Hacker News Reader

Comment by tptacek | Hacker News Reader

Defaults to bcrypt with a cost factor of 10. A totally sane default. The interface is clear, simple, and easy to audit for. This is a definite step forward.

View on HN

Auditing bcrypt (OpenBSD Blowfish) hashed passwords with JtR is much less satisfying than auditing md5 hashed passwords ;) Joking aside, I agree that this is a good move in the right direction.

Yeah, I'm just saying, the new standard password hash has a simple function signature; it's now easy to take a new PHP codebase and quickly check it to see if they're doing something wacky with passwords.

Read the comments. Users are already questioning these totally sane decisions and asking about ways to circumvent it.

It's PHP. They obviously wanted a broken language. Now the devs are taking that away from them.

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?

Looks very similar to the API in Laravel. [1]

I'm always happy to see PHP moving forwards like this. Baby steps towards better practices!

http://laravel.com/docs/auth/usage#hash

Plus the salt seems to be concatenated in the hash. Very cool and user friendly.

How long do you anticipate a cost factor of 10 being reasonable for?

Reply on news.ycombinator.com