4 ms·

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.c

by marklit 12y ago

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/ https://www.djangoproject.com/weblog/2013/sep/15/security/

venaoy 12y ago
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
- Someone1234 12y ago
  By default that uses 400 iterations, the current recommended is 10,000. Try it again with 10,000.
  - venaoy 12y ago
    Indeed: 28 seconds with 10,000 iterations. I assumed Django was iterating 400 times. I was wrong. Thanks for correcting.
  - marklit 12y ago
    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-some-passwords-too-long-for-django http://tech.marksblogg.com/passwords-in-django.html#why-are-...
jamiesonbecker 12y ago
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..

by marklit 12y ago

venaoy 12y ago

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

Someone1234 12y ago
By default that uses 400 iterations, the current recommended is 10,000. Try it again with 10,000.
- venaoy 12y ago
  Indeed: 28 seconds with 10,000 iterations. I assumed Django was iterating 400 times. I was wrong. Thanks for correcting.
- marklit 12y ago
  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-some-passwords-too-long-for-django http://tech.marksblogg.com/passwords-in-django.html#why-are-...

jamiesonbecker 12y ago

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..