Allow to disable OTP

[xvitaly]

Once enabled, OTP cannot be disabled due to the following error:

Sorry, You cannot delete your last active token.

[abompard]

Yes, this is a security precaution. It is explained on the OTP creation page (in bold) that once you create an OTP token, you can't disable two-factor authentication.

[abompard]

If you have a GPG key in your account, you can however ask admins to delete your token by sending a signed email to admin @ fedoraproject dot org.

[xvitaly]

Yes, this is a security precaution. It is explained on the OTP creation page (in bold) that once you create an OTP token, you can't disable two-factor authentication.

I don't think this a good idea. The user should be able to manually disable it if needed. All services with OTP support allow this.

[abompard]

Re-opening so that security experts can chime in.

[abompard]

@tiran Do you have an opinion on that?

[tiran]

I don't have a hard opinion. If you implement the feature request, then you should protect it with an additional verification step, e.g. require re-authentication with a valid password and OTP.

FreeIPA doesn't let you remove the last token by default. You have to disable the last token plugin:

dn: cn=IPA OTP Last Token,cn=plugins,cn=config
only:nsslapd-pluginenabled: off

[ryanlerch]

IMO, here on on the noggin side, what we should do is make sure noggin works properly (and doenst show the warnings) if the lasttoken plugin is disabled in freeipa.

Then whoever is managiing the ipa instance noggin is interacting with can make the security decision to disable last token. (in the case of Fedora Accounts, this would probably rest on the security minded folks in the fedora-infra team )

[nirik]

The only case where I can see this being undesired by us is for users with sudo access. We want them all to make sure and have a otp token enrolled. If they don't someone could sniff or otherwise aquire their password and have access to everything they do.
Ideally, there would be some way to mark groups as 'otp required' and 'last otp cannot be removed', but allow no otp/removal by everyone else.

[abompard]

There's one issue, if we allow the deletion of the last token, we can't really prevent users from doing it without re-authentication. Noggin can add that step, but users can login to people.fp.o and do ipa otptoken-del, which will remove the token without re-auth.

[nirik]

Yeah, but in both cases they would have to have the token to login to do that right?

[abompard]

Yeah, but in both cases they would have to have the token to login to do that right?

Unless someone with an active kerberos ticket leaves their laptop unlocked to go to the bathroom or something...

[trev-dev]

I can neither sign into the fedora community forums or my account on fedora because I keep getting authentication errors. Just for clarity's sake, how should I enter my OTP in forms that have no OTP field?

[abompard]

@trev-dev You should append the OTP to your password when there is no dedicated field.

[trev-dev]

@trev-dev You should append the OTP to your password when there is no dedicated field.

For myself this works so long as it's a FreeOTP key. Bitwarden did not work.

It's worth mentioning that I cannot sign into Gnome Accounts with either OTP key. I'm not sure what the benefit to signing in on my desktop is, but it appears broken with OTP 🤷

[tiran]

Did you create your OTP token with additional options? Some OTP apps ignore extended options and do not supported HMAC-SHA256 or 8 digit OTPs.

[trev-dev]

Honestly couldn't tell you. If bitwarden gives you a choice I haven't found it. I just clicked the button.

It is a trivial problems as FreeOTP just works ™️. For the one form, that is. Not for Gnome

[trev-dev]

As per Bitwarden:

The Bitwarden Authenticator generates 6-digit Time-based One-time Passwords (TOTPs) using SHA-1 and rotates them every 30 seconds.

Not sure if this is helpful but there it is.

[VelocityDesign]

Hey! I recently enabled 2fa and have no idea how to put my authentication code with my password.
Should I do $password:$authkey, $password$authkey, or what?

[VelocityDesign]

Nevermind, I figured it out :)

[orianflaust]

Iam having trouble using my Fedora Account on Gnome,since i set OTP.

Now i cannot login via gnome-accounts, Login via Web just works fine.

As i read the last comments here, i hopefully tried using "$password:$otp" and "$password$otp" but that did not work.

And going trough Webbrowser to accounts.fedoraproject.org and disabling the last active token is not allowed.

Any Ideas?

[orianflaust]

Nevermind, I figured it out :)

Could i ask what exactly it was, that you figured out?

[VelocityDesign]

Nevermind, I figured it out :)

Could i ask what exactly it was, that you figured out?

I have no clue. If you want to get out and back in, you can email the fedora infra group.

[AJCxZ0]

Re-opening so that security experts can chime in.

As a self-identified security expert with significant experience in making life difficult for myself (and occasionally others - #1394) by using a wide range of the strongest available authentication on many hundreds of services in multiple environments using several tools, I can confidently assert that the option for a strongly authenticated user to disable a single TOTP authenticator is essential for migrating between TOTP authenticators and, in some cases, environments.

The same applies to passkeys and any other second factor for authentication. Only the complete loss of all credentials - password, passkey, TOTP, backup codes and maybe verified email address - should leave a most unfortunate user having to convince human admins to intercede to recover access.

[abompard]

@AJCxZ0 IIRC it's possible to disable TOTP tokens, but not the last one (bringing the user back to single factor auth). Migrating betweed TOTP authenticators should already be possible this way.

[AJCxZ0]

Migrating betweed TOTP authenticators should already be possible this way.

When both TOTP devices (in the general sense) are concurrently available in the same environment , this is certainly the case, since one device can be used to authenticate a session, then a second can be added and the first removed in that session.

In almost every other case this isn't an option. Being able to temporarily disable MFA allows password authenticated login and the addition of MFA in a new environment.
Such cases include

• environments with local secrets management,
• different secrets managers with no option to safely transfer seeds,
• temporary environments with no secrets management,
• anticipated loss of a secrets manager before a replacement is available, or
• actual loss of a secrets manager while an authenticated session remains available*.

I've experienced that last scenario more than once back when TOTP was effectively restricted to hardware devices which died and there were no recovery codes. While I now use multiple cloud sync'ed secrets managers with clients on multiple independent devices combined with local encrypted backups and blah blah, I strongly suspect that many folks are and will remain one lost or dead device away from unnecessary disaster.

[github-actions]

This issue is stale because it has been open for 60 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 7 days since being marked as stale.

[abompard]

Sorry for the autoclose.

[github-actions]

This issue is stale because it has been open for 60 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 7 days since being marked as stale.