Timing Attack Security Risk: hash equality checks are not constant time

[ghost]

Line 94 of LambdAuthLogin/index.js simply check equality using 'hash == correctHash' but this is will make the function execution time be dependent on the number of correct characters in the hash. For more details on this vulnerability: http://codahale.com/a-lesson-in-timing-attacks/ I would recommend just creating a constant time equality check on the hashes that checks every character individually.

[ghost]

I am going to use https://github.com/SalesforceEng/buffer-equal-constant-time implementation.

[mikegchambers]

Hi Spannella,

Yes, but....

The timing attack your looking at requires the attacker to send progressively calculated hashes to the comparator. So for a thing like an HMAC (a message) this is bad, as the client sends the crypto hash message directly to the server code, and an attacker can go through each byte, watching the timing and gaining more and more certainty until they hit jackpot.

But this code works with passwords that are sent to the server and then hashed. As such an attacker can't step through the password one character at a time, as the resulting hash would be completely different each time.

In my opinion, adding a constant time comparator would not be a bad thing, just not all that necessary in this case. So I suggest this issue be closed. :)

[thewillhuang]

what about using bcrypt or scrypt?

[helloniklas]

@thewillhuang I modified to use bcryptjs instead as I also need to read parse.com passwords. Works well. But bcrypt is very much slower.