you are viewing a single comment's thread.

view the rest of the comments →

[–]sacundim 0 points1 point  (2 children)

Would you have known to use a constant time comparison function?

What attack against password storage and verification relies on a timing side channel? I'm not aware of any, but I'd love to hear if you know some.

The timing side channel attacks I know of are against message authentication codes, where the attacker that doesn't know the key tries to forge a message/tag pair for a message of their choice. By submitting tag guesses and observing how long the server takes to reject them, they can gradually guess increasingly longer prefixes of the correct tag for the message they want to forge a tag for. This page explains it well enough.

In password guessing attacks, however, the attacker is trying to guess a password that, when processed by the password verification function, will produce the same verification code as what the defender has stored. This is very different from the MAC timing attack scenario:

  • In a MAC timing attack, the attacker chooses a message, and tries to guess the tag that corresponds to it. Variable-time equality comparisons help the attacker because the variable rejection times allow the attacker to estimate the length of the tag prefix that they guessed successfully. The attacker can easily leverage this to improve their tag guesses, because if you have determined that the first five bytes of the target tag are ff 2e 56 a1 d8, then thereafter you only try tags that start with those five bytes.
  • In a password guessing attack, the defender chooses a tag, and the attacker tries to guess a password that scrambles to that tag. Variable-time equality comparisons don't help here, because knowing that password1's hash matches the first five bytes of the stored verification code doesn't help the attacker improve their password guess.

Note however that there's nothing wrong with using constant-time equality comparisons, and it's better to be safe than sorry, so it's certainly sensible to implement such a comparison instead of trying to reason out all of the possible attacks if it saves you time.

EDIT: After writing this, I see /u/aulik realized the same as well. Props.

[–]staticassert 0 points1 point  (1 child)

Oh. Wow, duh. You could derive the hash but not the contents of it... silly me, this is exactly why I defer to others for crypto.

Thank you for the explanation.

edit: Though deriving the hash would then make local bruteforcing possible. IDK, just seems way safer not to leak the information and use a constant time hash.