3 ms·

Crypt_blowfish 8-bit character mishandling

40 points by adulau 15y ago

X-Istence 15y ago
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.
pilif 15y ago
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.
- dekz 15y ago
  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.
- tedunangst 15y ago
  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).
losethos 15y ago
Signed characters for ASCII are silly. LoseThos uses unsigned. I made a promise of just ASCII, however, so I did not put extended ASCII in the font. It's trivial for international people to do so. The compiler allows extended ASCII for alphanumerics, though, it's untested much.
newman314 15y ago
Anyone know if scrypt is similarly affected?
- dekz 15y ago
  IIRC scrypt uses SHA256 and AES, not this blowfish implementation. So it's fine.
  - dchest 15y ago
    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.
Revisor 15y ago
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?
- dekz 15y ago
  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.
- there 15y ago
  crypt_blowfish (http://www.openwall.com/crypt/ 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 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.
martinp 15y ago
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 http://www.mindrot.org/files/jBCrypt/internat.adv

40 points by adulau 15y ago

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.

pilif 15y ago

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.

dekz 15y ago
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.
tedunangst 15y ago
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).

losethos 15y ago

Signed characters for ASCII are silly. LoseThos uses unsigned. I made a promise of just ASCII, however, so I did not put extended ASCII in the font. It's trivial for international people to do so. The compiler allows extended ASCII for alphanumerics, though, it's untested much.

newman314 15y ago

Anyone know if scrypt is similarly affected?

dekz 15y ago
IIRC scrypt uses SHA256 and AES, not this blowfish implementation. So it's fine.
- dchest 15y ago
  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.

Revisor 15y ago

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?

dekz 15y ago
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.
there 15y ago
crypt_blowfish (http://www.openwall.com/crypt/ 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 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.

martinp 15y ago

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 http://www.mindrot.org/files/jBCrypt/internat.adv