fix(security): use proper uuid for device token #1484
Conversation
This file contains hidden or 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 device tokens are supposed to be unguessable. They are meant to they help in not having to MFA constantly for devices, essentially a short-cirtuit to avoid needing MFA. So in sensitivity they are between your password and your MFA, therefore they are NOT meant to be precomputed from the username (as saml2aws does it today). If the device-token is easily guessable, then it defeats MFA, and users The current users of saml2aws live in a false sense of security when they allow remember-my-device (the default with saml2aws). With saml2aws using a predictable device token, it poses a security risk for any user using saml2aws, as it defeats using MFA. This fix aims at generating a UUID specific to the device saml2aws runs on and storing it as a secret (like storing the users password). This makes using 'remember device' safe.
Author
|
@tinaboyce I didn't find your contact info anywhere besides linkedin but I could not send you a message on LinkedIn because it's a paid feature 🙃 . I tried finding a proper channel to signal security issues, but couldn't find one. Tried reaching out to the top contributor, to no avail, didn't get a response in 2 weeks. I see he's not even a versent employee anymore. Anyway, this is relatively mild security hole IMHO, not immediately exploitable, but it significantly reduces the security posture of a user that uses MFA, they think they're safe, but the current state of device token handling in saml2aws completely defeats MFA, so you're only relying on password strength. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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 device tokens are supposed to be unguessable. They are meant to help in not having to MFA constantly for devices, essentially a short-cirtuit to avoid needing MFA. So in sensitivity they are between your password and your MFA, therefore they are NOT meant to be precomputed from the username (as saml2aws does it today).
If the device-token is easily guessable, then it defeats MFA, and the current users of saml2aws live in a false sense of security when they allow remember-my-device (the default with saml2aws).
With saml2aws using a predictable device token, it poses a security risk for any user using saml2aws, as it defeats using MFA.
This fix aims at generating a UUID specific to the device saml2aws runs on and storing it as a secret (like storing the users password). This makes using 'remember device' safe.