71

Good practice is not to unnecessarily restrict password length, so that appropriately-long passphrases (perhaps 35-45 chars for 6/7 dicewords) can be used. (See e.g. Should I have a maximum password length? where a maximum of 1K is suggested, to protect against DoS without restricting users' ability to set long passwords.)

bcrypt is also commonly recommended (see e.g. Do any security experts recommend bcrypt for password storage?, http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html)

It is also recommended to use a salt (random, and stored with the password hash) -- I believe 32-bits (4 characters) is often recommended. (I understand the salt-size rationale to be "enough that the number of combinations is much bigger than the number of user records AND is enough to make rainbow tables infeasibly large" -- 16 bits is enough for the second part but may not be enough for the first.)

But AIUI bcrypt only hashes 55 bytes -- with 4 chars for the salt that leaves 51 for the password.

I'm guessing that we shouldn't just bcrypt(left(password,51)) and ignore the last characters.

Should we just limit users to 50 characters in their password (enough for nearly everyone, but not definitely enough)?

Should we use something like bcrypt(sha256(salt+password)) instead, and allow up to 1K characters? Or does the addition of the sha256 (or sha512?) step reduce the overall security somehow?

Do scrypt or PBKDF2 have similar length restrictions?

(The last question is just for interest, really -- I realise that the space-hardness/FPGA-resistance, and relative newness of scrypt, and the GPGPU-resistance of bcrypt compared with PBKDF2 are far more important considerations in deciding which hash to use.)

Community
  • 1
Misha
  • 2,739
  • 2
  • 20
  • 17
  • 1
    I think you were talking about SHA-1 (which has a 160 digest output), you must discard this algorithm and use one in the SHA-2 family due to flaws in version 1. See the table here : http://en.wikipedia.org/wiki/SHA-1#Comparison_of_SHA_functions) – Shadok Aug 26 '11 at 14:54
  • 4
    32 bits is a bit low for a salt. To ensure statistical uniqueness, you should have a salt that can hold the user number squared. 64 bit salts are reasonable IMO. – CodesInChaos Jun 29 '12 at 11:02
  • BCrypt isn't limited to 50 characters, or 55 characters, or 56 characters. The original whitepaper mentions the maximum key length of 56 bytes. This was a misunderstanding based on the Blowfish maximum recommended key size of **448 bits.** (448 / 8 = 56 bytes). The algorithm can, and does, support up to 72 bytes. (e.g. 71 8-bit characters + null terminator). 72 comes from the Blowfish P-Box size, which is 18 DWORDs (18*4 = 72 bytes). The canonical OpenBSD implementation will truncate any UTF8 string that exceeds 72 bytes (even in mid-multibyte character, even forgoing the null terminator). – Ian Boyd Apr 19 '18 at 17:29
  • @Shadok I'm not sure how those flaws are relevant to password hashing. – forest Jun 30 '18 at 05:27

2 Answers2

44

Using a secure hash function to preprocess the password is secure; it can be shown that if bcrypt(SHA-256(password)) is broken, then either the password was guessed, or some security characteristic of SHA-256 has been proven false. There is no need to fiddle with the salt at that level; just hash the password, then use bcrypt on the result (with the salt, as bcrypt mandates). SHA-256 is considered to be a secure hash function.

The point of a salt is to be unique -- as unique as possible, so that no two hashed passwords use the same salt value. 32 bits are a bit low for that; you should use a longer salt. If you have n bits of salt, then you will encounter collisions (two hashed passwords using the same salt) as soon as you have more than about 2n/2 hashed passwords -- that's about 65000 with n = 32, a not too high value. You'd better use 64 bits or more of salt (use 128 bits and you can cease to worry about it).

Chris McKee
  • 105
  • 5
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • ... and luckily (or by design?) 64 or 128 bits (8 or 16 characters) of random salt with the 256 bits (32 characters) sha256(password) output does fit within the 55 char bcrypt() limit. Thanks. – Misha Aug 29 '11 at 08:34
  • 3
    Would the use of SHA384 improve anything over SHA256? – Jacco Oct 12 '12 at 12:10
  • 1
    @Jacco: not really, no. SHA-384 is also considered secure, but not "more secure" than SHA-256, because both are in the realm of "cannot break it" and there's no security level beyond that one. – Thomas Pornin Oct 12 '12 at 12:45
  • So, if I understand correctly, the increased digest length does not have any real value in this use case? – Jacco Oct 12 '12 at 13:10
  • 1
    @Jacco: indeed. Actually, the increased digest length has little value in general; SHA-384 and SHA-512 are there mostly to match the same overkill as what resulted in AES key sizes 192 and 256 bits (which are quite useless since AES-128 is already quite far in the "cannot break it" category -- the larger key sizes are now justified by invoking the distant threat of quantum computers, if they ever come into existence). – Thomas Pornin Oct 12 '12 at 15:51
  • You might want to remove the first line, as it was edited out of the question. Well, it was 6 years ago, but still! – Kyll Feb 15 '17 at 10:08
15

Bcrypt uses a 128-bit salt AND a 55 character (max) password. You do not need to add any other salt values; bcrypt handles that.

The designers of bcrypt felt that the 55 character limit on the password wasn't an issue since the hash has a 128-bit output. If your password is greater than 55 characters, the designers assumed that you are already providing more than 128-bits of entropy so this isn't a problem. On the contrary, the NIST guidelines would count this as only 77 bits of entropy. The NIST guidelines are based on the fact that pass phrases have less entropy per character than random passwords and on the assumption that users will use pass phrases for longer passwords. To better ensure that you get a full 128-bits of entropy, you could allow longer passwords and hash them using SHA-256 or SHA-384 to compress them to an acceptable length. You could also just simplify things by using scrypt or PBKDF2 which do not have length limitations. Scrypt is designed to be "memory hard" in addition to being computationally time-consuming; that would be my choice of algorithms.

Steven Alexander
  • 181
  • 1
  • 2
  • 1
    Do you know of an authoritative citation for your claim about the 55 character password limit? I haven't been able to find anything myself (beyond this answer). – Kenny Evitt Nov 10 '13 at 16:18
  • 1
    http://security.stackexchange.com/a/39851/29971 (which references this question) provides a link to the original spec. (https://www.usenix.org/legacy/events/usenix99/provos/provos_html/node4.html) – Curtis Mattoon Jul 03 '15 at 14:29
  • There is a second answer to that question, which explains that bcrypt is limited to 72 bytes, not 55 characters: https://security.stackexchange.com/a/184090/5119 – Dario Seidl May 19 '21 at 12:50