Comment by kijin | Hacker News Reader

Comment by kijin | Hacker News Reader

If a 12-char password is "secure enough" today, then a 16-char password is obviously even more secure and future-proof. Not to mention a 30-char password, or a password that contains more special characters than what your dumb webapp allows.

Not to mention that a 30-char purely alphabetic passphrase such as xkcd.com/936 is so much easier to remember (i.e. less likely to be written on a post-it note) and type into today's mobile devices (i.e. more likely to log out properly, because it's easier to log in the next time) than a 12-char password with two numbers and one symbol in it. What I'm trying to say is that there is more to password strength than the time it takes for a botnet to brute-force it. Humans are the weakest link in most security systems. If you want strong security, you need to design your system so that humans can interact with it without too much mental strain.

Nowadays, anything less than [\x20-\xFE]{8,64} is just a lame excuse for storing passwords in a plain-text VARCHAR field without proper escaping. Therefore, if your password policy as any more restrictive than [\x20-\xFE]{8,64}, I'm going to assume that you store my passwords in a plain-text VARCHAR field without proper escaping.

>Therefore, if your password policy as any more restrictive than [\x20-\xFE]{8,64}, I'm going to assume that you store my passwords in a plain-text VARCHAR field without proper escaping.

Alternative interpretation: the Website is neither UTF8-safe (or whatever charset you prefer) nor are prepared statements used. Otherwise VARCHAR is fine even without any escaping.

Sorry, that was supposed to be \x7E but I can't edit anymore. Now you only need to deal with printable ASCII characters.

No problem, I was assuming printable anyway... ;)

I just wanted to point out that it's possible to use VARCHAR even with weird characters.

Here are two real world issues that could arise

http://vbuterin.blogspot.ca/2011/08/password-strength-rebutt...

I think some cryptographers and security people have given rebuttals as well but I can't find them at the moment.

Interesting, but I think the author is focusing too much on the desktop experience. Try typing 'Tr0ub4dor&3' vs. 'correct horse battery staple' on a phone. Having to shift between alternate layouts every other character is not only annoying but also makes you prone to forget which character you were trying to type. With a full-size keyboard, on the other hand, you can rely on muscle memory to get it right without even thinking. As for shoulder surfing, I find it rather difficult to shoulder-surf someone who is typing on a glossy 4-inch screen, and you can always choose unusual words/spellings to throw off people who try to guess. Corrupt hearse buttery scalpels!

I agree that it would be a better system for phones. I'm not sure about full size keyboards. Muscle memory will allow you to learn the password with only simple characters more quickly but eventually both will be learned. Then the only factor that matters is how accurately the user can type. I don't think muscle memory could ever get 100% accuracy for typing one character correctly. Anything less than 100% and longer passwords will be worse. If you type a key correctly 99.9% of the time then you will lose about twice as much of your time to wrong password entries with an 11 vs 20 char password.

> Here are two real world issues that could arise

Definitely true.

On the other hand, non-tech folks often don't even make an attempt to remember password an put them on sticky notes in front of the screen. (At it can still get worse...) I think for these people long alphanumeric passwords are the best.

I don't see why you should limit the length of a password.

Exactly. In any way in fact. A special char password of 8 char is not more secure than a a-z phrase of 20 long.

I think there is some sense in having a lower limit around 6-8 chars. No matter how many special characters you use, it won't be strong if it's too short.

The upper limit of 64 chars is just something that I copy-and-pasted from an actual web app that I wrote some time ago. It works in most cases, but if I were to write the same app now, I'd probably remove the upper limit or make it very large. (By the way, bcrypt only hashes the first 72 bytes of your password [1], so make sure to do something like bcrypt(sha256(password)) if you plan on using longer passwords.)

[1] http://news.ycombinator.com/item?id=4515894

Reply on news.ycombinator.com