Onboarding: checking both "enabled" and "primary" is confusing

[paulschreiber]

New users are having trouble completing the setup. They often check "primary" for TOP, but do not check "enabled."

When this happens, 2FA is not enabled, and they have a useless barcode in their authenticator app, which they have to remove.

It would be helpful if, upon form submission, when TOTP is checked as primary and a valid code is entered, then TOTP gets enabled.

[My1]

in my opinion all 2FA set as primary shoulld be automatically enabled I mean it IS primary after all.

also maybe make the enabled checkbox on primaries grey so they cant be disabled (and enforce that on the server as well)

[kasparsd]

@paulschreiber What are your thoughts on removing the primary selector completely? What if the plugin made the choice and offered the most secure method as the primary? We could also add filter for those who need to change it.

[paulschreiber]

@kasparsd That sounds great. I agree 100%.

[My1]

just make sure you dont need a faulure condition to switch. I recently was on a site which has webauthn as default when enabled for the login but to switch to normal login the webauthn had to fail, otherwise the button/link wouldnt appear. which basically made it impossible to login on my phone browser

[paulschreiber]

@My1 Where was that? That's pretty bad.

[My1]

devolutions. the makers of for example the wayk remote support tool. and yes it IS bad but at least they used webauthn which shows stuff better in the browser and handles errors nicer (like in many cases you do not even need a retry button, which this project in my opinion really could need), also they use it for passwordless (but not usernameless (resident keys), which is good, as credential management is non existent on most devices) which would be a nice additional scenario, username, submit, PIN/finger BOOM and you're in.

[wkhayrattee]

@paulschreiber What are your thoughts on removing the primary selector completely? What if the plugin made the choice and offered the most secure method as the primary? We could also add filter for those who need to change it.

I would not do that. It is not up to the plugin to judge which is the best scenario for the actual user. This taste varies among users at different level.

You just need to either have a primary option or an enable option, not both.
It's that way for many other systems like gitlab, google..etc.

[paulschreiber]

Thinking about this more, both the checkbox and the radio button should be removed. They clutter up the UI and don't confer any advantage.

Facebook/Google/GitHub let you register as many methods as you want, and the system starts with the most secure and gives you a "click/tap to try another method" prompt.

[blogtutor]

I agree that the individual "Enabled" options are unnecessary, and confusing enough that it can lead to misconfiguration. Though if the "Enabled" option is removed for each method, there will need to be an overall "Enabled" setting to turn Two-Factor on (or off) for individual users.

• Email should always be enabled automatically since the email address is always known*
• TOTP should be enabled once configured**
• Security Keys should be enabled if any keys are registered**
• Backup codes could be enabled once the verification codes are generated (and disabled if codes are deleted or used up)

*I could see a case for having a Disabled option on email, available once other methods are configured, so that a user can further increase security if they choose to disable those methods.

**Of course, TOTP and Security Keys would then need to auto-disable if the configuration is removed.

FWIW, I'm guessing most user's preferences would likely be:

1. Security Key (since that's by far the easiest to use each time)
2. TOTP (If a user sets this up, they likely prefer it over email)
3. Email
4. Backup Codes

[blogtutor]

Also for any changes here, it would make sense to consider automatic backup code generation - #292

[akwala]

When first enabling TOTP for a user, I found that entering the TOTP (from authenticator app) and clicking Submit only works as expected if the Enable checkbox is not checked and/or the Primary radio button is not selected. If those are checked/selected, nothing happens when Submit is clicked after entering the generated TOTP.

If UI elements need to be set in an order, they should only be available/modifiable when it's their turn to be set.

[mbaierl]

Any update on this bug?