Crypt_blowfish 8-bit character mishandling | Hacker News Reader

Crypt_blowfish 8-bit character mishandling

seclists.org

40 pointsadulau11 comments

sigh - this happens just as I completed moving my web app to bcrypt and once enough time has passed for most of the passwords to be converted from my old salted-md5 method.

Most of the users are German or French speaking, so I'm sure there will be 8bit characters. I wonder whether just forcing them to use the forgot-my-password function is good enough or whether I will have to do extra work.

Still. Very detailed email and very helpful thread.

Spend x weeks updating passwords as the users log in, then for whoever hasn't logged in since then can be sent an email (maybe it doesn't have to exactly say "Login so I can update the passwords", just some sort of incentive to log in.

This depends entirely on what bcrypt implementation you use. The ruby gem for instance uses a version that's not affected (bcrypt.c from openbsd).

That man sure knows how to say he is sorry ;-).

This just goes to show that testing more and especially unexpected input is extremely important. Test driven development is nice, but in general it only tests for known valid data and what it should return but doesn't include the tests to verify that the program still behaves as expected when given invalid data or data that you aren't expecting it to receive.

I think this exact bug was fixed in another implementation of bcrypt [1] over a year ago.

[1] http://www.mindrot.org/files/jBCrypt/internat.adv

Can someone please help me understand the implications?

Crypt_blowfish handles 8(and higher?)-bit characters wrong on OpenBSD? Are other *nix systems also affected? Is the wrong character handling consistent?

I don't believe Crypt_blowfish == OpenBSD's implementation, they cannot interoperate as crypt_blowfish has this inconsistency with 8bit chars. You'd have to look up with distros use it, there are a number listed in his email but that might not list all affected platforms. I'd be looking into it if I was using PHP and blowfish.

crypt_blowfish (http://www.openwall.com/crypt/) is a 3rd party crypt() interface for non-openbsd systems that uses bcrypt. this problem doesn't affect openbsd.

according to another post (http://seclists.org/oss-sec/2011/q2/653) postgresql and php-suhosin use the same crypt_blowfish code, but may or may not be affected.

Anyone know if scrypt is similarly affected?

IIRC scrypt uses SHA256 and AES, not this blowfish implementation. So it's fine.

SHA-256 (in PBKDF2) and Salsa20/8 core.

Colin uses uint8_t* everywhere -- I think it's a standard practice in crypto code to use types that specify their size and signness right in the name and avoid using char/unsigned char directly.

Plus, scrypt doesn't do any encoding -- it's user's responsibility to serialize raw bytes into the suitable format.

Reply on news.ycombinator.com