Hacker News new | ask | show | jobs
by borando 4495 days ago
Incidentally Bcrypt does have a 56 byte limit

This is incorrect; bcrypt has a 72-character limit. Try this in python:

  import bcrypt, sys

  salt = "$2a$10$2TmO7iAhRfimvNwvpBn.7e"
  print bcrypt.hashpw(sys.argv[1], salt)
Nearly identical 56 and 57-char inputs produce different hashes:

  $ python pass.py 12345678901234567890123456789012345678901234567890123456                                                                     
  $2a$10$2TmO7iAhRfimvNwvpBn.7e701F3mp2Z7fpuY/4lu6vUUkrlMEmMou
  $ python pass.py 123456789012345678901234567890123456789012345678901234567
  $2a$10$2TmO7iAhRfimvNwvpBn.7ejJV9jpN0Ahp2RmNAdUGaRxRZndRAs9y
Nearly identical 72 and 73-char inputs produce identical hashes:

  $ python pass.py 123456789012345678901234567890123456789012345678901234567890123456789012                                                     
  $2a$10$2TmO7iAhRfimvNwvpBn.7e9w2f6/fKQ2QBu1eaIXp4A1WheruxtGK
  $ python pass.py 1234567890123456789012345678901234567890123456789012345678901234567890123
  $2a$10$2TmO7iAhRfimvNwvpBn.7e9w2f6/fKQ2QBu1eaIXp4A1WheruxtGK
you can use longer bcrypt passwords by doing a SHA256 pass

True, but: Beware! Imagine you're doing bcrypt in C, and the first sha256 output byte is a 0-byte. bcrypt() sees the NUL / empty password and produces a hash trivially breakable by anyone aware of this issue. :-)

So I'd recommend doing Base64 on the sha256 hash, if you're using C and you want such long passwords with bcrypt. But plain bcrypt will give the best results.

Hopefully the above illustrates the general wisdom of avoiding DIY crypto of any kind.

edit: code formatting

1 comments

EDIT: I was attributing the 56 byte limit incorrectly to hashing, see the reply I made to this comment for what the limit actually seems to be.

Maybe it's changed but the paper which defined Bcrypt specifically states:

"Finally, the key argument is a secret encryption key, which can be a user-chosen password of up to 56 bytes (including a terminating zero byte when the key is an ASCII string)."

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

which is a subpage of:

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

To clear up my own confusion, the 56 bytes only comes in when using bcrypt for encrypting vs hashing, however the "72 character" password limit for hashing is actually 18 words of 32-bits.

http://www.gossamer-threads.com/lists/wiki/wikitech/430719#4...

"Note that much confusion on the web about key lengths with bcrypt ('72' vs. '56' bytes) comes from the fact that there are TWO algorithms called 'bcrypt' which both happen to use Blowfish. One is an encryption algorithm, and the other is a hash algorithm. While they share a common core component, the purposes are thereby entirely different. For the sake of the bcrypt HASHING/key-strengthening algorithm (which we care about now), the 72-byte input parameter is in no way a theoretical problem at all, even for non-Latin UTF-8 based passphrases which eat up 3 bytes per unicode point. The reason is because the text-based passphrase itself needs to 'somehow' be converted into 18 words of 32-bits each anyway. (If we were _encrypting_ then the 56 bytes limit for THAT algorithm would come into play.) Even if you restrict your attention to ASCII it would not be ideal to simply convert ASCII code points to a (zero-padded) juxtaposed stream of 32-bit chunks anyway, because, well for one thing, you would be throwing away entropy due to not using the upper 1-bit range in each char, not to mention the range of unavailable non-printable ASCII characters."