I’m attending a two-day Windows PowerShell course, delivered by my colleague Dave – who I know reads this blog and should really think about starting his own…
I’ve written before about Windows PowerShell (twice) and I think it’s a great product, but it is a version 1.0 product and as such it has some faults. One (which I was horrified to discover today) is that this product, which is intended to be secure by default (for a number of good reasons) has the ability to store user credentials in clear text!
All it takes is two lines of PowerShell script:
$cred=get-credential username
(the user wil then be prompted for their password using a standard Windows authentication dialog)
$cred.getnetworkcredential()
(the username, password and domain will be displayed in clear text)
Some people ask what’s wrong with this? After all there are legitimate reasons for needing to use credentials in this manner. That may be so but one of the fundamental principles of Windows security is that passwords are never stored in clear-text – only as a hashed value – clearly this breaks that model. Those who think there is nothing wrong with this argue that the credentials are then only used by the user that entered them in the first place. Even so, I’m sure this method could easily be used as part of a phishing attempt using a fake (or altered) script (digitally signing scripts may be the default configuration but many organisations will disable this, just as they do with signed device drivers and many othe security features).
After searching Microsoft Connect and being surprised that I couldn’t find any previous feedback on this I’ve raised the issue as a bug but expect to see it closed as “Resolved – by design” within a few days. If it really is by design, then I don’t feel that it’s a particularly smart design decision – especially as security is tauted as one of the key reasons to move from VBscript to PowerShell.
I think your “bug” on Connect will be resolved, but not how you think.
This discovery is one that many people “stumble upon” when they first start using get-credential. Using Poweshell istself (as below) you can see PS stores the values in Security.SecureString, not in cleartext.
Lee Holmes (dev on Powershell project) explains this much better than I, both on his blog and numerous times on the PS newsgroup.
http://www.leeholmes.com/blog/PowerShellCredentialsAndGetNetworkCredential.aspx
[54]> $cred = Get-Credential
cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:
Credential
[55]> $cred | gm
TypeName: System.Management.Automation.PSCredential
Name MemberType Definition
—- ———- ———-
Equals Method System.Boolean Equals(Object obj)
GetHashCode Method System.Int32 GetHashCode()
GetNetworkCredential Method System.Net.NetworkCredential GetNetworkCredential()
GetType Method System.Type GetType()
get_Password Method System.Security.SecureString get_Password()
get_UserName Method System.String get_UserName()
ToString Method System.String ToString()
Password Property System.Security.SecureString Password {get;}
UserName Property System.String UserName {get;}
Hi James,
I’ve read various posts about this (including Lee’s) but am still not convinced – my reasoning is that, regardless of how the credential is stored, it can be retrieved in a human-readable form. I shouldn’t ever be able to say “what is the password?” and read it – what I should be able to say is, “does this hash (based on what I think the password is) match the stored hash for the password?” – that’s something very different (and far more secure in my view).
Whether this is actually a bug is questionable (it probably is by design) – unfortunately the only other type of feedback that I can submit to Microsoft is a suggestion – maybe I should “suggest” that this is a poor way in which to handle user credentials and other sensitive data.
Mark
But it’s only accessible in a human readable format in your process. Another session cannot read it, its stored in yours. And there is only a certain extent that you can protect yourself from yourself.
James