Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was messing around with bcrypt today and noticed something:

hashpw('testtdsdddddddddddddddddddddddddddddddddddddddddddddddsddddddddddddddddd', salt)
Output: '$2a$15$jQYbLa5m0PIo7eZ6MGCzr.BC17WEAHyTHiwv8oLvyYcg3guP5Zc1y'

hashpw('testtdsdddddddddddddddddddddddddddddddddddddddddddddddsdddddddddddddddddd', salt)
Output: '$2a$15$jQYbLa5m0PIo7eZ6MGCzr.BC17WEAHyTHiwv8oLvyYcg3guP5Zc1y'

Does bcrypt have a maximum password length?

share|improve this question
up vote 28 down vote accepted

Yes, bcrypt has a maximum password length. The original article contains this:

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

So one could infer a maximum input password length of 55 characters (not counting the terminating zero). ASCII characters, mind you: a generic Unicode character, when encoded in UTF-8, can use up to four bytes; and the visual concept of a glyph may consist of an unbounded number of Unicode characters. You will save a lot of worries if you restrict your passwords to plain ASCII.

However, there is a considerable amount of confusion on the actual limit. Some people believe that the "56 bytes" limit includes a 4-byte salt, leading to a lower limit of 51 characters. Other people point out that the algorithm, internally, manages things as 18 32-bit words, for a total of 72 bytes, so you could go to 71 characters (or even 72 if you don't manage strings with a terminating zero).

Actual implementations will have a limit which depends on what the implementer believed and enforced in all of the above. All decent implementations will allow you at least 50 characters. Beyond that, support is not guaranteed. If you need to support passwords longer than 50 characters, you can add a preliminary hashing step, as discussed in this question (but, of course, this means that you no longer compute "the" bcrypt, but a local variant, so interoperability goes down the drain).

Edit: it has been pointed out to me that although, from a cryptographer's point of view, the article is the ultimate reference, this is not necessarily how the designers thought about it. The "original" implementation could process up to 72 bytes. Depending on your stance on formalism, you may claim that the implementation is right and the article is wrong. Anyway, such is the current state of things that my advice remains valid: if you keep under 50 characters, you will be fine everywhere. (Of course it would have been better if the algorithm did not have a length limitation in the first place.)

share|improve this answer
I see. I read an article (here, actually) and it suggested using a server-side key along with the actual password and salt to generate the hash. What would you recommend as the key length, or for this use, should I just hash this first through something like crypt, then bcrypt? – d0ctor Jul 31 '13 at 13:38
An additional secret key is often called "peppering". The proper way is to compute a MAC on the password (with HMAC/SHA-256), using the secret key as MAC key; and then use the MAC output as "password" in bcrypt. HMAC/SHA-256 yields 32 bytes, which can be converted to 44 ASCII characters with Base64, within the limit of bcrypt. Moreover, HMAC will process arbitrarily long passwords, so that solves your password length issue as well. Be aware that using a key implies key management issues, which can be tricky (e.g. it interferes with backups and multi-frontend systems). – Tom Leek Jul 31 '13 at 13:50
Based on some testing just now, the Java bcrypt library jBCrypt has a 72 character limit. – Kenny Evitt Nov 10 '13 at 19:44

Yes, BCrypt has an upper limit of 72 characters. It's a limitation by the Blowfish cipher itself. One way to work around it is by using SHA-256 first and then BCrypt the result. In your case it would be something like

hashpw(sha256('pass'), salt)
share|improve this answer
According to "You're not really going to help people much who use long passwords by hashing first. Some groups you can definitely help. Some you can definitely hurt." – user6059 Jul 7 '14 at 12:43

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.