Implement account lockout after multiple failed login attemps

[fpietrosanti]

Improve brute force protection with lockout on admin user .

Currently is possible to keep going with a brute force on the admin user, even with the increased delay of #112 .

Due the high sensibility of the admin user, it has been decided that the admin user after a brute force must be locked-out.

After the admin is locked-out, the error shown to the end-user must inform him to use the gl-reset-password command line client, from within the linux.

The text instructing on how to change the password, must be translatable on the globaleaks client.

The amount of time to shown the error message have to be increased, to let the admin to read with calm the error.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[vecna]

umh, isn't this a DoS and/or a strong usability problem ? because I believe, in a media organization, "globaleaks node administrator" and "system administrator with console access" shall easily be different persons, and the node admin need to be independent

[fpietrosanti]

Given the admin must not login often (only whistleblower and receiver operate the system) and that brute force attacks are extraordinary events, i think that the overall usability impact is quite low.

[fpietrosanti]

Comments from Mario Heiderich on this ticket:

[8/24/13 4:06:44 PM] Mario Heiderich: As for #532: Might be a bit too radical - but why would the admin log in via web-form only anyway? [8/24/13 4:07:42 PM] Mario Heiderich: Maybe it makes sense to for example have the application run in dev and prod mode: In dev mode the admin can login (maybe using mail verification or alike) whilst in prod mode the login can only happen via console / cert installed in browser + web-form or similar [8/24/13 4:08:39 PM] Mario Heiderich: I agree with the assumption that admin logins need to take place rather rarely once the system is up and running. So why no general admin login lockdown after the app went to the suggested prod-state? [8/24/13 4:10:41 PM] Mario Heiderich: So, bottom line: lockout is a good idea - better than delays. And it should be even stricter and admin login web-only should be forbidden anyway once the app is "live"

[evilaliv3]

I've extended the scope of this ticket to apply to every autenticated user type.

Up to the current evaluations:

• The account should be locked after a certain number of unsuccessfull attempts
• Administrators and the User should be notified that the lockout happened.
• As subsequent attempt should inform the user that the account is locked and offered the Request Support" feature to get in touch with administrators

In relation to usability this lockout feature should be implemented only on users that do not have enabled the Two Factor Authentication feature. In fact considering the limited risk that the attacker could have access to the user phone, we could avoid to apply the lockout with reasonable security and avoid to 1) lock the real user out 2) notify and warn the user 3) warn and notify administrators