fedora-infra / noggin

Self-service user portal for open-source communities to use over FreeIPA.
MIT License
108 stars 57 forks source link

Allow to disable OTP #579

Open xvitaly opened 3 years ago

xvitaly commented 3 years ago

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

Sorry, You cannot delete your last active token.

abompard commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Re-opening so that security experts can chime in.

abompard commented 3 years ago

@tiran Do you have an opinion on that?

tiran commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

abompard commented 3 years ago

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...

Mikaela commented 3 years ago

In general I would be all for forcing users to always have 2FA, but as these same credentials are used for https://pagure.io/ which doesn't have a field for 2FA authentication having unclear guidance on how to enter the token that is incompatible with password managers (or then I am not figuring out how to enter it with Bitwarden), I would seriously like to disable it.

I also cannot report this issue to Pagure, because Pagure's issue tracker is within Pagure itself. The error I am getting is "OpenID request was cancelled".

Screenshot of the problematic login page

Side note: the "Common Bugs" in the bottom middle has version number 33.

trev-dev commented 3 years ago

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 commented 3 years ago

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

trev-dev commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

Nevermind, I figured it out :)

orianflaust commented 1 year ago

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 commented 1 year ago

Nevermind, I figured it out :)

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

VelocityDesign commented 1 year ago

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 commented 3 months ago

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 commented 2 months ago

@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 commented 2 months ago

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

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[bot] commented 1 day ago

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