Repository navigation
Recovery authentication codes #8518
Replies: 9 comments 31 replies
|
Milestones should probably be removed. I presume "Recovery codes display and download screen" isn't the final product? |
|
I made an update. There will be download link , also when displayed the codes will be probably split in 3 columns. We will display also the remaining number codes in the account console |
|
@rh-iatanaso you mean the remaining number of codes right, not the actual codes themselves? |
|
Thanks and yes that is what I actually reflected in the discussion. I updated in my comment as well. |
|
the process is ........ |
|
I like that this proposal contains a detailed description and screenshots. Makes it easier to think through and provide feedback 👍 My notes on UI/UX:
|
|
Thank you for your feedback.
|
|
@jbman in the owasp reference I added, the suggested number was up to 10 but, the number is really arbitrary in my opinion probably anything between 5 and 30 would make sense for me at least. As I mentioned we can make it configuration if there is need for it. |
|
Thanks for the thoughts and the PoC!! I really like the feature! I agree with @jbman that the user should be able to enter any of the backup-codes. Maybe a way to know which code the user entered could be a list like this:
And then extracting the first two digits. This would increase the length of a backup code . Or we do it like in https://groups.google.com/g/keycloak-dev/c/SC1JvewgLwM/m/pIAS4-9pAwAJ and just try every code with a reduced number of iterations. Thanks for your work! |
|
I don't agree with having the option to enter any backup codes as it gives both a worse user experience as it's harder for the user to know what codes have been used and how many there are left, and also reduced security as an attacker can guess from many codes rather than a single one. It also is more costly (although that's insignificant really) as rather than compare a single code you need to compare multiple codes. |
|
When searching for "2FA recovery codes" with image search, it seems to best practice to provide multiple valid codes without enforcing linear use. Github, Google and Facebook do it like that. I also wonder why this is the established way. Of cause you can split your codes and store them at different places. You can hand one out to a trusted recovery person. You can print them and take all except one with you, instead of your phone. Many providers also allow to view the recovery codes when you're logged in (e.g. Github and Facebook do). Github tells me that my codes were "viewed X hours ago". If one time codes are used as 2FA replacement, this seems to be common practice. Maybe usability was preferred over best possible security. Github also brings me right to the 2FA settings, if I log in with a recovery code:
|
|
@rh-iatanaso thanks for putting this together, very concise and easy to understand proposal. I'm curious about the statement below: "When a user is prompted to authenticate the recovery authentication codes should be available as an option if already has another 2FA method configured. If OTP is disabled the user will be able to authenticate only with recovery authentication codes" Let's think about the following malicious user story: Please correct me if I'm wrong, but it seems that the adversary should be able to log in with the recovery authentication code, disable OTP and lock the user outside the app. Is that correct? |
|
@rh-iatanaso I'd suggest AIA for disabling OTP, plus the action of deleting the recovery codes. |
|
@abstractj Considering using AIA for disabling OTP will be change of prior behavior should it be separate issue ? |
|
For sure AIA for disabling OTP doesn't really have anything to do with recovery codes. So should be opened as a JIRA / bug. |
|
I just opened one - feel free to edit it: https://issues.redhat.com/browse/KEYCLOAK-19673 |
|
After looking into it some more , currently only Create/Update actions support AIA. CredentialTypeMetadata does not have support for update action. I think the issue above should handle the generic case to add support for Delete actions to use AIA. |
|
Great work and great proposal so far, thanks for that! I just try to get my head around the "Allow users to use recovery code as primary 2FA" - Part. Could you clarify that a bit? disclaimer: The following is more a "stream of conciousness" with a few questions inside from my side w.r.t. using the codes as primary 2FA: I imagine a user has not setup 2FA yet, but creates recovery codes (thus, leading to 2FA enabled for the login flow). potential options of "what happens" i think of: option 1: user gets noticed to re-create new codes (or setup an MFA device) before the codes are completely gone? option 2: user gets no notice, and has to reset his/her account after using the 15 codes. option 3: make the usage of recovery codes dependant on having set up a 2FA Generator/APP at least once So, as said, great work so far. Would be great if you could clarify the question :) |
|
I am concerned about using recovery codes as the primary 2FA mechanism, and I understand that it is a secondary use case, but it is something that I would say has very little value. The purpose of standard 2FA is "something you have and something you know," with the password being something you know. Recovery codes are explicitly made to be written down so that they become "something you have." I could see a valid use case for recovery codes if a user doesn't have a smartphone or physical token. When I used to work at an IT helpdesk, some users would not be able to utilize our recommended 2FA mechanisms due to this, and printed recovery codes might work for them. My concern occurs when a user is on an untrusted computer, like at a library or on a school PC, and they are unable to print or download the codes to a valid location (if they do not have a smartphone, they likely will not be able to capture a picture either). If this occurs on their last login they would be locked out. From my perspective, if the last 2FA generator or hardware token is removed, then the recovery codes should be as well. |
Ultimately this is another tool in the tool box that will help administrators to provide best experience for their users. |
For this case, it is necessary to make it clear that Recovery Codes are not removed when 2FA is removed or give the option for the user to disable both at the same time. I am not aware of a service that leaves Recovery Codes enabled when 2FA is disabled so proper user education will be key to preventing problems. |
|
I think Facebook and Twitter have on/off switch for 2FA which is more explicit, keycloak does not have on/off switch. But if the consensus is that we want to remove the backup codes if all the 2FA methods are deleted we can do that. But in general recovery codes + password will be better than just password if I just lost my phone and I need some time to procure new device. |
|
Keycloak doesn't currently have an option to "disable 2FA", but rather that is implicit when all 2FA authenticators are removed. I do agree that a switch to "enable/disable" 2FA could be useful, but that should be discussed as a separate thing to introducing recovery codes. |
|
Few more points from me besides what was already told here:
|
|
From your point-of-view: Would it be possible for users to set up multiple independent sets of recovery codes, so people can choose the set they have available at their current location? I would definitly warn the users in the UI that they have to have ALL recovery codes of a set available to securely recover a account - since I would assume the opposite. |
|
|
I noticed when viewing the codes one of the codes is wrapped on multiple lines, which is not great. Perhaps we should go with 2 columns instead of 3, then go down to 12 codes? |
|
In general number that divides but 2 and 3 will be better as starting point because it provides more flexibility you can have 2,3,4 columns . |
|
Can we go down to a single column if the width is not wide enough for the codes to be displayed on a single line? Would look quite daft if at lower res we have two columns and at the same time have codes spanning two rows |
|
In my designs for the next iteration, I have the numbered list being separate from the recovery codes so that the numbers can be right-aligned. This helps when the column contains both single and double-digit numbers (ex. 9 and 10 in the screenshot) and should prevent the beginning of the recovery code from being pushed to the right and consequently wrapping. Not sure how this impacts development etc., but this is just from the visual standpoint. |
|
This looks good and is much more idiomatic than my initial implementation :) Some remarks about how we currently use the original backup code implementation:
Regarding the generated codes:
|
|
Thomas,
We picked uppercase + numbers just to avoid that problem I (uppercase i ) , l ( lowercase L) , crockford-base-32-encoding might good to avoid the O(0) problem . |
|
The round of changes after review that affects the features include:
Everything else is a refactoring. See #8730 for full discussion. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Support for recovery authentication codes
Motivation
The base work around multi-factor authentication is defined in multi-factor-admin-and-step-up.md. However users need an easy alternative means of authentication if they are unable to generate a one time token. Currently, users with 2FA enabled who do not have access to the device configured with an authenticator application must reset their password, which disables 2FA and allows the user to authenticate. In the event that the user’s email account has been compromised, this renders 2FA useless as an attacker can reset the password, disabling 2FA, allowing access to the user’s account.
We would like to propose a solution which will deliver a functionality to generate recovery authentication codes that can be printed or stored in a safe location. Those recovery authentication codes can then be used when none of the other forms of second factor authentications are available, or potentially they can be used as a second factor authentication on their own. Quite a few of the authentication providers and websites have features that deliver similar functionality.
Use Cases
Design Proposal
Recovery codes will be configured as part of the Authentication flow.
Following requirements will be followed:
Implementation details
In order to enable the recovery codes the server administrator will register the ‘Required Action’ through the Realm > Authentication -> Required Action and enable the feature.
Information about recovery authentication codes will be available when managing users in the realm at Realm > Manage -> Users -> User -> Credentials. There will be a specific credential type. The number of remaining recovery codes will be available in the Data section.
The user will be able to create or remove recovery codes under the Two-Factor authentication section in the account console. The section will show the number of recovery codes available as well as the date that the recovery codes were generated. Notification messages will be displayed if the number of recovery codes left is under 3.
When a user is prompted to authenticate the recovery authentication codes should be available as an option if already has another 2FA method configured. If OTP is disabled the user will be able to authenticate only with recovery authentication codes.Specific recovery code number will be requested. Those would be requested in sequential order starting from 1.
UI Screens
For simplicity few screens can be found below.
Account console
Admin Console
Admin console >> User management
Database changes
There will be no database changes required. We are using the CredentialModel to store the credentials.
Resources
Notes
Recovery Codes entropy
Comparing to others:
All reactions