12.57. DD 57: LibEufin Bank Account Lockout & Recovery¶
12.57.1. Summary¶
LibEufin Bank should have password-based authentications lockout and recovery measures.
12.57.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 solution would be to have a per-user attempt counter that blocks password authentication after N attemps and a per-user 2FA submission limit.
12.57.3. Requirements¶
We must not disclose personal information about our users (email or phone number)
We must not allow unlimited number of 2FA requests, as sending emails and sms is expensive
We must not allow 2FA recovery flow (forgotten password flow), as this goes against multi-factor authentication
An attacker should not be able to block an account by knowing only the username, as its a public information
12.57.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.
12.57.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.
12.57.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 do not limit the number of challenges created, to allow a user to log in from multiple devices at the same time for example, so it’s possible for an attacker who knows a user’s password to create numerous token creation challenges. Consequently, using the current per challenge attemps counter is not enough, we will also have a per account token creation attemps counter that will only be reset when a password is changed or a token created.
12.57.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 those informations are acessible 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.
12.57.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.