Something on password rate limits has been on my mind ever since watching
one of the Security Now episodes.
Rather than cut-off rate limits isn't it a better experience to use
something with a slow exponential/compound increase
Think about the case where the user has forgotten their password, they
remember its probably one of 6 passwords and they don't want to bother
resetting the password.
They start trying out their passwords, but once they it that last password
and are thinking (right, this HAS to be the one I used) they get hit with
an error saying that all of a sudden they have to wait 5 whole minutes.
Something instead based on increasing wait time a bit each time seams like
if tuned right could be a better experience.
- By the time the user hits their 5th password the wait time may have
reached 1min.
- That last password is only a tiny bit more than the wait they just had.
- It's still secure, brute forcing takes a lot of tries. So even though we
don't punish bots much for their first few tries, as they continue it just
gets worse and worse for them. By the time they hit a mere 100 they could
be waiting a half-hour before they can continue instead of simply 5min.
- Wait times below a certain threshold (one that the first 5 or so tries
would be below) could be either ignored or handled with sleep() so that
instead of forcing a discouraging error message on a user and making the
user do time tracking (something that is trivial for bots, so this is an
unhelpful negative to user experience) the login page only feels like it's
a little sluggish.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]
On Wed, 04 Apr 2012 00:54:58 -0700, Petr Bena
benapetr@gmail.com wrote:
> More:
>
> IP addresses which do N bad login attemps should be blocked from
> accessing login page for Z minutes (You have done too many bad login
> attempts, please wait 5 minutes before trying again)
> This would help to avoid bots who try to compromise account by trying
> random passwords
>
> The target user should be notified according to their personal config
> (They could specify if they want to be warned if someone is about to
> compromise their account or not)
>
> On Wed, Apr 4, 2012 at 9:43 AM, Petr Bena
benapetr@gmail.com wrote:
>> I have seen there is a lot of wikis where people are concerned about
>> inactive sysops. They managed to set up a strange rule where sysop
>> rights are removed from inactive users to improve the security.
>> However the sysops are allowed to request the flag to be restored
>> anytime. This doesn't improve security even a bit as long as hacker
>> who would get to some of inactive accounts could just post a request
>> and get the sysop rights just as if they hacked to active user.
>>
>> For this reason I think we should create a new extension auto sysop
>> removal, which would remove the flag from all users who didn't login
>> to system for some time, and if they logged back, the confirmation
>> code would be sent to email, so that they could reactivate the sysop
>> account. This would be much simpler and it would actually make hacking
>> to sysop accounts much harder. I also believe it would be nice if
>> system sent an email to holder of account when someone do more than 5
>> bad login attemps, in order to be warned that someone is likely trying
>> to compromise their account.