SecureString() in framework 1.1

  • Thread starter Thread starter Pietro Pesce
  • Start date Start date
P

Pietro Pesce

hi all,

i have this code:


Module Module1


Sub Main()


Dim theProcessStartInfo As New
System.Diagnostics.ProcessStartInfo("Cambio_ip.exe")


Dim theSecurePassword As New System.Security.SecureString()


theSecurePassword.AppendChar("*")


theSecurePassword.AppendChar("*")


theSecurePassword.AppendChar("*")


theSecurePassword.AppendChar("*")
theSecurePassword.AppendChar("*")
theSecurePassword.AppendChar("*")
theSecurePassword.AppendChar("*")
theSecurePassword.AppendChar("*")
theSecurePassword.AppendChar("*")
theSecurePassword.AppendChar("*")
theSecurePassword.AppendChar("*")
theSecurePassword.AppendChar("*")
theSecurePassword.AppendChar("*")
theSecurePassword.AppendChar("*")
theSecurePassword.AppendChar("*")
theSecurePassword.AppendChar("*")


theProcessStartInfo.UserName = "Administrator"


theProcessStartInfo.Password = theSecurePassword


theProcessStartInfo.UseShellExecute = False
'theProcessStartInfo.WorkingDirectory = "c:\"


System.Diagnostics.Process.Start(theProcessStartInfo)


End Sub


End Module


its work...but whit framework 1.1 dont work because SecureString()
there arent.


i must be run i program whit the administrator privileges......where
i
can do?


tnx,
bye
 
its work...but whit framework 1.1 dont work because SecureString()
there arent.

i must be run i program whit the administrator privileges......where
i

As far as I know. the securestring does not exist in the 1.1 framework.

I think you'll need to compile the code against version 2.0 or better.
 
As far as I know. the securestring does not exist in the 1.1 framework.

I think you'll need to compile the code against version 2.0 or better.



i know....but i must run the program whit the pc whit framework 1.1
 
So you can't use SecureString !? So I'm sure what the question is but it
could range from just using a plain old string or crypting yourself the
string (possibly using the same class name so that you could easily upgrade
to 2.0 once read) or enforcing the use of .NET 2.0. Anyway there are likely
some securestring features you won't be able to implement by yourself.

Also as a side note it's likely best to always code for the framework you
target so that you don't use accidentaly things that would not compile
anyway on an earlier framework release you support...

If not enough please elaborate a bit on your requirements (for now the
question sounds like how do I use a 2.0 specific feature in 1.1 which is not
possible by definition).
 
So you can't use SecureString !? So I'm sure what the question is but it
could range from just using a plain old string or crypting yourself the
string (possibly using the same class name so that you could easily upgrade
to 2.0 once read) or enforcing the use of .NET 2.0. Anyway there are likely
some securestring features you won't be able to implement by yourself.

Also as a side note it's likely best to always code for the framework you
target so that you don't use accidentaly things that would not compile
anyway on an earlier framework release you support...

If not enough please elaborate a bit on your requirements (for now the
question sounds like how do I use a 2.0 specific feature in 1.1 which is not
possible by definition).

---
Patrice

"Pietro Pesce" <[email protected]> a écrit dans le message de (e-mail address removed)...





- Mostra testo tra virgolette -


mmmm i dont understand:
1- how can use securestring whit fw 1.1? post the code?
2- you know another method for run the program whit the administrator
privileges?


tnx
 
Precisely you can't. That's what I meant. For now I'm not sure what you are
asking.

Note that the use of SecureString is not needed and that the same code would
work with a plain usual string (is this the information you are looking for
?). The SecureString allows to crpt/decrypt the string when needed and the
framework take some actions to avoid having this floating in memory where it
could be captured.

So unless you have a more specific requirement I would say just use a
string. The secure string is not at all related to running a program under
an account but is a general tool you can use to store sensitive strings in
2.0.

--
Patrice

"Pietro Pesce" <[email protected]> a écrit dans le message de (e-mail address removed)...
So you can't use SecureString !? So I'm sure what the question is but it
could range from just using a plain old string or crypting yourself the
string (possibly using the same class name so that you could easily
upgrade
to 2.0 once read) or enforcing the use of .NET 2.0. Anyway there are
likely
some securestring features you won't be able to implement by yourself.

Also as a side note it's likely best to always code for the framework you
target so that you don't use accidentaly things that would not compile
anyway on an earlier framework release you support...

