Skip to content

RFD 158: Description of how we should address a targeted account auth DoS #35533

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jentfoo merged 4 commits into from
Jan 9, 2024
Merged

RFD 158: Description of how we should address a targeted account auth DoS #35533

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
44dfcb8
RFD: Description of how we should address a targeted account DoS
jentfoo Dec 8, 2023
c78ee31
Update 0158-account-recovery-protections.md
jentfoo Dec 11, 2023
f3e1ba1
Add required approvals to RFD
jentfoo Dec 12, 2023
d618a7c
RFD 0158 Added API, Metric, and deployment details
jentfoo Dec 18, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 0 additions & 2 deletions rfd/0029-account-lifecycle.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down
30 changes: 30 additions & 0 deletions rfd/0158-account-recovery-protections.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
---
authors: Mike Jensen (mike.jensen@goteleport.com)
state: draft
---

# 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.
Comment thread
jentfoo marked this conversation as resolved.
Outdated

## 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.

@zmb3 zmb3 Dec 11, 2023

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We must allow users access to their accounts even under conditions where they are under a targeted attack.

Brute forcing a password and locking the account is also a targeted attack isn't it? Are you proposing any changes here, or are we okay with not allowing access during this type of targeted attack?

@jentfoo jentfoo Dec 11, 2023

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The password reset mechanism unlocks the account from failed password auth failures. Which is a common pattern since theoretically the user likely entered an incorrect password repeatedly before starting the password reset flow.


## 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.

@strideynet strideynet Dec 27, 2023

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What length are reset tokens at the moment ? Do we need to increase their length if we're removing the 3 attempt limit.

@jentfoo jentfoo Dec 27, 2023

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The length varies due to us using a combination of words. Each recovery code consists of 8 words. When considering how brute forcible this is, it's tempting to look at the character count (which on average is close to our max input length of 72 characters), but instead we need to recognize the word list is well understood. There are 7775 possible words. which means the probability per guess is (1/7775)^8 (result is 7.5E-32).

This is an extremely low probability, well outside of the possibility of brute forcing. Using a similar length fully random string would technically provide more entropy and brute force resistance, but considering the scale I don't feel that it's a necessary change.