# Automatic generation of secure passwords with the least inconvenience for a user

I'm working on a web site for a private company that should allow them to upload files, which will be later retrieved by their affiliates. The site will be available from a public Internet using private URLs for each uploaded file. All files uploaded will be encrypted-and-MAC'ed using AES-256 encryption. Files could be retrieved by a recipient only if they know the password for each file.

Since humans are pretty bad at picking secure passwords I decided to generate passwords for such encryption automatically and display them for a user after the file is uploaded & encrypted.

Another detail that I need to mention is that after each file is uploaded an employee of the company may transmit its password to a recipient (via a phone call or a fax.) Thus a requirement for this password to be something that can be both "secure" and "manageable" by a non-cryptographer.

So my strategy was to come up with a set of unambiguous characters and numbers that will be easy for a human being to relay over the phone.

I came up with the following 20 characters:

efghkpqrsuwxy2345679

But my question is, how many of those characters shall I include in the password to make it secure, and at the same time make it not too hard for a sender/receiver to work with?

The entropy of a random password is given by the formula:

$$H = log_2 N^L = L\log_2 N$$

where $$N$$ is the number of possible symbols, and $$L$$ is the length of the password. Since you want to know the minimum length to achieve a determined level of security, then the answer to your question is $$L = \lceil \frac{H}{log_2 N} \rceil$$.

In your case, $$N=20$$, and your desired entropy $$H$$ depends on the requirements of your system. RFC 4086 gives some guidelines about it. Let us assume you want to have only a one in a million chance of a password being guessed, then you need at least 39 bits of randomnes, so $$H = 39$$. Then $$L = \lceil \frac{H}{log_2 N} \rceil = \lceil 9.02 \rceil = 10$$, so you need at least 10 characters. Of course, if you want to achieve more bits of randomness, then the length will increase. For instance, for 128 bits, you need at least 30 characters.

Note: All this info comes from Wikipedia

• Thanks for the math and the Wiki link. I'll try to read through it. Feb 4 '15 at 9:18
• Can I ask -- how did you get H=39 from a one in a million chance? Feb 4 '15 at 9:49
• It is one of the examples given in Section 8.1 from RFC 4086. In this example it is assumed an attacker can make up to 500,000 guesses before the attack is noticed by the target system, so for a one in a million chance you need an universe of $500\,000 * 1\,000\,000 \approx 2^{39}$ passwords, hence 39 bits. Anyway, it is just an example, and the requirements of your system should be very clear in order to find out the required bits of entropy. Feb 4 '15 at 10:00

Concerning your generated password, I would opt for the BASE32 alphabet. This should be unambiguous enough. 32 characters will lead you to 5 bit per character.

Thus, it would require approx. 25 characters to get (nearly) a 128 bit key.

Better would be, to take this randomly chosen character string and feed it into a key derivation function as password (e.g. PBKDF2, BCrypt or SCrypt). You can generate the required random salt (e.g. 128bit) and place it together with the encrypted file. This will allow you to "stretch" your 125 bit random data into a good 256 bit key.

• Thanks. Yes, absolutely, I'll pass this password through PBKDF2 algo using random salt and high iteration count. Feb 4 '15 at 9:04