Page MenuHomePhabricator

Allow OATHAuth users with 2FA already enabled to add / switch devices without disabling
Open, Needs TriagePublic

Description

When a user who has enabled 2FA visits Special:OATH, there is only one thing they can do: enter a TOTP code to disable 2FA altogether. This means if I want to use multiple 2FA token generator devices, I must set them all up at the same time.

If I want to add a new device, all the scratch codes need to be replaced and all my existing devices need to be set up once again. This is rather inconvenient.

This problem can be solved with one simple change. When a current 2FA user visits Special:OATH, there should be two options: "update two-factor authentication" and "disable two-factor authentication". If the user chooses "update two-factor authentication", simply take them back to the screen where the QR code is displayed.

With this change, a user can add devices (or view their remaining scratch codes) without resetting 2FA completely. I think the possibility to set up additional devices at a later date will encourage many more users to take up 2FA.

(I guess the long-term solution is to allow multiple devices with different TOTP secret keys, but that's a long-term goal.)

A note on security: There is no additional security risk in displaying the QR code and the scratch codes again, because an existing TOTP token is required for the user to view the codes.

GoogleFacebookTwitterMediaWiki OATH (as of now)
TOTP1 device (or secret) only, changing device invalidates previous TOTP deviceWhen user asks to add device, it asks for (human-remembered) password again and then shows same secretvia official Twitter app1 secret only, cannot see existing secret again
scratch-codes10 codes, user can see existing codes again without needing to regenerate10 codes, user can see existing codes again without needing to regeneratenone5 codes, cannot see existing codes again
other modesPhone call or SMS (allows multiple phone numbers; Google Prompt or U2F USB;SMS (allows multiple phone numbers); U2F USB/NFC keysconfirmation by email linknone yet
to change...need to log in then enter password again to access 2FA menuneed to enter password again to change any 2FA itemmay ask for confirmation of phone number or email addressneed extra 2FA secret or scratch code (but not password) after logging in

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 30 2017, 10:11 PM

What are the chances of this being implemented fairly soon?
I'm in exactly the scenario described above, I need to set up a new authernication device rather urgently. My scratch codes were lost when a device I had stored them on broke.

Reedy added a subscriber: Reedy.Sep 1 2017, 3:34 PM

A note on security: There is no additional security risk in displaying the QR code and the scratch codes again, because an existing TOTP token is required for the user to view the codes.

Most people would disagree.

T150601 is a much better option than showing users the old scratch tokens again!

What are the chances of this being implemented fairly soon?
I'm in exactly the scenario described above, I need to set up a new authernication device rather urgently. My scratch codes were lost when a device I had stored them on broke.

Why can't you just disable it?

Dodger67 added a comment.EditedSep 1 2017, 6:29 PM

AIUI i need scratch tokens to do that.

T150601 has been open since last November, with zero actual visible progress towards actually being done....

Reedy added a comment.Sep 1 2017, 6:33 PM

AIUI i need scratch tokens to do that.

Or a valid OTP from your application

If you have neither, some of the changes being requested in this app aren't going to help you

Dodger67 added a comment.EditedSep 1 2017, 6:39 PM

I am currently correctly logged in, thus my identity right now is securely proven, so why must it be so hard to get either a new batch of scratch codes or a new QR code to reset an authenticator app?
We're writing an encyclopedia, not handling nuclear missile launch keys. Even my bank is not this paranoid!

Reedy added a comment.Sep 1 2017, 6:46 PM

I am currently correctly logged in, thus my identity right now is securely proven, so why must it be so hard to get either a new batch of scratch codes or a new QR code to reset an authenticator app?

What if you'd left yourself logged in on a public machine? Or if your machine had been compromised?

Just because a browser is logged into an account, doesn't mean the person driving it should have access. They could change your 2FA, and then you can't login to your account.. Or other fun and games. Other sites do the same to allow modification to 2FA status

Dodger67 added a comment.EditedSep 1 2017, 6:58 PM

How do I get rid of this crap WITHOUT! losing my user account with it's long track record and privileges?

As I have already explained: The memory stick containing my scratch codes broke (some time ago) and this week I had to replace the phone that my authenticator was running on.
The vital importance of the scratch codes is not clearly explained and emphasized during the process of getting this whole two factor setup.
Litterally months go by between log-ins, I edit from only three devices (which I own and are the only user) it's not like logging in and security issues are front-of-mind for a user like me.

2FA was "sold" to me as an essential upgrade that all admins must have, but the "simple" page through which I got it, is seriously lacking sufficient detailed explanation and OBNOXIOUSLY LOUD warnings about the consequences of losing the keys.

I'm not willing to sacrifice my ten-year, 80,000-edit track record for this.....

Aklapper added a comment.EditedSep 1 2017, 10:42 PM

If you want your personal account on Wikimedia wikis to get dealt with, that would be a separate request and task (likely for Trust-and-Safety).
So far this ticket has been about the code base of the OATHAuth extension and specifically the extension's Special:OATH page behavior.

A note on security: There is no additional security risk in displaying the QR code and the scratch codes again, because an existing TOTP token is required for the user to view the codes.

Most people would disagree.

[citation needed]

T150601 is a much better option than showing users the old scratch tokens again!

I agree on the principle that the best way forward is to separate the functionality for

  1. disable OATH;
  2. add new TOTP devices without needing to reset existing TOTP devices and scratch codes; and
  3. regenerate scratch codes without needing to reset existing TOTP devices.

But that's a bigger functionality change and the quick-fix most OATH-enabled users need for now is to let an OATH-enabled user see their OATH config page again without disabling OATH first.

Reedy added a comment.Sep 4 2017, 1:14 PM

A note on security: There is no additional security risk in displaying the QR code and the scratch codes again, because an existing TOTP token is required for the user to view the codes.

Most people would disagree.

[citation needed]

Where's the citation that there is no additional risk?

Reedy added a comment.Sep 4 2017, 1:18 PM

T150601 is a much better option than showing users the old scratch tokens again!

I agree on the principle that the best way forward is to separate the functionality for

  1. disable OATH;
  2. add new TOTP devices without needing to reset existing TOTP devices and scratch codes; and
  3. regenerate scratch codes without needing to reset existing TOTP devices.

But that's a bigger functionality change and the quick-fix most OATH-enabled users need for now is to let an OATH-enabled user see their OATH config page again without disabling OATH first.

But, we shouldn't allow people to add extra/new devices, without having their original device, or a scratch token. Otherwise you're just creating a security hole.

What would we do if the OTP were stored in a way that it wasn't possible to get them back?

A note on security: There is no additional security risk in displaying the QR code and the scratch codes again, because an existing TOTP token is required for the user to view the codes.

Where's the citation that there is no additional risk?

If someone has access to an account and the TOTP device or an existing scratch code, they can reset TOTP altogether anyway, so there's no additional risk in re-showing the existing QR code and scratch codes.

Else: if someone doesn't have access to both the account and the TOTP device or an existing scratch code, they can't see the OATH config page anyway, so this proposed design change is irrelevant.

Reedy added a comment.Sep 4 2017, 1:24 PM

A note on security: There is no additional security risk in displaying the QR code and the scratch codes again, because an existing TOTP token is required for the user to view the codes.

Where's the citation that there is no additional risk?

If someone has access to an account and the TOTP device or an existing scratch code, they can reset TOTP altogether anyway, so there's no additional risk in re-showing the existing QR code and scratch codes.
Else: if someone doesn't have access to both the account and the TOTP device or an existing scratch code, they can't see the OATH config page anyway, so this proposed design change is irrelevant.

That's not a citation.

T150601 is a much better option than showing users the old scratch tokens again!

I agree on the principle that the best way forward is to separate the functionality for

  1. disable OATH;
  2. add new TOTP devices without needing to reset existing TOTP devices and scratch codes; and
  3. regenerate scratch codes without needing to reset existing TOTP devices.

But that's a bigger functionality change and the quick-fix most OATH-enabled users need for now is to let an OATH-enabled user see their OATH config page again without disabling OATH first.

But, we shouldn't allow people to add extra/new devices, without having their original device, or a scratch token. Otherwise you're just creating a security hole.
What would we do if the OTP were stored in a way that it wasn't possible to get them back?

Ah, I believe we've misunderstood each other.

My suggestion is that a user should be able to add a device without resetting all scratch codes and existing devices at the same time, not to allow adding a device without bringing an existing device or scratch code.

For example, I currently have my Wikimedia OATH secret on two different devices, because it is crucial to have redundancy in all non-human elements of 2FA. If I want to add a third device in the future, I will need to bring all three devices with me at the same time when I go to the OATH page, update the Wikimedia secret on both old devices, and replace all the scratch codes I've scribbled down with new ones.

But if I can add a new device without disabling existing ones, I can set up OATH with one TOTP device and copy the scratch codes somewhere, then on a later day I can log in with my existing TOTP device to add a second TOTP device, and then on yet another day log in with either existing TOTP devices - without bringing the other one - and add a third TOTP device. And my first and second TOTP devices, plus the original scratch codes, will still be valid.

This will be a massive design improvement to most users, because you know, an individual electronic device is rather unreliable, but if you have several of them they tend to break on different days.

Reedy added a comment.Sep 4 2017, 1:44 PM

Ah, I believe we've misunderstood each other.

Yeah, I think we've got a little bit of crossed wires. Sorry :). Plus the mostly offtopic discussion which you have now forked into T174931, so thanks for that

My suggestion is that a user should be able to add a device without resetting all scratch codes and existing devices at the same time, not to allow adding a device without bringing an existing device or scratch code.

Because of the PITA that it is moving 2FA between devices, I've switched to using Authy rather than Google Authenticator. I also keep a copy of the seed in a secure place incase I really need to use it.

But all this is basically why we have these TODOs like T150601: Add option to generate new set of scratch codes and various other UX issues on MediaWiki-extensions-OATHAuth - we know it sucks pretty badly. We know the workflow is crap

There are questions here whether we use the same seed on multiple devices (if we give the users a way to add multiple devices. Obviously, at original setup time they can share it with the world if they want (not recommended!) or install it on 1000 devices. Nothing to stop them doing that)...

I'd be interested in getting some actual "evidence" or what other people do - Google, Facebook, Twitter et al. How they let users handle it. See what works, what doesn't work

Certainly, this task has merit, Special:OATH should be some sort of "menu", with various options that will probably need an extra OTP entering, allowing things like disabling completely, changing device, regenerating scratch tokens without changing device etc etc

That's not a citation.

......

What would we do if the OTP were stored in a way that it wasn't possible to get them back?

As I wrote in the task description: "the long-term solution is to allow multiple devices with different TOTP secret keys".

For reference from another task

From a user experience POV it would be nice to be able to list the tokens at any time as well. Google allows this on https://myaccount.google.com/security/signinoptions/two-step-verification and it has been handy in the past for me.

@csteipp can maybe comment more, but I don't know if I agree with this. The backup codes are a shared secret between the server and user, and we should avoid communicating shared secrets as much as possible. It'd be better to only show the codes once, and if the user wants to see them again, just generate brand new codes.

That's not a citation.

......

Well, it's not. It wouldn't fly on Wikipedia. Somebody stating something doesn't make it true. We generally require references from 3rd party trusted sources etc. But I don't need to explain that to you.

There are questions here whether we use the same seed on multiple devices (if we give the users a way to add multiple devices. Obviously, at original setup time they can share it with the world if they want (not recommended!) or install it on 1000 devices. Nothing to stop them doing that)...

lolz.

Certainly, this task has merit, Special:OATH should be some sort of "menu", with various options that will probably need an extra OTP entering, allowing things like disabling completely, changing device, regenerating scratch tokens without changing device etc etc

Thanks and yes please!

I'd be interested in getting some actual "evidence" or what other people do - Google, Facebook, Twitter et al. How they let users handle it. See what works, what doesn't work

GoogleFacebookTwitterMediaWiki OATH (as of now)
TOTP1 device (or secret) only, changing device invalidates previous TOTP deviceWhen user asks to add device, it asks for (human-remembered) password again and then shows same secretnone1 secret only, cannot see existing secret again
scratch-codes10 codes, user can see existing codes again without needing to regenerate10 codes, user can see existing codes again without needing to regeneratenone5 codes, cannot see existing codes again
other modesPhone call or SMS (allows multiple phone numbers; Google Prompt or U2F USB;SMS (allows multiple phone numbers); U2F USB/NFC keysconfirmation by email linknone yet
to change...need to log in then enter password again to access 2FA menuneed to enter password again to change any 2FA itemmay ask for confirmation of phone number or email addressneed extra 2FA secret or scratch code (but not password) after logging in
Reedy added a comment.Sep 4 2017, 2:51 PM

Thanks!

FWIW, 2FA via SMS is very much considered against best practices, so we're definitely not going to be implementing that. Though, you're obviously not requesting that, just mentioning it for reference of what others do :)

https://techcrunch.com/2016/07/25/nist-declares-the-age-of-sms-based-2-factor-authentication-over/

Reedy updated the task description. (Show Details)Sep 6 2017, 12:57 AM
mxn added a subscriber: mxn.Nov 6 2017, 6:25 AM
TheDJ added a subscriber: TheDJ.Nov 9 2017, 10:21 PM

@deryckchan FYI, Twitter allows for TOTP via their own app as well as via a TOTP app as we use. They don't seem to have a limit on how many devices (I wonder if all devices use the same code actually....). There are no scratch tokens either. Phone and/or email verification required for account recovery.

Something seems to be missing here - you can enroll as many devices as you want, at any time with us - provided you store your two-factor secret key. That key can be re-used in the future to initialize more authentication clients at any time. So this is already information that the users have, though hopefully if they store it they store it safely. That being said, being able to access it online after re authenticating with 2FA seems fine to me.

Tgr added a subscriber: Tgr.Nov 18 2017, 11:17 PM

The backup codes are a shared secret between the server and user, and we should avoid communicating shared secrets as much as possible.

By regenerating scratch tokens you also communicate shared secrets so there doesn't seem to be much difference security-wise.

the long-term solution is to allow multiple devices with different TOTP secret keys

Yeah. That has some security benefits (we want users to be able to name keys and track what devices they have set up 2FA for, so that they can revoke permissions of devices they don't control anymore) and the backend capability of multiple auth methods per user will be necessary anyway for T100373.

Something seems to be missing here - you can enroll as many devices as you want, at any time with us - provided you store your two-factor secret key. That key can be re-used in the future to initialize more authentication clients at any time. So this is already information that the users have, though hopefully if they store it they store it safely. That being said, being able to access it online after re authenticating with 2FA seems fine to me.

Current common practice is that TOTP clients (notably Google Authenticator) don't store the two-factor secret key in a way that allows it to be displayed back to the user. Sure, one can store the secret in plain-text so it can be added to another device later, but that isn't common practice and as you said raises interesting questions about security. A better solution is to allow the MediaWiki OATH interface to show the secret again when the user logs in with a TOTP code from an existing device, and a still better solution than that is to allow multiple devices with different TOTP tokens.

I'm going for the low-hanging fruit in this thread and requesting that Special:OATH simply takes the user back to the same secret and scratch codes rather than disables and erases all existing 2FA secrets altogether.

Tgr added a comment.Nov 21 2017, 1:03 AM

Current common practice is that TOTP clients (notably Google Authenticator) don't store the two-factor secret key in a way that allows it to be displayed back to the user.

{{citation needed}} :) I doubt that's even technically possible.

Current common practice is that TOTP clients (notably Google Authenticator) don't store the two-factor secret key in a way that allows it to be displayed back to the user.

{{citation needed}} :) I doubt that's even technically possible.

I'm not saying there's some kind of irreversible hash. The secret is obviously stored in a reversibly encoded manner because that's how TOTP works.

However, Google Authenticator has no feature to display the secret back to the user. As discussed in this article, it is only possible to retrieve a secret stored by Google Authenticator if you have a rooted Android device. This CNET guide says the standard method to migrate 2FA to a new device is to go to each online service for which you've enabled 2FA and obtain the 2FA secret again (or a new one) from the online service for your new device. It is not common practice to try to get the secret back from whatever TOTP app you use.

Tgr added a comment.Nov 21 2017, 10:08 PM

The point is, how the secret is stored and whether you display it to the user are two entirely unrelated things. We do seem to store the key and tokens in plaintext (we probably shouldn't, to mitigate SQL injection), but even if we didn't, we could still easily display the tokens if the user asks. Google Authenticator operates under entirely different trust scenarios (e.g. someone could copy your keys while the phone is in the service) which are probably not relevant here.

but even if we didn't, we could still easily display the tokens if the user asks.

This is indeed my main aim in raising this task.

Reedy added a comment.Dec 20 2017, 7:10 PM

The point is, how the secret is stored and whether you display it to the user are two entirely unrelated things. We do seem to store the key and tokens in plaintext (we probably shouldn't, to mitigate SQL injection), but even if we didn't, we could still easily display the tokens if the user asks. Google Authenticator operates under entirely different trust scenarios (e.g. someone could copy your keys while the phone is in the service) which are probably not relevant here.

T145915

Liuxinyu970226 added a comment.EditedDec 21 2017, 4:15 AM

@Reedy:

T145915

Is a private task, wondering if I'm possible to contact WMF-Legal member for the possible disclosure? Or will you add me as a subscriber of it (I obey to not disclose anything even its other subscribers, though)? Or it's now suitable for removing the visibility settings (like this task?)

deryckchan updated the task description. (Show Details)Nov 26 2018, 4:11 PM

@deryckchan FYI, Twitter allows for TOTP via their own app as well as via a TOTP app as we use. They don't seem to have a limit on how many devices (I wonder if all devices use the same code actually....). There are no scratch tokens either. Phone and/or email verification required for account recovery.

Updated table in task description per your comment.

Reedy renamed this task from Special:OATH should go to 2FA setup, not just disable to Improve Special:OATH workflow for users with 2FA already enabled.Dec 7 2018, 6:27 AM
Reedy removed a subscriber: dpatrick.
Tgr renamed this task from Improve Special:OATH workflow for users with 2FA already enabled to Allow OATHAuth users with 2FA already enabled to add / switch devices without disabling.Dec 7 2018, 6:51 AM