Secure Password Generator

[barefootNH]

As you requested, I created C code to do the same thing. It will work on Linux or Windows. I took the Perl script, C code, 32-bit Linux binary, and 32-bit Windows binary and put it into a ZIP file that can be downloaded from the pwgen page.

I downloaded the .zip file with the source code and attempted to install it in my Ubuntu Linux, but it wouldn't install. I was able to do this with the source code for aescrypt and the aescrypt_keygen programs.

I'm in the directory with the source files. Doing a 'make' resulted in the creation of the pwgen and pwgen.o files, but 'sudo make install' resulted in
make: ***No rule to make target 'install'

[paulej]

Yeah, I did not define a rule for installing it. It's trivial, though. Just do this:

Code: Select all

sudo cp pwgen /usr/local/bin

If you prefer to put it in /usr/bin, that's OK. Either will work.

Paul

[barefootNH]

Yeah, I did not define a rule for installing it. It's trivial, though. Just do this:

Code: Select all

sudo cp pwgen /usr/local/bin

If you prefer to put it in /usr/bin, that's OK. Either will work.

Paul

Oooooh!

It works now; I didn't realize the resulting pwgen was what we were after.

Thank you.

[barefootNH]

I prefer Single Pass. With Single Pass, you remember just one password and unique, per-site passwords are created automatically. It's very handy.

I'm looking over the Technical Details of Single Pass...
http://singlepass.packetizer.com/technical.html

As I understand it, it's taking a relatively random number between 0 and 255 and doing a mod(62) to it to choose one of the 62 characters.

Doesn't the mod(62) operation introduce a bias (towards the first 8 characters) because 256 isn't an integer multiple of 62?

I'm also thinking in the context of pwgen, if this method is used to choose from the 62 character set and if there is a bias.

[paulej]

Yes, mod 62 will create bias. This is something I wrestled with for a bit for SinglePass. I could not find a good solution for that, so I gave up.

I considered an approach where I keep reading more random values in the hash that gets generated. The problem is that there is still the possibility of running out of octets. That would be extremely rare, but it's possible. And the bias is fairly minor. It exists, but only if the octet is >= 248 in value. That results in wrapping back around to 0..7. In my experiments, this often only happens to a single character in a typical password. So out of one 16-octet password, there is usually about 1 character that might see bias. How serious is that?

I also have the same issue with aescrypt_keygen. I have a fix for that in the source repository, but not posted to the web site. For that, I just used an additional two characters: I then selected "%" and "$" to create 64 possible values. Two reasons it is not yet posted are that 1) I'm not sure I like this solution, and 2) I'd like to just integrate the code right into aescrypt itself.

I had previously updated the pwgen C code to avoid modulo bias. Basically, it just discards and value that is higher than acceptable to avoid bias.

The Perl code is not subject to bias due to the random number generator that is used. It generates a big integer (not just values 0..255) and, based on my tests, bias is not visible.

[barefootNH]

Yes, mod 62 will create bias. This is something I wrestled with for a bit for SinglePass. I could not find a good solution for that, so I gave up.

For a log-in password a little bias is not a concern. I'm pretty sure fixes exist, but since I'm not that well-versed I'm not sure what they are.

I've read numerous times that bias in a random number generator is definitely a problem, but we're just making log-in passwords with SinglePass.

I considered an approach where I keep reading more random values in the hash that gets generated. The problem is that there is still the possibility of running out of octets. That would be extremely rare, but it's possible. And the bias is fairly minor. It exists, but only if the octet is >= 248 in value. That results in wrapping back around to 0..7. In my experiments, this often only happens to a single character in a typical password. So out of one 16-octet password, there is usually about 1 character that might see bias. How serious is that?

I understand what you're saying about the possibility of running out of octets, and I think that's one of the standard "fixes" to the bias problem: just keep throwing more digits into the soup (I'm not sure I understand how that fixes the bias, so I need to study it more). To give you more octets to play with I guess an alternative approach might be to use SHA512 or SHA1024 instead of SHA256.

I also have the same issue with aescrypt_keygen. I have a fix for that in the source repository, but not posted to the web site. For that, I just used an additional two characters: I then selected "%" and "$" to create 64 possible values. Two reasons it is not yet posted are that 1) I'm not sure I like this solution, and 2) I'd like to just integrate the code right into aescrypt itself.

I had previously updated the pwgen C code to avoid modulo bias. Basically, it just discards and value that is higher than acceptable to avoid bias.

The Perl code is not subject to bias due to the random number generator that is used. It generates a big integer (not just values 0..255) and, based on my tests, bias is not visible.

If it's not a problem in pwgen I'm surprised to hear that there's a problem in aescrypt_keygen.

If you're thinking of adding 2 additional characters to round up to 64, what about just using standard base-64 encoding? (But there are a few different "standards".)

These classical problems of modulo bias and whether or not to use base-64 is why I frequently just stick with using hex characters: no ambiguous characters (0 vs O, etc.) in case I'm forced to enter it manually, and it just looks geeky cool. lol. I do essentially what you're doing with SinglePass: do a hash on something and use all or some of the hex characters. Working from the command line makes it quite easy in whatever OS I'm using at the time (home=Linux, work=Windoze).

Sure, it's only 4 bits worth of entropy at most, but since I've gotten myself to a point that some sort of password safe (Keepass or LastPass) is absolutely mandatory for virtually everything I do, entering 24 hex characters through copy-and-paste is just as easy as entering 16 base-64 characters. Same reason for not choosing to use special characters, which I also see you're not a real fan of: it's just not all that necessary.

Wow, sorry if I've gotten too wordy. lol

[paulej]

If it's not a problem in pwgen I'm surprised to hear that there's a problem in aescrypt_keygen.

It was a problem in pwgen. I fixed that about a month ago. Previously, they were using similar logic.

If you're thinking of adding 2 additional characters to round up to 64, what about just using standard base-64 encoding? (But there are a few different "standards".)

One reason is that pwgen will also use a 93-character alphabet and it could be extended to use more, though I'm struggling to find more characters to use. I think it uses about every printable ASCII character. The other reason for not using Base64 is that we're not encoding data for transmission. We just need to create a string of random characters. So, no standard is needed with respect to internal order. For pwgen or aescrypt_keygen, I could easily re-order to follow base64. However, I can't do that for Single Pass, as it would mean anyone using it presently would not be able to generate the same password. So, Single Pass is locked to its ordering of characters. And I think it's that ordering that found its way into pwgen (and then aescrypt_keygen).

BTW, the reason for using 62 characters originally was so that "normal" passwords contained only letters and numbers. That's easy for the human user.

These classical problems of modulo bias and whether or not to use base-64 is why I frequently just stick with using hex characters: no ambiguous characters (0 vs O, etc.) in case I'm forced to enter it manually, and it just looks geeky cool. lol. I do essentially what you're doing with SinglePass: do a hash on something and use all or some of the hex characters. Working from the command line makes it quite easy in whatever OS I'm using at the time (home=Linux, work=Windoze).

Sure, it's only 4 bits worth of entropy at most, but since I've gotten myself to a point that some sort of password safe (Keepass or LastPass) is absolutely mandatory for virtually everything I do, entering 24 hex characters through copy-and-paste is just as easy as entering 16 base-64 characters. Same reason for not choosing to use special characters, which I also see you're not a real fan of: it's just not all that necessary.

Wow, sorry if I've gotten too wordy. lol

My only concern with using hex digits is the fact you really need a lot more digits to have a strong password. Some sites restrict password lengths (for some insane reason). I've found 16 octets is fairly well accepted, though not everywhere.

Using only {0-9A-F} and having 16 character passwords (64 bits of strength), you would generate passwords that could be broken in a year. That sounds like a long time, but using a 62 character alphabet and 16 character passwords (95.2 bits of strength), that bumps up to 4.3 billion years.

You are correct about the O and 0 problem. But, I don't worry about that for the reason you mentioned: these passwords have to be copied and pasted most times. On the rare occasion where I have to manually enter one, it's not a big deal.