3 ms·

I believe the Ruby example is incorrect: When checking a password's validity, you must use a constant-time comparison or else you are exposing a vulnerability t

I believe the Ruby example is incorrect: When checking a password's validity, you must use a constant-time comparison or else you are exposing a vulnerability to side-channel timing attacks. There is an open issue in Coda Hale's bcrypt repo about this: https://github.com/codahale/bcrypt-ruby/pull/119 https://github.com/codahale/bcrypt-ruby/pull/119 My stance on posting "best practice" articles is: you must follow all best practices in them. <Edited for clarity>

sarciszewski 11y ago
> I believe the Ruby example is incorrect Unfortunately, there's nothing I can do about that, unless someone can point me to an alternative that uses a constant-time comparison. I've left a comment on the pull request so that, hopefully, it can be merged. > (and likely others) Which others?
- astockwell 11y ago
  After re-reading the others in depth, all other examples appear to use appropriate comparison methods (knowing nothing of the underlying implementations). I've updated my comment to clarify. I see your team is actively posting on the bcrypt-ruby issue #119 as we speak, so I guess I'd say wait for the PR to merge, or manually implement the approach they've outlined to secure compare: https://github.com/codahale/bcrypt-ruby/pull/119/files https://github.com/codahale/bcrypt-ruby/pull/119/files
Freaky 11y ago
As mentioned elsewhere in the thread, this isn't a "you must", this is a "you might as well". Timing attacks depend on an attacker having control over the hash being compared (e.g. they have a HMAC in a cookie they're sending you, and they can adjust it character by character) - with randomised secret salts and server-side hashing, this isn't the case. The SCrypt example is the one I'm more concerned with. The defaults there are 1MB of RAM and 64-bit salts, both of which could do with increasing. I have an open issue on this: https://github.com/pbhogan/scrypt/issues/25 https://github.com/pbhogan/scrypt/issues/25 As it is, the example would probably be better as this: password = SCrypt::Password.create(usersPassword, salt_size: 32, max_mem: 16*1024*1024) You'll be pleased to know SCrypt::Password#== is at least constant-time.

sarciszewski 11y ago

> I believe the Ruby example is incorrect Unfortunately, there's nothing I can do about that, unless someone can point me to an alternative that uses a constant-time comparison. I've left a comment on the pull request so that, hopefully, it can be merged. > (and likely others) Which others?

astockwell 11y ago
After re-reading the others in depth, all other examples appear to use appropriate comparison methods (knowing nothing of the underlying implementations). I've updated my comment to clarify. I see your team is actively posting on the bcrypt-ruby issue #119 as we speak, so I guess I'd say wait for the PR to merge, or manually implement the approach they've outlined to secure compare: https://github.com/codahale/bcrypt-ruby/pull/119/files https://github.com/codahale/bcrypt-ruby/pull/119/files

Freaky 11y ago

As mentioned elsewhere in the thread, this isn't a "you must", this is a "you might as well". Timing attacks depend on an attacker having control over the hash being compared (e.g. they have a HMAC in a cookie they're sending you, and they can adjust it character by character) - with randomised secret salts and server-side hashing, this isn't the case. The SCrypt example is the one I'm more concerned with. The defaults there are 1MB of RAM and 64-bit salts, both of which could do with increasing. I have an open issue on this: https://github.com/pbhogan/scrypt/issues/25 https://github.com/pbhogan/scrypt/issues/25 As it is, the example would probably be better as this: password = SCrypt::Password.create(usersPassword, salt_size: 32, max_mem: 16*1024*1024) You'll be pleased to know SCrypt::Password#== is at least constant-time.