Lock a user's account after X unsuccessful login attempts

[ckarlof]

Per #222 (comment)

5. lock a user's account after "x" total unsuccessful consecutive login attempts. By moving to X consecutive failed logins instead of resetting the quota after 1 hour, we may thwart attempts for attackers to throttle login requests to stay under suspicion. A fine line between "security" and mass inconvenience.

[jbonacci]

👍 to this security feature.
But just how will we lock the account?
And how will we notify the user? through an email message?
or some message in the browser on the next attempt to login?

[pdehaan]

You should be able to reset the account by going through the password reset flow.

[pdehaan]

The code for this should be in Persona to check for X attempts in Y minutes.

[pdehaan]

/cc @jrgm Can you find the discussion or code in mozilla/Persona repo. Thanks.

[jrgm]

For reference, this is the bug for Persona mozilla/persona#2656 and the PR to implement mozilla/persona#3337. (I misremembered how it was done, and there is no time component; it's simply a count of consecutive failures and the user has to 'forget" their password to regain account access).

[dannycoates]

We can't just use the forgot password flow because wrapKb gets reset when you complete the reset. This would allow anyone to reset anyone's wrapKb by intentionally locking their account. Not cool.

[ckarlof]

I think we should at least get something basic in by train-08.

[ckarlof]

This does raise the question of whether our policies and algorithms on this are public.

[ckarlof]

What options do we have for notifying a client that they logged wrong too many times in a row?

This one?
status code 429, errno 114: client has sent too many requests

Does Android support this? @ncalexan?

[rfk]

status code 429, errno 114: client has sent too many requests

yep, that's broadly what this is intended for

[ncalexan]

@ckarlof Android will say something generic: "There was a problem."

See http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/locales/en-US/sync_strings.dtd#217

We can land better messaging for 31.

[dannycoates]

This does raise the question of whether our policies and algorithms on this are public

I intend to implement this and #520 as a separate service that the auth-server queries before handling the request. So it will be possible to have private implementations of these if we need to.

[ckarlof]

I intend to implement this and #520 as a separate service that the auth-server queries before handling the request. So it will be possible to have private implementations of these if we need to.

Just what I was thinking this weekend as well.

[ckarlof]

@dannycoates is this on your radar for this week? I think we need some bare bones disaster mechanism in place for Fx 29 GA.

[dannycoates]

@ckarlof we already rate limit by failed login attempts, 5 tries in 15 minutes, i.e. you can't login even with valid credentials during that time after 5 failures. I do plan on making that piece more robust this week. Do we need something that requires user intervention to unlock the account?

[ckarlof]

Right, #664. I'll close this then.

Do we need something that requires user intervention to unlock the account?

Not in general, but it would be nice if resetting the password reset the counts.

I'm going to open an issue to revisit these params for #664 before Fx 29 GA.

[ckarlof]

Take it to #680.