• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Using SecureString objects

H

Hal Rottenberg

#1
I'd like to use the SecureString feature of read-host to be able to
treat passwords entered on the command-line with more umm, respect.
However, I'm running into a problem using the created object
(SecureString class) and passing the value as input to a COM object.
I _think_ this is by design, and I see references perhaps to how to
enable this in MSDN, but the C# etc. stuff is over my head. Can
anyone tell me how to do this?

Hmm, after further poking, I can't seem to extract the value in any
way at all. I must be doing something wrong?

MSDN: http://msdn2.microsoft.com/en-us/library/system.security.securestring.aspx

code:

# $password = read-host "Enter password" -asSecureString

# $password.GetType()

IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True False SecureString
System.Runtime.ConstrainedExecution.CriticalFinal...

# $password | get-member

TypeName: System.Security.SecureString

Name MemberType Definition
---- ---------- ----------
AppendChar Method System.Void AppendChar(Char c)
[and so on...]

100# $password
System.Security.SecureString
 

My Computer

M

Marco Shaw

#2
Hal Rottenberg wrote:
> I'd like to use the SecureString feature of read-host to be able to
> treat passwords entered on the command-line with more umm, respect.
> However, I'm running into a problem using the created object
> (SecureString class) and passing the value as input to a COM object.
> I _think_ this is by design, and I see references perhaps to how to
> enable this in MSDN, but the C# etc. stuff is over my head. Can
> anyone tell me how to do this?
>
> Hmm, after further poking, I can't seem to extract the value in any
> way at all. I must be doing something wrong?


Check out:
http://abhishek225.spaces.live.com/blog/cns!13469C7B7CE6E911!273.entry

I think MoW has also said a few things on this before (in his older blog).
 

My Computer

H

Hal Rottenberg

#3
On Jun 27, 2:58 pm, Marco Shaw <marco.shaw@_NO_SPAM_gmail.com> wrote:
> Check out:http://abhishek225.spaces.live.com/blog/cns!13469C7B7CE6E911!273.entry


Perfect. Yeah, since my COM object doesn't know about SecureStrings,
looks like I have to do the little dance. Here's what I ended up
with:

If ($password -eq $null) # wasn't provided to function
{
# much crap required here to do the little "****" thing when
typing passwords
$SecurePassword = Read-Host "Enter password" -asSecureString

$Ptr=[System.Runtime.InteropServices.Marshal]::SecureStringToCoTaskMemUnicode($SecurePassword)
$password =
[System.Runtime.InteropServices.Marshal]::PtrToStringUni($Ptr)

[System.Runtime.InteropServices.Marshal]::ZeroFreeCoTaskMemUnicode($Ptr)
}

thanks for the $ptr
 

My Computer

T

ThuyLee

#4
I may be missing something, but if a secure string can be so easily
converted back into plaintext, what's the point? If malware can inject a
DLL into my powershell.exe process or otherwise access system memory to get
my admin password from the variable (regular or secure string), it's game
over anyway, isn't it? Seems more important to get the password into the
variable as late as possible, use it to authenticate to the remote system,
then set that variable to $null immediately afterwards.

So, is a "secure string" just a security feature (i.e., a hassle) without a
realistic threat to motivate it, a threat that wouldn't already represent a
complete compromise of the box? So few interfaces/objects support the use
of secure strings, the topic hardly seems to deserve so much attention.
 

My Computer

M

Marco Shaw

#5
ThuyLee wrote:
> I may be missing something, but if a secure string can be so easily
> converted back into plaintext, what's the point? If malware can inject
> a DLL into my powershell.exe process or otherwise access system memory
> to get my admin password from the variable (regular or secure string),
> it's game over anyway, isn't it? Seems more important to get the
> password into the variable as late as possible, use it to authenticate
> to the remote system, then set that variable to $null immediately
> afterwards.
>
> So, is a "secure string" just a security feature (i.e., a hassle)
> without a realistic threat to motivate it, a threat that wouldn't
> already represent a complete compromise of the box? So few
> interfaces/objects support the use of secure strings, the topic hardly
> seems to deserve so much attention.


http://mow001.blogspot.com/2005/11/get-credential-and-decrypting.html

You would have bigger problems if someone gained access to a object
containing your secure string: they'd have gained access to your account
somehow.

I couldn't name you how many cmdlets out there support secure strings,
but there's quite a few. I know quite of few of the cmdlets from
NetCmdlets do (www.nsoftware.com/powershell).

Marco
 

My Computer

H

Hal Rottenberg

#6
On Jun 27, 7:14 pm, "ThuyLee" <t...@unlv.edu> wrote:
> I may be missing something, but if a secure string can be so easily
> converted back into plaintext, what's the point?


I recognize that my use case isn't a typical one. I'm being
necessarily insecure here as the object I'm passing to doesn't accept
SecureStrings as input. It's almost not worth the **********'s but it
does at least cover the shoulder password sniffing attempts. :)
 

My Computer

Users Who Are Viewing This Thread (Users: 1, Guests: 0)