If not enough please elaborate a bit on your requirements (for now the
question sounds like how do I use a 2.0 specific feature in 1.1 which is
not
possible by definition).

---
Patrice

"Pietro Pesce" <[email protected]> a écrit dans le message de (e-mail address removed)...





- Mostra testo tra virgolette -


mmmm i dont understand:
1- how can use securestring whit fw 1.1? post the code?
2- you know another method for run the program whit the administrator
privileges?


tnx
 
I KNOW!

FYI - if you're rude you will get ignored. While you might not have
meant this statement rudely, the allcaps gives that impression.
my question is: there is another method for run the program whit the
administrator
privileges?

None that I know of that don't require an admin username and password.

Besides, if you are worried about the security of the password
SecureString isn't going to help in your current implementation
anyways. All a malicious user would need to do is use the MSIL
disassembler and look at which characters you are passing to the
SecureString's methods.

If it were me, I would use VB6 (much harder to decompile) and a bit
shifting/XOR method to encrypt/decrypt the password string. This way
you don't even need to worry about what (if any) framework is
installed on the client. Be warned, this won't stop a determined
hacker, but it should at least stop "script-kiddies" from reading your
IL or plain text strings with notepad.

Thanks,

Seth Rowe
 
The problem for us is that running a program as an administrator has nothing
to do with the SecureString object. It will run as well with a usual string.

So for now I'm not sure if the question is that you don't know that the
SecureString is not needed and that a string will work as well ?!

If this is to run at start time I would use a GPO for example. Not an expert
but AFAIK it allows to run scripts are an administrator out from the box.
 
The problem for us is that running a program as an administrator has nothing
to do with the SecureString object. It will run as well with a usual string.

So for now I'm not sure if the question is that you don't know that the
SecureString is not needed and that a string will work as well ?!

If this is to run at start time I would use a GPO for example. Not an expert
but AFAIK it allows to run scripts are an administrator out from the box.

--
Patrice

"Pietro Pesce" <[email protected]> a écrit dans le message de (e-mail address removed)...





- Mostra testo tra virgolette -



i' have od this vbs

On Error Resume Next
dim WshShell,FSO







sUser=*****
sPass=****
sCmd=****
set WshShell = CreateObject("WScript.Shell")
set WshEnv = WshShell.Environment("Process")
WinPath = WshEnv("SystemRoot")&"\System32\runas.exe"
set FSO = CreateObject("Scripting.FileSystemObject")

if FSO.FileExists(winpath) then
'wscript.echo winpath & " " & "verified"
else
wscript.echo "!! ERROR !!" & VBCRLF & "Can't find or verify " &
winpath &"." & VBCRLF & "You must be running Windows 2000 for this
script to work."
set WshShell=Nothing
set WshEnv=Nothing

set FSO=Nothing
wscript.quit
end if

rc=WshShell.Run("runas /user:" & sUser & " " & CHR(34) & sCmd &
CHR(34), 2, FALSE)

Wscript.Sleep 30 'need to give time for window to open.
WshShell.AppActivate(WinPath) 'make sure we grab the right window to
send password to
WshShell.SendKeys sPass 'send the password to the waiting

set WshShell=Nothing
set WshEnv=Nothing
set FSO=Nothing

wscript.quit


but if the user open it whit notepad see the password ^_^
i can encrypt?

my problem is:
1- the must run in administrative mode
2- the user cant see/write the password


tnx,Pietro
 
If we step back to the real problem. What is this application that must run
under an administrative account ?

I've seen applications failing and it's usually something such as writing to
a bad location in which case changing the location where the application
writes or in the worst case granting rights to the application directory is
sufficient to make the application run.

Tools such as wwww.sysinternals.com could help and the editor support could
likely have already heard about this.

If the user runs under an administrative account :
- he could do whatever he want on disk (for example from the save dialog)

My personal preference would be to grant the minimal amount of rights needed
to run rather than running the application under an administrative account.

Else I'm afraid there is not much you can do :
- you could perhaps encrypt a script (windows script encoder if I remember)
but AFAIK it's quite weak
- even a Securestring wouldn't help if the password is shown anyway in your
code
- GPOs are able to run under scripts administrative accounts but AFAIK at
startup

I would definitively try to understand what this damn application needs
something better than normal rigths (but it likely doesn"t mean real admin
rights).

--
Patrice

