Hacker News Reader

Comment by robmil | Hacker News Reader

Instead of freezing the account until it's unlocked by customer service, why not just lock it for increasingly longer periods of time? 2 seconds after the third failed attempt, 3 after the fourth, 5 after the sixth, 10 after the seventh, etc.

Not too inconvenient for legitimate users trying to remember their passwords, but it surely makes bruteforcing impossible (if by the 1,000th attempt they're having to wait an hour between attempts).

View on HN

That would still enable someone to DOS your website. A better way IMHO is to limit the maximum timeout - say 1 or 10 seconds. This, compared with even simple passwords that have slighlty more than 1 000 000 combinations, would mean hackers need days or weeks to crack passwords, in this time you should be able to notice the attack.

You would only be able to DOS a individual accounts, rather than the whole website. Do it by IP address, sure at some point someone with a huge enough botnet will be able to crack an account. But is it likely that someone will use their entire botnet to crack a single user's password on some consumer service?

An alternative might be for the user to be able to request that the block is cleared, and for that process to send out an automated email; if the user clicks the link in the email, the block is cleared.

It's no less secure than a password reset and would mean that legitimate account owners can't be locked out of their accounts by attackers.

Depends on what you can do on that site. Around my part of the world:

* Phone/number that is redirecting a call pays for the redirected leg of the call

This leads to a lot of creative hacking on trying to program a phone to redirect calls to expensive service numbers or foreign numbers. And many operators lets you administer call redirection on their website

This. Instead of having a timeout after n-number of passwords, have a random timeout after each one (between 1 and 3 seconds). Not really a big deal for a user (you can hold the connection open, so the browser looks like it's waiting for a response, or put up a loading spinner) but makes brute forcing infeasible.

Reply on news.ycombinator.com