057-libeufin-bank-account-lockout.rst (4791B)
1 DD 57: LibEufin Bank Account Lockout & Recovery 2 ############################################### 3 4 :Design status: Accepted 5 :Implementation status: Implemented 6 :DD shepherd: TBD 7 :Historical contributors: Antoine A, Christian Grothoff 8 :First published: 2024-10-21 9 :Last substantive change: 2024-10-21 10 :Implementation evidence: libeufin (2024-11-15) 11 :Normative references: :doc:`../core/api-corebank`, :doc:`../libeufin/bank-manual` 12 13 .. note:: 14 15 The Core Bank API is normative for authentication and lockout behavior. 16 Deployment-level request throttling remains an operator responsibility. 17 18 Summary 19 ======= 20 21 LibEufin Bank should have secure token-acquisition lockout and recovery 22 measures for password-plus-2FA authentication. 23 24 Motivation 25 ========== 26 27 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. 28 We also allow unlimited creation of 2FA challenges, enabling TAN submission DOS attacks and 2FA brute forcing. 29 The design must limit per-user 2FA attempts without allowing an attacker who 30 knows only a public username to lock the victim out. 31 32 Requirements 33 ============ 34 35 1. We must not disclose personal information about our users (email or phone number) 36 2. We must not allow unlimited number of 2FA requests, as sending emails and sms is expensive 37 3. We must not allow 2FA recovery flow (forgotten password flow), as this goes against multi-factor authentication 38 4. An attacker should not be able to block an account by knowing only the username, as its a public information 39 40 Proposed Solution 41 ================= 42 43 We expect that deployments seeking strong security will enforce 2FA. Therefore, for our solution, we expect 2FA to be enabled for all accounts. 44 45 Token only auth and strong passwords 46 ------------------------------------ 47 48 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. 49 50 Account lockout 51 --------------- 52 53 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. 54 55 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. 56 57 We allow concurrent challenges so that a user can log in from multiple devices, 58 but cap the number of pending challenges and rate-limit message delivery per 59 account. A per-challenge attempts counter is not enough, so there is also a 60 per-account token-creation attempts counter that is reset only when a password 61 is changed or a token is created. 62 63 2FA endpoints 64 ------------- 65 66 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. 67 68 We can make them unauthenticated only for token creation challenges only: 69 70 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. 71 72 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. 73 74 TAN submission throttling 75 ------------------------- 76 77 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.