11
$\begingroup$

There are some strong studies which support the use of pronounceable passwords and multiple tools which provide generation of such passwords.

According to this question the entropy of a password depends on its method of generation but how can I be sure that my generated pronounceable password has enough entropy for my use? (for example, in case of pwgen open source software)

Below is a pseudocode for generating a pronounceable password. However, this might be the simplest possible solution and I am rather interested in existing "conventional" methods.

vowels = A, AI, AU, E, EA, EE, I, IA, IO, O, OA, OI, OO, OU, U
consonants = B, C, CH, CL, D, F, FF, G, GH, GL, J, K, L, LL, M, MN, N, P, PH, PS, R, RH, S, SC, SH, SK, ST, T, TH, V, W, X, Y, Z
theLastOneIsAVowel = True
while length(strPassword) < Minimum_Length do
if theLastOneIsAVowel then
strPassword = strPassword + randomElementOf(consonants)
else
strPassword = strPassword + randomElementOf(vowels)
endif
theLastOneIsAVowel = ~(theLastOneIsAVowel)
endwhile
$\endgroup$
  • 5
    $\begingroup$ Do you have some pseudocode or anything on the method of generation? Once you know that, you can compute the entropy of the resulting passwords. $\endgroup$ – mikeazo Oct 22 '14 at 13:34
  • $\begingroup$ What is enough entropy for your use? How long is that pronounceable password? Entropy for passwords from language are hard to measure, because you would have to know the likelihood of each syllable, etc. Then: Do you consider saying "hash", "dot" pronounceable? Most symbols have some form to speak them out. $\endgroup$ – tylo Oct 22 '14 at 13:36
  • 2
    $\begingroup$ Entropy is calculated with some reference to a model. The lowest (and this most conservative) measure of entropy will be if you assume the attacker has access to your generator model. The fact that the output is pronounceable does not need to control total entropy, but setting the entropy target high may make the passwords longer and defeat your goal of making them memorable. $\endgroup$ – Neil Slater Oct 22 '14 at 13:53
  • $\begingroup$ I didn't include anything about pwgen in my answer because there are several unrelated programs named that. (And because I didn't feel like reading through their source.) $\endgroup$ – otus Oct 23 '14 at 16:21
  • $\begingroup$ @tylo My aim is to compare the entropy of a pronounceable password with the entropy of an unpronounceable one with the same length. For a certain purpose I might need, say, 128-bit of entropy which guarantees that exhaustive search is hard enough for my purpose, even if the generation method is known to the attacker. Pronounceable passwords are "usually" some kind of nonsense words which are so easy to memorize. Examples are "leynoberepin", "ainporietora" or "iteellyterna". (these ones are all generated by LastPass) $\endgroup$ – Habib Oct 25 '14 at 11:39
8
$\begingroup$

Yes, the entropy depends on the generation process. The study you link to has the answer for the (fixed) process used there:

To overcome this [flaw in the original program], we generated the full list of eight-character pronounceable passwords without duplicates (≈ 1.2 billion) and assigned each password on this list with equal probability, resulting in 30.2 bits of entropy.

That is equivalent to five base 64 characters. I.e. you lose about 2.25 bits of entropy per character by making the password pronounceable, compared to using random base 64 passwords.

However, like the implementation they used, it is possible the algorithm is flawed and does not generate all possible pronounceable passwords with equal probability. In that case you lose even more entropy. So I would check the program carefully before relying on it.

$\endgroup$
5
$\begingroup$

"How can I be sure that my generated pronounceable password has enough entropy for my use?"

One way to guarantee that a passphrase has "enough entropy for my use": Obtain a block of at least that many bits of fresh entropy from /dev/random or some other secure random number generator, and then encode those bits to a passphrase in a way that every possible block of bits generates a different passphrase.

There are huge variety of ways to encode raw bits to an easier to type password, passphrase or ID number.

For example, if you decide 64 bits of entropy adequate, then obtain a block of 64 fresh random bits. Then pick any one of:

  • Use the PGP word list to convert those 64 bits to a passphrase composed of 8 very distinct English words with space between them. (This produces phrases that are easy to decode after hearing them read over a telephone).

  • Use the S/KEY word list to convert those 64 bits to a passphrase composed of 6 short English words with spaces between them. (This may be the quickest way for touch-typists on a regular keyboard to enter a passphrase with the desired amount of entropy).

  • use the Diceware list to convert those 64 bits to a passphrase composed of 5 more-or-less common English words with spaces between them.

  • Use the Antti Huima Bubble Babble Encoding (a) (b) (c) (d), alternating vowels and consonants, to convert those 64 bits into a 29-character pronounceable passphrase.

  • Use the rsaarelm vorud encoding, alternating vowels and consonants, to encode those 64 bits into a 23-character pronounceable passphrase.

  • It appears that the code for rsaarelm vorud encoding can be adapted for the alternating vowels/dipthongs and consonants/consonant clusters technique, described by the original poster -- it looks like encoding 64 bits with this encoding produces a pronounceable passphrase of roughly 24 characters, more or less depending on the exact value of those bits.

  • Use octal encoding to convert those 64 bits into a 22-digit number.

  • Use base32 encoding to convert those 64 bits into a 14-character password.

  • Use base-64-url encoding to convert those 64 bits to an 11-character password.

  • Use Ascii85 encoding to convert those 64 bits to a 10-character password.

(Contrary to popular belief that shorter passwords are easier to type, the last two encodings usually produce passwords that take more keystrokes and more time to type than other encodings, when you include the "shift key" as a keystroke).

Since, once you've chosen one of these encodings, every possible block of 64 bits generates a different password or passphrase, all of these encodings and all of the passphrases generated by them are equally secure. Each encoding -- as long as you started with a block of bits with 64 bits of entropy -- generates a passphrase with 64 bits of entropy.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.