DD 57: LibEufin Bank Account Lockout & Recovery

23.58. DD 57: LibEufin Bank Account Lockout & Recovery#

Design status:

Accepted

Implementation status:

Implemented

DD shepherd:

TBD

Historical contributors:

Antoine A, Christian Grothoff

First published:

2024-10-21

Last substantive change:

2024-10-21

Implementation evidence:

libeufin (2024-11-15)

Normative references:

Taler Core Bank API, Bank Setup Manual

Note

The Core Bank API is normative for authentication and lockout behavior. Deployment-level request throttling remains an operator responsibility.

23.58.1. Summary#

LibEufin Bank should have secure token-acquisition lockout and recovery measures for password-plus-2FA authentication.

23.58.2. Motivation#

Currently, we allow anyone to make any number of password login attempts. This exposes us to brute-force authentication attacks and DOS password hashing attacks. We also allow unlimited creation of 2FA challenges, enabling TAN submission DOS attacks and 2FA brute forcing. The design must limit per-user 2FA attempts without allowing an attacker who knows only a public username to lock the victim out.

23.58.3. Requirements#

  1. We must not disclose personal information about our users (email or phone number)

  2. We must not allow unlimited number of 2FA requests, as sending emails and sms is expensive

  3. We must not allow 2FA recovery flow (forgotten password flow), as this goes against multi-factor authentication

  4. An attacker should not be able to block an account by knowing only the username, as its a public information

23.58.4. Proposed Solution#

We expect that deployments seeking strong security will enforce 2FA. Therefore, for our solution, we expect 2FA to be enabled for all accounts.

23.58.4.1. Token only auth and strong passwords#

We have rules on minimum password length and expect administrators or users to use strong passwords. We also require token authentication for all endpoints, so password authentication is only used to obtain tokens.

23.58.4.2. Account lockout#

We will not block user accounts based on password authentication attemps, as this allows anyone to block an account knowing only the username. We expect deployments to put in place throttling for the token creation endpoint, and may in future thottle password authentication for every user.

If an attacker have the user’s password, he will also have to solve a 2FA challenge. If he fails to often, the account will be blocked and password authentication will not longer be allowed. Existing tokens will continue to work, so if a user is already logged in with another client, they will be able to reset their password and unlock their account. Otherwise, only the administrator can unlock the account by setting a new password.

We allow concurrent challenges so that a user can log in from multiple devices, but cap the number of pending challenges and rate-limit message delivery per account. A per-challenge attempts counter is not enough, so there is also a per-account token-creation attempts counter that is reset only when a password is changed or a token is created.

23.58.4.3. 2FA endpoints#

We will reuse the current 2FA endpoints and logic for token creation challenges. They are currently token-authenticated, which won’t work for token creation challenges.

We can make them unauthenticated only for token creation challenges only:

For POST /accounts/$USERNAME/challenge/$CHALLENGE_ID/confirm this is not a problem, as it requires knowledge of the username, the random challenge ID and the TAN code sent. This endpoint is also throttled, to many attemps invalidate the challenge.

For POST /accounts/$USERNAME/challenge/$CHALLENGE_ID, it requires knowledge of the username and the random challenge ID, but that information is accessible to an attacker knowing the user password that create a token creation challenge. This endpoint can disclose the tan channel and information (phone number or email address) to the attacker, enabling him to know how to attack the second authenticated factor. We can solve this by hiding or obfuscating the tan information for token creation challenges.

23.58.4.4. TAN submission throttling#

It is possible to have multiple 2FA challenges for the same account at the same time, allowing a user to log in from their phone and browser at the same time without these challenges clashing. This also means that a user can create an unlimited number of challenges and therefore send an unlimited number of emails/sms. The validity period, number of retramsission and number of trials are already capped per challenge, but not per user. We need to limit the number of pending challenges (not confirmed or expired) per user.