Hacker News new | comments | show | ask | jobs | submit login

bcrypt as specified is limited to 72 char passwords [1]. That may not matter for most applications where nobody is using more than 72 characters, but it's sad that one of the leading password hashing systems has such a built-in limitation.

[1] bcrypt, the passphrase-handling part being eksblowfish, takes the user passphrase and turns it into the array of 18 32-bit (4 byte) subkey values blowfish needs for encryption. 18 * 4=72 so that's where 72 comes from. Increasing that limit requires pre-hashing the passphrase down to 72 bytes or less, or chaining multiple bcrypts using each 72-byte chunk of the passphrase. Either of which makes it no longer bcrypt. The problem with pre-hashing is that there is no standard; every implementation uses some arbitrary hashing algorithm. It also adds complexity to implementations.

First, nobody has a 72 character password. Second, at some point, the length of the password stops being the dominant factor in brute-forcing the hash, as Mazieres points out in the bcrypt paper.

Whose fault will it be if some naive application designer uses bcrypt on automatically constructed passphrases that have enough total entropy, but where the first 72 characters have very low entropy? It might be obvious to people who have looked at bcrypt that you should never do that, but someone may expect it to behave like any other hash that accepts arbitrary length input, and that could be catastrophic.

I would prefer that every hash function, including one that's designated as a password hash, utilize every bit of input to generate the output. If password length is limited, shouldn't it be done earlier, and not silently?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact