0

According this reference source code, the function SlowEquals

private static bool SlowEquals(byte[] a, byte[] b)
    {
        uint diff = (uint)a.Length ^ (uint)b.Length;
        for (int i = 0; i < a.Length && i < b.Length; i++)
            diff |= (uint)(a[i] ^ b[i]);
        return diff == 0;
    }

I got the author's point to use xor & or to make the compare-time to be

consistent, but now I'm quite confused about the BCrypt's password

verification, is it need to do the same thing to avoid timing-attack?

Or the bcrypt already been adjust to be consistent after hashing it?

So it just verifies the result with "=="?

Any ideas or document/articles about this? Thanks.

JimNeo
  • 23
  • 6

1 Answers1

1

Author of the source code is a little bit paranoid. Timing attack is a theoretical attack, applicable only when it is possible to measure precise timing. And he states this on his blog. If you are using bcrypt or PBKDF2 for password hashing in any web-client application, the timing attack is practically impossible. The network latencies make much more grey noise to reponse timings than the string comparison procedure would do.

Since you should setup your password hashing to be slow for attacker, yet reasonable fast for user (say 200ms for one hash), the difference in string comparison is nearly unmeasurable on classic PC.

If you are still concerned by timing attack, you can always add a random sleep just before string comparison.

Michal Klempa
  • 41
  • 1
  • 4
  • thanks for the point about "random sleep", i didn't think about that before, but draw back if i want to compare the byte, where should i get into the starting at? is it possible to change the bcrypt equation to the byte xor comparison? – JimNeo Mar 18 '15 at 15:19