On 11/06/13 20:06, Eugen Leitl wrote:
Use a timing-independent array
comparison<http://rdist.root.org/2010/01/07/timing-independent-array-comparison/>.
It's an easy fix. I've made the same mistake before, which is why I always
look for it now.
the page says "Usually it's not, but if these were passwords instead of
cryptographic values, it would be better to hash them with PBKDF2
<http://en.wikipedia.org/wiki/PBKDF2> or bcrypt
<http://www.mindrot.org/projects/py-bcrypt/> instead of working with
them directly."
if you are indeed comparing passwords thru their
hashed/bcrypt'ed/pbkdf2'ed representations; you would now leak info
about whether or not those representations mach. You have essentially
shifted the problem to their hashes. I don't believe this is enough.
if users have simple password, this theoretically allows someone to
brute force password offline once attackers know the
hashed/bcrypt'ed/pbkdf2'ed representation (leaked thru the side channel
mentioned above; e.g. timing). Yes it is better than plain text password
but not bullet proof. Let H be the representation of the password using
an (iterative) hash; then wouldn't it be better to compare H(N,The_pwd)
and H(N,attempt_pwd), where N is picked randomly each time the
comparison is performed?
This way, every time you compare pwds; the H representation changes, and
you cannot do offline brute force search.
BTW, scrypt is also better than bcrypt/pbkdf2 against pwd cracking.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
