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:
(the user wil then be prompted for their password using a standard Windows authentication dialog)
(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.