Twitter response

@rfreeburn

Hey Ryan,

I thought this would be the easiest way to answer you in 140+ characters.

My first point is that the entropy of a random string is not defined by the number of possible characters. If you were to randomly pick a number between 1 and 100, and I randomly picked seven 1's or 0's, my string would have more entropy

log(100,2) = 6.64
and
2^7 > 2^6.64

---

The second point is that three characters in a set do not provide 3 bits of entropy. For example, there are 94 printable characters on a typical keyboard:

len(ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890`~!@#$%^&*()-=_+[]\{}|;\':",./<>?) == 94

if we remove @:!, it becomes

len(ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890`~#$%^&*()-=_+[]\{}|;\'",./<>?) == 91

and

log(94, 2) = 6.555 bits
log(91, 2) = 6.508 bits

so we lost about .05 bits per character, not 3.

---

The last point is that people generally don't randomly generate their passwords. They use strings that are easily remembered. A user chosen password has very little entropy per character, and most users wouldn't pick a password containing @:! anyway. This presentation [1], explains how to estimate the entropy bits per user chosen password (but it's low, like 1-2 bits per character). 

If you are actually generating passwords [2], either ignore the .05 bits/char that you lost, or add another character.

[1]: http://csrc.nist.gov/archive/pki-twg/y2003/presentations/twg-03-05.pdf
[2]: https://github.com/oconnore/diceware
[3]: http://www.xkcd.com/936/

Having thought about this a bit, I totally see what you're saying, but I still think it's bad practice to limit the charset. Not only does it help attackers (even just a little), but it also creates a poor user experience for people who run into it, like me.

I'm a developer, and I've written authentication code a time or two, so I know what's involved. When a system rejects the password I choose, for any reason, my immediate thought is: what other compromises have they made that make development simpler but potentially reduce security? It leaves a bad taste in my mouth. I was unclear in our discussion of this on Twitter: the reduction in entropy wasn't my major concern; the reduction in trust was.

Good passwords are behavioral, like you said. Trying to get people to choose long passwords that can't easily be guessed is difficult; putting an unexpected and unstated rule in their way is just going to lead to frustration, and frustration leads to poor behavior.

In http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/ one of the crackers they interviewed explicitly said, "If I knew the site, I would go there and find out what the requirements are." Processing power is cheap, and cracking tools are powerful. Seeing anything that's not best practices, especially on a site targeted at developers (who really should know better), worries me.

Thanks for helping me understand the math behind entropy calculation better, though. I appreciate the time you took to write this up and send me pointers.