Ask HN: Which login method do you use?

Post by tptacek » Thu, Apr 23, 2009, 6:37 PM UTC

lsc wrote: post #39

tptacek wrote: post #29

Earlier quoted context omitted.

If the password is hashed well, with stretched SHA1/SHA256 or (better yet) bcrypt, then yes: breaking the hash would involve a significant advance in cryptography.

hm? I'm trying to say that once you have the hash, you can run a dictionary attack against it without any advances in anything. I can use whatever procedure the server uses to verify logins, and just try passwords. You can make the dictionary attack more expensive by using an expensive hash like bcrypt, but that's going to slow down your app, too. (http auth re-authenticates every page load.) so really, you can't mak…

Post by tptacek » Thu, Apr 23, 2009, 6:46 PM UTC

lsc wrote: post #42

tptacek wrote: post #41

Earlier quoted context omitted.

You're not thinking this through. In no well-designed web application is password checking in the 80/20 hotspot of performance. In fact, if it's within a light year of mattering to performance, you've done something horribly wrong. The point of adaptive hashing is that doubling the cost of the hash on the serverside adds negligable overall cost, but doubling the cost of the hash on the attacker's side doubles their c…

hmm? http basic auth checks your password on every request. you can do auth other ways, (but you need to be very careful.) but that's how http basic auth works. the attacker can check one word from her dictionary in the same amount of time it takes you to authenticate one user for one page. if you make that check take longer than 50ms, it will start slowing down your webapp. at 50ms, an attacker can check 40,000 word…

Post by lsc » Thu, Apr 23, 2009, 7:02 PM UTC

tptacek wrote: post #43

lsc wrote: post #42

Earlier quoted context omitted.

hmm? http basic auth checks your password on every request. you can do auth other ways, (but you need to be very careful.) but that's how http basic auth works. the attacker can check one word from her dictionary in the same amount of time it takes you to authenticate one user for one page. if you make that check take longer than 50ms, it will start slowing down your webapp. at 50ms, an attacker can check 40,000 word…

Don't use basic auth, lsc. [Edit] I regret even conceding this point. Even if you use basic auth, the tradeoff here is not complicated.

Post by decode » Thu, Apr 23, 2009, 7:27 PM UTC

lsc wrote: post #42

tptacek wrote: post #41

Earlier quoted context omitted.

You're not thinking this through. In no well-designed web application is password checking in the 80/20 hotspot of performance. In fact, if it's within a light year of mattering to performance, you've done something horribly wrong. The point of adaptive hashing is that doubling the cost of the hash on the serverside adds negligable overall cost, but doubling the cost of the hash on the attacker's side doubles their c…

hmm? http basic auth checks your password on every request. you can do auth other ways, (but you need to be very careful.) but that's how http basic auth works. the attacker can check one word from her dictionary in the same amount of time it takes you to authenticate one user for one page. if you make that check take longer than 50ms, it will start slowing down your webapp. at 50ms, an attacker can check 40,000 word…

Post by lsc » Thu, Apr 23, 2009, 7:47 PM UTC

decode wrote: post #47

lsc wrote: post #42

Earlier quoted context omitted.

hmm? http basic auth checks your password on every request. you can do auth other ways, (but you need to be very careful.) but that's how http basic auth works. the attacker can check one word from her dictionary in the same amount of time it takes you to authenticate one user for one page. if you make that check take longer than 50ms, it will start slowing down your webapp. at 50ms, an attacker can check 40,000 word…

On average, the attacker will have to search half of the hash space to find a given password. So, your 40,000 searches is way too small as long as you require more than 2 character passwords. If you assume lowercase + uppercase + numbers for the passwords, and require at least 6 characters, you get (26 + 26 + 10) ^ 6 = 56,800,235,584 combinations searching half of that would be about 28 billion combinations. At 50ms…