3 ms·
It's still a bit scary that they're apparently using some ad-hoc KDF (key derivation function) built from bcrypt and HMAC. bcrypt is a decent KDF, but there ar
by KMag 13y ago
It's still a bit scary that they're apparently using some ad-hoc KDF (key derivation function) built from bcrypt and HMAC. bcrypt is a decent KDF, but there are several ways to make a bad KDF from a combination of bcrypt and HMAC. For instance, concatenating bcrypt(salt, pw) and HMAC-SHA512(salt, pw) makes guessing passwords way too fast.
I'm hoping that all they've done is use bcrypt(salt, HMAC-SHA256(salt, pw)) to get around the bcrypt 72 character limit. However, using scrypt would have been better.
- nialo 13y agowhy does concatenating bcrypt(salt, pw) with HMAC(salt, pw) make guessing fast? Intuitively it seems like you'd still need to guess the bcrypt portion, making it no worse than just bcrypt.
- euank 13y agoWhy not just ignore the bcrypt portion? "Intuitively" it seems to me like you could just un-concatonate the two strings and guess at them separately, working on whichever you know to be easier.
- reedloden 13y agoHopefully, the 'salt' passed to HMAC-SHA256 is a pepper (preferably stored outside the database), not the same user salt as what bcrypt uses. As for scrypt, it definitely has great potential, but I still feel it's too new and not as well understood to be used 100% correctly in production by most folks (see also http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scryp...).
- azinman2 13y agoWhat's wrong with bcrypt?