4 ms·
This is a fantastic read. Timing attacks are insidious and tend to crop it in the oddest places. I first learned of them when learning how to securely compare s
by jtchang 9y ago
This is a fantastic read. Timing attacks are insidious and tend to crop it in the oddest places. I first learned of them when learning how to securely compare strings (used a lot with passwords). A naive implementation means that you can easily guess if a character is correct depending on how fast the compare function returns.
- ksearch 9y agoI believe that you now know that every time you do this(comparing passwords as Strings) a puppy dies!
- ksearch 9y agoSorry. Is this crude? Don't really understand down votes.
- grzm 9y agoI suspect the downvotes are because the comment is pretty light on substance as well as being a tired meme. HN members typically value good, substantive, constructive comments and try to keep the signal to noise ratio up as best they can. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- ksearch 9y agoThank you.
- Franciscouzo 9y agoYou shouldn't be comparing plain text passwords anyway. You should be using a secure password hash, such as bcrypt, sure, you should use constant time comparison, but in this specific case, it won't really make you vulnerable to use normal comparison.
- ufo 9y agoNormal comparison is bad even if you are comparing hashes. Letting the attacker figure out the password hash allows them to attempt to crack the password through an offline brute-force attack running on GPUs.
- odonnellryan 9y agoI don't understand how this can be an issue. This is usually what happens: > User enters password > PW gets hashed > Hash gets compared to the DB I don't know of any same system that would allow you to compare a hash to a hash? Unless you have access to something you shouldn't, in which case it doesn't matter anyway, because you can probably just read the hashes.
- stordoff 9y agoIf the user knows exactly how the hashes are generated (I believe a random salt would prevent this), it could still be used to better target an online bruteforce, though other defences such as rate-limiting should still kick in. If, say, you submit a password with a hash that starts "b94", if the database doesn't use a constant time comparison, you can use the timing to figure out that the stored hash also starts with "b94" (statistically, given network etc. delays involved), meaning you can pre-filter your submitted guesses (i.e. bruteforce offline and only submit guesses that start "b94"). It's definitely a edge-case thought (and probably not worth worrying about unless you don't salt/rate-limit requests). I also don't know if the number of requests needed to determine the timing would actually be less than just making random guesses outright (intuitively it seems so because even if it takes a lot of requests it shrinks the search space at each step).