"Pietro Pesce" <[email protected]> a écrit dans le message de (e-mail address removed)...
The problem for us is that running a program as an administrator has
nothing
to do with the SecureString object. It will run as well with a usual
string.

So for now I'm not sure if the question is that you don't know that the
SecureString is not needed and that a string will work as well ?!

If this is to run at start time I would use a GPO for example. Not an
expert
but AFAIK it allows to run scripts are an administrator out from the box.

--
Patrice

"Pietro Pesce" <[email protected]> a écrit dans le message de (e-mail address removed)...





- Mostra testo tra virgolette -



i' have od this vbs

On Error Resume Next
dim WshShell,FSO







sUser=*****
sPass=****
sCmd=****
set WshShell = CreateObject("WScript.Shell")
set WshEnv = WshShell.Environment("Process")
WinPath = WshEnv("SystemRoot")&"\System32\runas.exe"
set FSO = CreateObject("Scripting.FileSystemObject")

if FSO.FileExists(winpath) then
'wscript.echo winpath & " " & "verified"
else
wscript.echo "!! ERROR !!" & VBCRLF & "Can't find or verify " &
winpath &"." & VBCRLF & "You must be running Windows 2000 for this
script to work."
set WshShell=Nothing
set WshEnv=Nothing

set FSO=Nothing
wscript.quit
end if

rc=WshShell.Run("runas /user:" & sUser & " " & CHR(34) & sCmd &
CHR(34), 2, FALSE)

Wscript.Sleep 30 'need to give time for window to open.
WshShell.AppActivate(WinPath) 'make sure we grab the right window to
send password to
WshShell.SendKeys sPass 'send the password to the waiting

set WshShell=Nothing
set WshEnv=Nothing
set FSO=Nothing

wscript.quit


but if the user open it whit notepad see the password ^_^
i can encrypt?

my problem is:
1- the must run in administrative mode
2- the user cant see/write the password


tnx,Pietro
 
If we step back to the real problem. What is this application that must run
under an administrative account ?

I've seen applications failing and it's usually something such as writingto
a bad location in which case changing the location where the application
writes or in the worst case granting rights to the application directory is
sufficient to make the application run.

Tools such as wwww.sysinternals.comcould help and the editor support could
likely have already heard about this.

If the user runs under an administrative account :
- he could do whatever he want on disk (for example from the save dialog)

My personal preference would be to grant the minimal amount of rights needed
to run rather than running the application under an administrative account.

Else I'm afraid there is not much you can do :
- you could perhaps encrypt a script (windows script encoder if I remember)
but AFAIK it's quite weak
- even a Securestring wouldn't help if the password is shown anyway in your
code
- GPOs are able to run under scripts administrative accounts but AFAIK at
startup

I would definitively try to understand what this damn application needs
something better than normal rigths (but it likely doesn"t mean real admin
rights).

--
Patrice

"Pietro Pesce" <[email protected]> a écrit dans le message de (e-mail address removed)...





i' have od this vbs

On Error Resume Next
dim WshShell,FSO

sUser=*****
sPass=****
sCmd=****
set WshShell = CreateObject("WScript.Shell")
set WshEnv = WshShell.Environment("Process")
WinPath = WshEnv("SystemRoot")&"\System32\runas.exe"
set FSO = CreateObject("Scripting.FileSystemObject")

if FSO.FileExists(winpath) then
'wscript.echo winpath & " " & "verified"
else
wscript.echo "!! ERROR !!" & VBCRLF & "Can't find or verify " &
winpath &"." & VBCRLF & "You must be running Windows 2000 for this
script to work."
set WshShell=Nothing
set WshEnv=Nothing

set FSO=Nothing
wscript.quit
end if

rc=WshShell.Run("runas /user:" & sUser & " " & CHR(34) & sCmd &
CHR(34), 2, FALSE)

Wscript.Sleep 30 'need to give time for window to open.
WshShell.AppActivate(WinPath) 'make sure we grab the right window to
send password to
WshShell.SendKeys sPass 'send the password to the waiting

set WshShell=Nothing
set WshEnv=Nothing
set FSO=Nothing

wscript.quit

but if the user open it whit notepad see the password ^_^
i can encrypt?

my problem is:
1- the must run in administrative mode
2- the user cant see/write the password

tnx,Pietro- Nascondi testo tra virgolette -

- Mostra testo tra virgolette -

i have made a program for change ip...i must run this exe in
administrator mode because the user don have the permission to do ;)
 
Back
Top