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.

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!

In T172079#3573414, @Dodger67 wrote:

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?

AIUI i need scratch tokens to do that.

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

In T172079#3573888, @Dodger67 wrote:

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

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!

In T172079#3573915, @Dodger67 wrote:

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

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

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.

In T172079#3573460, @Reedy wrote:

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.

In T172079#3577419, @deryckchan wrote:

In T172079#3573460, @Reedy wrote:

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?

In T172079#3577419, @deryckchan wrote:

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?

In T172079#3577422, @Reedy wrote:

In T172079#3577419, @deryckchan wrote:

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.

In T172079#3577439, @deryckchan wrote:

In T172079#3577422, @Reedy wrote:

In T172079#3577419, @deryckchan wrote:

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.

In T172079#3577423, @Reedy wrote:

In T172079#3577419, @deryckchan wrote:

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.

In T172079#3577481, @deryckchan wrote:

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

In T172079#3577481, @deryckchan wrote:

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

In T172079#3577450, @Reedy wrote:

That's not a citation.

......

In T172079#3577423, @Reedy wrote:

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

In T131788#2708008, @Parent5446 wrote:

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.

In T172079#3577510, @deryckchan wrote:

In T172079#3577450, @Reedy wrote:

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.

In T172079#3577507, @Reedy wrote:

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!

In T172079#3577507, @Reedy wrote:

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

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/

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

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.

In T172079#3770839, @Xaosflux wrote:

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.

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.

In T172079#3776581, @Tgr wrote:

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.

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.

In T172079#3779576, @Tgr wrote:

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.

In T172079#3779576, @Tgr wrote:

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

@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?)

In T172079#3749425, @TheDJ wrote:

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

Mentioning a few related tasks that solve the same set of issues:
T150601 Add option to generate new set of scratch codes
T242031 Allow multiple different 2FA devices