Hacker News Reader

Comment by billyhoffman | Hacker News Reader

"Maximum password length should not be set too low, as it will prevent users from creating passphrases. Typical maximum length is 128 characters."

Why would you ever have a maximum password length at all? bcrypt or (god forbid) your secure hashing algorithm of choice doesn't care about input length, and has a fixed output length to stick in a database. Why on earth would you limit the password length beyond anything so insanely large (1024, etc) to not even matter?

View on HN

Hashing passwords takes a lot of CPU resources. Django limited their password lengths to a maximum 4,096 characters because of this: https://www.djangoproject.com/weblog/2013/sep/15/security/

The Django developers are wrong to blame PBKDF2 for this slowness. It takes just 1 second with an unoptimized Python PBKDF2 to hash a 1MB password, and probably 0.1 second or less with a native implementation. If they claim it takes 1 full minute, they must be doing something seriously wrong, like using a crappy parsing or serialization mechanism to pass a 1MB string around higher-level modules.

  $ time python -c 'import pbkdf2; print pbkdf2.crypt("a"*1000000,"XXXXXXXX")'
  $p5k2$$XXXXXXXX$hmAHZehesTpLs.pM3G4mKlHZI6/FMj.Y
  
  real	0m1.233s
  user	0m1.221s
  sys	0m0.012s

By default that uses 400 iterations, the current recommended is 10,000. Try it again with 10,000.

Indeed: 28 seconds with 10,000 iterations. I assumed Django was iterating 400 times. I was wrong. Thanks for correcting.

Django have been upping the iterations in each release, it's 15,000 in 1.7 and by 1.9 will be 24,000. 500 password checks saturates a core i5 4670 for 25 seconds: http://tech.marksblogg.com/passwords-in-django.html#why-are-...

You could still just truncate. (But what is the use case for a 4 megabyte password anyway... keys aren't even that long)

Certain companies (Fidelity.com, looking at you!) enforce a ridiculously SHORT password max length. 12 characters? I'm laying odds that they're not hashing passwords at all.

And then we come to the companies that disallow characters that could be used for SQL injection. Those companies frighten me the most..

Because `bcrpyt` only accepts 72-bytes, (so abstractions ignore everything after 72 characters).

Example: http://3v4l.org/4lGu3

bcrypt has a maximum input length of 72 bytes:

https://www.usenix.org/legacy/events/usenix99/provos/provos_...

I suppose one could split the input into 72 byte chunks, hash each chunk and then combine again. Either store that, or rinse-and-repeat until you end up with one final hash.

> I suppose one could split the input into 72 byte chunks, hash each chunk and then combine again

This sounds like a recipe for screwing something up and opening yourself up to some kind of weird attack. I'm not enough of a crypto expert to know what the downside of this would be but it's more mucking around with crypto that I would be comfortable with.

You should first SHA-512 the password (to get a uniformly-64-byte string) and then apply bcrypt to that.

> bcrypt or (god forbid) your secure hashing algorithm of choice doesn't care about input length

bcrypt itself accepts a maximum key size of 56/72 bytes (depending on stage) as per http://en.wikipedia.org/wiki/Bcrypt#User_input

To a user it may not matter (they won't know what is being truncated) but from a systems design POV you should limit the unnecessary. Why let users POST 1MB text strings to your server if you're just going to discard them?

Such a low maximum length does not make a lot of sense, but say a limit of 1024/2048 seems reasonable. The amount of time it takes to compute a hash is proportional to the length of the input and you do not want to facilitate a DOS attack.

to avoid an attack where a user submits an absurdly long passphrase to the auth system, that it crashes?

Reply on news.ycombinator.com