There is an open issue in Coda Hale's bcrypt repo about this: 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>
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
As it is, the example would probably be better as this:
password = SCrypt::Password.create(usersPassword, salt_size: 32, max_mem: 16*1024*1024)
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?
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