Account Lockout/Whitelisting

[nullstyle]

As part of the wallet v2 design, we would like to improve our system's response to online dictionary attacks.

Now that the anonymization of a db record is no longer a design goal for the wallet server, we can co-locate the username with the encrypted blob. This lets correlate a login attempt to a specific user account, allowing us to detect online dictionary attacks against a single account.

Tasks for this ticket:

• Record login attempts (failed and successful) with a timestamp in an expiring redis list (or sorted set)
• Use login audit trail to determine if we should return the wallet data upon successful login attempt
• Implement IP whitelist system to allow time-limited login from whitelisted ips
• Successful login (whether the account is locked out or not), aborts a TOTP-removal request
• TOTP-enabled accounts are not subject to lockout (an attacker would have to make 1 million attempts per 30 seconds to compromise the account)
• Stex logging of audit log events

Login Audit Log design

For each username, and for each ip we see, we will maintain a time-limited login audit log. This audit log will hold three types of entries at first: (timestamp, AUTH_BAD), (timestamp, AUTH_GOOD), (timestamp, WHITELIST_IP, ip).

Overall, the sorted set we store these tuples in has a configurable TTL (which is extended everytime we push onto the set), and in addition we expire old records using ZREMRANGEBYSCORE to help control the size of each log.

At the time of a login attempt, we can refer to this audit log to determine whether an account is locked out

Account Lockout Design

Accounts with no prior audit log data get N free attempts (configurable via config.js). Each login attempt is kept in the log for M minutes (also configurable).

If the audit login has > N AUTH_BAD records, we enforce a minute delay between attempts, greatly reducing the rate at which a brute force can proceed.

At the moment of lockout (i.e. after the 3rd failed login attempt), we notify the user via email that we have locked out their account because of too-many failed login attempts. Open question: how do we prevent this from spamming the user's inbox? Do we limit it to one warning per day?

The lockout notification email contains a link that when visited will push a WHITELIST_IP record onto the audit queue for that user. This will allow the attacked user to login (and potentially enable 2FA)

If an account is locked out, we perform all normal login processing, except at the final step we simply override the response to return a failed response. A good W parameter still add an AUTH_GOOD
record in the audit log, even if the account is logged out. This may allow us in the future to potentially resolve a lockout if the user provides enough good login attempt (i.e. enter password successfully 3 times to resolve the lockout).

Logging

In addition to the Login Audit Log based in redis, we should also ement logging events to the stex log that can be used for analytics in the future.

IP Whitelist design

When a login attempt is received for a given user, we check to see if there is a valid WHITELIST_IP in their audit log, allowing the attempt through if one is found.

When an account is locked out, we provide an email to the account owner with a link in it that allows them to whitelist their IP. This link contains a signed payload (to prevent forgery) that identifies the username that it pertains to, a timestamp that expresses the time at which the link expires (configurable via config.js).

As of the current design, we allow the link to whitelist multiple ips. In the future, we may bound this by some count.