diff --git a/rfd/0029-account-lifecycle.md b/rfd/0029-account-lifecycle.md index 31caa87a106f7..92274bfab6e57 100644 --- a/rfd/0029-account-lifecycle.md +++ b/rfd/0029-account-lifecycle.md @@ -56,8 +56,6 @@ domain names in the prefix about leaked tokens. * [ ] Each token can only be used one time successfully or unsuccessfully. * [ ] Teleport should store tokens hashed with `crypto/bcrypt` and compare using constant-time compare. Teleport should store the time when the tokens were generated alongside the hashed tokens. -* [ ] Trying a wrong token 3 times in a row should lead to a temporary account lock following -the same failed account login rate-limiting that exists for local users right now. * [ ] The reset endpoints should be rate-limited by account and IP to prevent brute-force scans. * [ ] UI should make it clear that these tokens are important and if lost, the account can not be recovered. * [ ] Set the following headers on the web page presenting the tokens: diff --git a/rfd/0158-account-recovery-protections.md b/rfd/0158-account-recovery-protections.md new file mode 100644 index 0000000000000..f51767007cf31 --- /dev/null +++ b/rfd/0158-account-recovery-protections.md @@ -0,0 +1,47 @@ +--- +authors: Mike Jensen (mike.jensen@goteleport.com) +state: draft +--- + +# Required Approvers +* Engineering @zmb3 && (@codingllama || @nklaassen) +* Product: (@xinding33 || @klizhentas || @russjones) + +# RFD 0158 - Account Recovery Protections + +## What + +This RFD addresses a flaw from a prior RFD [0029-account-lifecycle.md](0029-account-lifecycle.md) when an account is under a targeted attack. This RFD clarifies how accounts are recovered when they are being targeted to by an attacker trying to prevent authentication. In order to accomplish this we only need a small change in the product behavior, the removal of the account lock on failed recovery attempts. + +## Why + +The [Account Lifecycle RFD](0029-account-lifecycle.md) defines how an account can be recovered after the loss of credentials. However it does not ensure that an account is recoverable under the condition that it is under a targeted attack. + +Account authentication can (and should be) locked out after invalid attempts. Because passwords are user supplied, there are real brute force risks that must be considered. However this lockout mechanism can also prevent accounts from being accessible by the legitimate user. We must allow users access to their accounts even under conditions where they are under a targeted attack. + +## Details + +### Failed Auth Reset Mechanism + +In many applications (including Teleport) using a password reset will also reset any potential account auth lockouts. Because a user may have locked themselves out after failed attempts prior to the reset, this is a very intuitive UX. + +### Issues with RFD 0029 - Account Lifecycle + +Prior to this RFD the reset mechanism also incorporated a lockout after 3 failures. This means that if an attacker wants to prevent access for an account they simply need to deny these two mechanisms. A failed reset lockout combined with a failed authentication lockout means that a legitimate users will have no ability to access their account. + +### Fix + +Because reset tokens are not user controlled, and neither tokens nor MFA devices are able to be brute forced, this lockout on reset is unnecessary. We should remove this mechanism so that legitimate users who have control over reset tokens or associated MFA can maintain access even under attack conditions. + +### API Changes + +The API for retrieving and deleting recovery attempt records will be removed, as they exclusively support the now-obsolete lock mechanism. Additionally, the user status will no longer include a recovery attempt lock expiration. + +### Audit Events + +An event is already sent when an account recovery fails. That auditing will be preserved, no new metrics will be added. + +### Security + +Upon implementing this change, all accounts previously locked due to account recovery issues will be immediately unlocked, making them available for recovery. +