4

I currently have some (PowerShell) code that does this -

$password = [System.Web.Security.Membership]::GeneratePassword(128,0)

I realise that strings are generally considered insecure. So I am curious whether there is a way to generate a random password directly into a secure string?

(for a little background, I am trying to find a solution to this post)

Community
  • 1
  • 1
Michael B
  • 11,887
  • 6
  • 38
  • 74
  • 1
    1) You ARE generating a "random password". 2) Anything in plaintext is "insecure". As a second step, you need to encrypt the password. 3) UNLESS "generate password" and "encrypt password" are two separate steps ... how is anybody going to be able to use the password???? – paulsm4 Oct 04 '16 at 04:56
  • @paulsm4 I'm trying to avoid the 'anything in plaintext is "insecure"' part of that - by generating a random password directly as a SecureString - i.e. so there is no string step involved at all. – Michael B Oct 04 '16 at 05:00
  • 2
    Secure strings [aren't all that secure](http://stackoverflow.com/a/30653815/1630171) to begin with. And as paulsm4 already said: nobody will be able to use the password if you create and encrypt (hash, actually) a random string in one step. How would the intended user know the password? – Ansgar Wiechers Oct 04 '16 at 10:27
  • @AnsgarWiechers there are [reasons](http://stackoverflow.com/a/141393/5255018) that securestrings exist though. I am aware of the weaknesses of SecureStrings, but by using SecureStrings thoughout an application they do reduce the likelihood of sensitive data leaks. A determined attacker might be able to easily bypass them, but that doesn't mean they shouldn't be used to add a layer of protection where it is appropriate. – Michael B Oct 04 '16 at 11:54
  • My point wasn't that you shouldn't use them, but that you should be aware of their weaknesses, so you can make an educated decision when to use them, and when not to use them. From what I can see I'd say using `ConvertTo-SecureString -AsPlainText -Force` and suppressing `PSAvoidUsingConvertToSecureStringWithPlainText` should be fine in your scenario. – Ansgar Wiechers Oct 04 '16 at 11:58
  • 1
    @AnsgarWiechers It is the awareness of the weaknesses that I'm trying to find a solution for - by using -AsPlainText the plain text will be left in memory and possibly swapped to disk (as plaintext) If I create the password as a securestring, it avoids that particular weakness. There may be other issues along the way that could leak that data, but I'll address those as I come to them. It isn't the warning that is bothering me, it is actual insecurity it is warning about. Turning the warning off and saying it should be fine, isn't really the stance I'm looking for – Michael B Oct 04 '16 at 12:08

0 Answers0