-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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.
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
Remove account lockout from failed recovery attempts #35325
Conversation
The PR changelog entry failed validation: Changelog entry not found in the PR body. Please add a "no-changelog" label to the PR, or changelog lines starting with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jentfoo Can you link me to the RFD where this change was discussed and approved?
@russjones The only RFD changes are the removal of the requirement from the existing RFD. As mentioned in the description I opened this PR to prompt exactly that type of discussion. To reiterate the motivation for bringing this change up for discussion:
Let me know what additional details you would like to have captured, and what your thoughts around this change are. Thank you! |
@jentfoo Is this tied to a compliance goal or issue that will reach it's SLA if not addressed? |
@russjones There is a potential DoS risk here in that a user can be targeted and prevented access to their account. However we have not filed a report against it yet. I wanted to submit this PR for discussion and to explore if this is something we can improve. If you would like me to file an issue to link to this, I can do that. I just thought this was a better way to open up the discussion. |
@russjones The report that motivated this PR is now filed under https://github.com/gravitational/security-findings/issues/75 Let me know if you have any additional questions, or feedback on this change. Thank you! |
@jentfoo Please propose changes via our RFD process if you want to change the behavior of Teleport. |
@russjones I submitted the RFD under the PR here: #35533 The RFD is fairly light in content because this is a relatively isolated change, but hopefully it will provides a better description of why we want to make this improvement. Please let me know your thoughts and questions, thank you! |
daf5c3f
to
c4fabf6
Compare
@zmb3 and @codingllama, I have partially updated this PR. This will depend on the I would appreciate a look around the API changes (mostly captured in the most recent commit). I believe I have removed all possible API as discussed in the RFD. I have kept the |
🤖 Vercel preview here: https://docs-lmolodche-goteleport.vercel.app/docs/ver/preview |
🤖 Vercel preview here: https://docs-laqayemcy-goteleport.vercel.app/docs/ver/preview |
(gogoproto.nullable) = false, | ||
(gogoproto.jsontag) = "recovery_attempt_lock_expires,omitempty" | ||
]; | ||
reserved 5; // removed RecoveryAttemptLockExpires after lockout was removed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually I see these reserve blocks at the top of the message - but unsure if that's a standard thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK this goes either way. Not sure if we have a consensus.
9f8fb88
to
c5fbce0
Compare
🤖 Vercel preview here: https://docs-kxlh7p8g5-goteleport.vercel.app/docs/ver/preview |
244f60c
to
b44adb9
Compare
🤖 Vercel preview here: https://docs-aac30f8qy-goteleport.vercel.app/docs/ver/preview |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're almost there.
🤖 Vercel preview here: https://docs-8oucg7azh-goteleport.vercel.app/docs/ver/preview |
/excludeflake * |
* Remove account lockout from failed recovery attempts This account lockout looks to be unecessary and potentially problematic. Recovery codes and recovery through MFA are not possible to brute force. In addition the potential to lockout an account from being able to use a recovery method could result in them being unable to unlock their account from other potential abuse cases (for example an attacker locking the account from failed password attempts). As discussed in the RFD (#35533) this includes the removal of all the API used for this locking mechanism. * accountrecovery: Update `WithLock` function names * accountrecovery: Combine verifyRecoveryCode and verifyRecoveryCodeWithRecord into one function
* Remove account lockout from failed recovery attempts This account lockout looks to be unecessary and potentially problematic. Recovery codes and recovery through MFA are not possible to brute force. In addition the potential to lockout an account from being able to use a recovery method could result in them being unable to unlock their account from other potential abuse cases (for example an attacker locking the account from failed password attempts). As discussed in the RFD (#35533) this includes the removal of all the API used for this locking mechanism. * accountrecovery: Update `WithLock` function names * accountrecovery: Combine verifyRecoveryCode and verifyRecoveryCodeWithRecord into one function
reserved 5; // removed "google.protobuf.Timestamp RecoveryAttemptLockExpires" after lockout was removed | ||
reserved "RecoveryAttemptLockExpires"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The removal of this field is making UpdateAndSwapUser fail.
If the stored user had the "recovery_attempt_lock_expires" field set, then the comparison always fails. That is because when we read and unmarshal the user the unknown field gets dropped, but the actual CompareAndSwap operation compares using the storage blobs instead.
Reverting the deletion, but keeping the field deprecated should serve as an immediate fix. Arguably, a better fix is to make sure CompareAndSwap compare apples-to-apples: either user vs user, or blob vs blob, but never user vs blob.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just submitted a PR to bring the field back: #37618
Thank you for finding this issue @codingllama!
This account lockout looks to be unnecessary and potentially problematic. Recovery codes and recovery through MFA are not possible to brute force.
In addition the potential to lockout an account from being able to use a recovery method could result in them being unable to unlock their account from other potential abuse cases (for example an attacker locking the account from failed password attempts).
For that reason I believe we should remove this lock as part of Teleport 15. Opening this PR for discussion, please highlight if there are any concerns which motivated this account lockout and which I may have missed.