Skip to content

Timing vulnerability? #42

Closed
Closed

Description

@corporealfunk

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?

Activity

  1. codahale commented on Jul 18, 2012

    @codahale
    Contributor

    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.

  2. waiting-for-dev commented on May 6, 2015

    @waiting-for-dev

    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 timingsafe_bcmp.c in py-bcrypt or password_verify() in PHP use constant time functions, following defence in depth policy.

    I just took this information from a post in security stackexchange:

    For hashing schemes such as Bcrypt, Scrypt, etc., timing attacks are irrelevant. Using comparisons such as == and === isn't a problem. Having that said, using constant time comparison is a good practice as part of a defence-in-depth policy. In fact, many Bcrypt implementations already used timing-safe comparison just in case (timingsafe_bcmp.c in py-bcrypt, for example).

    What do you think about it?

  3. tjschuck commented on May 6, 2015

    @tjschuck
    Collaborator

    @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:

    It's like saying holding an umbrella gives you a "slight advantage" over holding nothing over your head when a piano is dropped on you.

  4. waiting-for-dev commented on May 6, 2015

    @waiting-for-dev

    Ok, thanks for pointing me there :)

  5. codahale commented on May 6, 2015

    @codahale
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions