fix(passcodes): user enumeration on invalid passcodes #3054
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Okta will only allow a maximum of 5 attempts for passcodes before giving an errorm where the user will be redirected to the sign in page/ However if a user doesn’t exist in Okta, we fake this functionality to always show an passcode error, however we don’t keep track of the number of attempts. This means that you can work out if an account exists or not, by attempting to submit a passcode more that 5 times on the sign in/password reset flow. If you’re able to submit the code more than 5 times, then the user doesn’t exist in Okta, if you’re not able to submit more than 5 times then the user exists in Okta. Essentially we need to replicate this behaviour for user’s who don’t exist in Okta, by keeping track of how many times the code was submitted. This commit does this by adding and incrementing a `passcodeFailedCount` on the `EncryptedState` cookie. Then when we reach 5 attempts (or more), we redirect to the expired page, in order to replicate this behaviour for all scenarios.
On a redirect to an expired page we should clear the encrypted state cookie from all IDX API values in order to reset it.
…reset-password Previously when the passcode had expired, or had been incorrect multiple times, we'd redirect users to the older `/welcome/expired` page for create account (register), and `/reset-password/expired` for reset password. The problem with these pages is that the copy and UX was more suited to when a link rather than code had expired/invalidated. Instead we now take the same approach as taken on the Sign In page, where we redirect back to the initial page the user took the action on, but show an error with context saying their code had expired, and to receive a new one instead. We also add cypress tests to cover this behaviour as they previously didn't exist!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Okta will only allow a maximum of 5 attempts for passcodes before giving an errorm where the user will be redirected to the sign in page/
However if a user doesn’t exist in Okta, we fake this functionality to always show an passcode error, however we don’t keep track of the number of attempts.
This means that you can work out if an account exists or not, by attempting to submit a passcode more that 5 times on the sign in/password reset flow. If you’re able to submit the code more than 5 times, then the user doesn’t exist in Okta, if you’re not able to submit more than 5 times then the user exists in Okta.
Essentially we need to replicate this behaviour for user’s who don’t exist in Okta, by keeping track of how many times the code was submitted.
This commit does this by adding and incrementing a
passcodeFailedCounton theEncryptedStatecookie. Then when we reach 5 attempts (or more), we redirect to the expired page, in order to replicate this behaviour for all scenarios.What does this change?
How to test
How can we measure success?
Have we considered potential risks?
Images
Accessibility