Hacker News Reader

Comment by Rinum | Hacker News Reader

Which is why I like the method of increasing the login processing time per invalid login. It seems to be the easiest way to prevent most attacks.

1st attempt - 1 second sleep

...

nth attempt - n^2 second sleep

Something of that nature.

[edit] - the sleep time INCLUDES the time required to process the login credentials

View on HN

Doesn't this open up the opportunity to basically DOS someone from logging in to their own account?

If HN did this, I could theoretically have a ton of bots attempt to log in to your account, thus pushing your login timer ever higher, and making your login attempt fairly frustrating and slow.

Yes, it is.

so you can simply have a maximum delay, of say 10 minutes.

If you had to wait 10 minutes to login to a website every time, you'd very quickly stop bothering to log in.

You'd rule out all the legitimate users and only be left with people trying to break in. That strategy would only work on a honey-pot site.

10 minutes +1ms vs 10minutes +2ms can still leak information.

Ideally you want something like 3 seconds per password per IP starting the timer before you look up the password.

This only prevents brute-force password guessing, it doesn't solve the problem of the timing attack. Especially on passwords, which don't change very often. A patient attacker would try only a few attempts at a time, get timing info, then wait out the cooling period until the penalty is back down to 1 second of sleep, then repeat. Each time they gain more information which can all be put together to complete the attack.

With the 1 second sleep (for the first attempt) I was thinking of something along the lines of this:

t1 = time();

/* Perform login credentials check, if okay return */

loginattempt = n;

sleep(n^2 - time() + t1);

In other words, the sleep time includes the time it took to process the login info.

Reply on news.ycombinator.com