141–144 of 144 posts
> MD5, SHA-1, SHA-256, SHA-512, et al, are not "password hashes." By all means use them for message authentication and integrity checking, but not for password authentication. Bullshit. MD5 is just fine, as long as you use the salt. Here, hack this: MD5(password + salt) = "b520542710812f347432232b2a1fba83" salt = "MD5 rules"
$ echo -n "Spiderpig1MD5 rules" | md5sum
b520542710812f347432232b2a1fba83 -
MD5 is broken.
Earlier quoted context omitted.
I'll make one more attempt. I don't think I can explain it any clearer than this: http://pastebin.com/MYT9kpgZ Here I model the server as a simple function that takes a password, hashes it, and compares it to a known digest with an '==' substitute. The function returns true or false, but also leaks information about how long the match was, through a simulated timing leak. This lets me identify the dictionary word tha…
No, I understand the attack you're proposing. I just don't think it works, or, for that matter, buys you much of anything. Some things a reader of this thread would want to know, to make sense of it: * C memcmp (which is what Python uses) is below the known measurement floor for remote timing. * With (many) repeated trials and statistical filtering, the floor is (IIRC, but just Google [crosby wallach timing]) hundred…
I didn't ignore the time limit. As long as login attempts are much slower than offline bruteforcing, all that matters is whether we need less attempts total. Since it lets you cut your attempts by some fraction with a corresponding constant cost, it always wins out for a large number of passwords. In the toy example it's about a wash if you assume 1000 samples per 'attempt'
I won't examine each of your plausibility objections, but I'll note that the case is identical when checking a HMAC. You shouldn't rely on those assumptions if you can avoid it.
Simply put, using a timing independent comparison is best practice both for checking MACs and password hashes, and I think it is wrong to dissuade people from doing so.
Earlier quoted context omitted.
No, I understand the attack you're proposing. I just don't think it works, or, for that matter, buys you much of anything. Some things a reader of this thread would want to know, to make sense of it: * C memcmp (which is what Python uses) is below the known measurement floor for remote timing. * With (many) repeated trials and statistical filtering, the floor is (IIRC, but just Google [crosby wallach timing]) hundred…
It was a toy example, it was not meant to capture the exact details of an attack. I didn't ignore the time limit. As long as login attempts are much slower than offline bruteforcing, all that matters is whether we need less attempts total. Since it lets you cut your attempts by some fraction with a corresponding constant cost, it always wins out for a large number of passwords. In the toy example it's about a wash if…
Earlier quoted context omitted.
The check of hash to input uses == which will shortcircuit and return quicker as you guess the leading digits allowing you to figure out what the hash is. (i.e. a timing attack)
Try to explain how you would actually conduct that timing attack to see why it isn't one.
I believe that point was well made, even though in a technical sense, the exact error was unfounded.