-
Notifications
You must be signed in to change notification settings - Fork 283
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timing vulnerability? #42
Comments
No. One of the desired properties of a cryptographic hash function is preimage attack resistance, which means there is no shortcut for generating a message which, when hashed, produces a specific digest. Finding a first-preimage attack for bcrypt would be surprising, to say the least. |
Hey, I have been worried recently about this issue. I understand the reason why it is not needed, but it seems that other language implementations like I just took this information from a post in security stackexchange:
What do you think about it? |
@waiting-for-dev See #43 for much more information about why this is unnecessary. Regarding "defense in depth" for this specific issue, @codahale said it best on #43:
|
Ok, thanks for pointing me there :) |
To be clear, I’ve personally softened my position since then. I don’t think using a constant-time comparison function adds any actual security, but if it makes people feel better (and therefore more likely to use bcrypt instead of rolling their own), the cost isn’t particularly high. I’m not maintaining the codebase, however, so I’ll defer to those who would actually bear that cost. |
I've been working on implementing bcrypt-ruby and have been reading about timing attacks, particularly your article here:
http://codahale.com/a-lesson-in-timing-attacks/
I notice that Devise (popular gem that uses bcrypt-ruby) implements a constant-time comparison algorithm in conjunction with bcrypt-ruby:
https://github.com/plataformatec/devise/blob/master/lib/devise.rb#L424
I also notice that bcrypt-ruby's BCrypt class inherits from Ruby's String class, and the BCrypt#== method simply calls up to super, thus comparing strings using Ruby's String#== method, which I assume is not a constant-time comparison algorithm.
Should BCrypt handle this constant time issue in it's comparison method?
The text was updated successfully, but these errors were encountered: