
Ask HN: What is a secure way to allow 2FA resets? - tvirelli
I have 2FA on one of my web apps. Most users are using Google Authenticator which uses TOTP (Time-Based One-Time Password). On first login, we show them a QR code. We instruct them to save a copy of this QR code in the event they get a new phone or want to install a new 2FA app. However, I am running into a situation where users are not doing this. I can easily enough reset their account to show a QR code again on next login, but my question is: What is the safest way to &quot;authenticate&quot; them for a reset? I could do things like send a reset email to the email associated with the account, but I am just wondering what others are doing for situations like this. I want to make sure I am doing it as securely as possible.<p>Thanks!
======
segfaultbuserr
This is the most tricky issue about 2FA: who's going to authenticate the
authentication system? From what I've seen in practice, if an account is lost,
there are two primary ways for recovery.

(A) Secret key. When a user is setting up 2FA for his/her account, the system
generates a secret passphrase/QR Code as a crypto key, with instructions for
user to write it down or print it out, then store it at a secure location.

(B) Manual review. The policy of a hosting company I use, is that when a 2FA-
protected account is lost, the user must submit a national passport and proof
of payment to reset the account manually.

And if user wants to add a new device.

(C) Send a challenge to the original device. If the system is in form of an
app, it's as easy as showing up a Yes/No warning in the app: _someone is
adding a new device to your account, do you trust it?_ This is commonly used
for various chat apps.

However, all the methods are not going to work for your use case, as the user
wants to bypass the 2FA when setting up a new device... Currently, I don't see
a satisfactory solution, otherwise, it effectively opens up a loophole and
nullify the advantage of 2FA.

Let's see what other readers are saying.

~~~
nindalf
A. OP's original problem is that users aren't noting down the secret when
they're requested to.

B. Manual review works, unless there is a sufficient incentive to break it.
Here's an example of PlayStation Network struggling with hackers disabling 2FA
via customer support - [https://waypoint.vice.com/en_us/article/43ebpd/the-
long-weir...](https://waypoint.vice.com/en_us/article/43ebpd/the-long-weird-
story-explaining-why-i-bid-dollar700-for-a-stolen-psn-account)

C. If a user is resetting 2FA then most likely they've lost the device on
which they had the authenticator app installed. If they still had access to
it, authorizing them to perform a 2FA reset would be trivial.

D. Reset via email is the most commonly used one. It's scalable, unlike manual
review. Less secure, arguably.

> This is the most tricky issue about 2FA: who's going to authenticate the
> authentication system

100% agree here. It's a hard problem.

~~~
naravara
>D. Reset via email is the most commonly used one. It's scalable, unlike
manual review. Less secure, arguably.

What's the argument that it's not any less secure? That seems like a pretty
obvious conclusion to me.

~~~
totallyashill
Password reuse and 2FA enforcement.

Although, we at HN are the shining tier of amazingness (/s), most people will
use the same password across as many accounts as they can, or use some
dirivation of the password.

The bigger issue is that plenty of people don't enable 2FA onto their emails
as it's never really suggested by the providers, some just don't support it,
and the fear of getting locked out of something so central.

It's better than SMS 2nd Factor though.

~~~
mont
Gmail at least (sort of) pushes 2fa with their 'security reviews'.

------
richardwhiuk
You probably want to request a reset.

When a reset is requested, you should then allow a grace period - possibly up
to a month for the reset to be cancelled. You should notify the user via
email/out of band mechanism that a reset has been requested.

On each login you should prompt that the reset is ongoing and that it can be
cancelled.

Finally after a month, you revoke the 2FA and allow a new device to be
activated.

Or alternatively/as well, you require that the user sets up a new account. You
may allow them to merge this account after the reset has completed.

Fundamentally the question is "if a user took over someone else's account what
the impact be?"

On reset, you may want to delete any sensitive recoverable data - e.g. Credit
card details or Passport info.

~~~
Klathmon
This is the one that I like the best if manual human review doesn't work for
your use case.

Set a reasonable time period (a month seems like really long, I was thinking
more along the lines of a week), use every piece of information you have to
attempt to alert the user multiple times that a reset is happening (email,
text, in-app alerts, etc...), make sure that each "alert" gives the user a
one-click way of stopping the reset, and when the reset is successful, delete
all information that is easily replaceable (like saved credit cards or
addresses, or as much personal information that you can get rid of).

~~~
nmalaguti
One of the problems with that is it makes account recovery after a compromise
that much harder. If an attacker manages to prevent you from seeing those
notifications (compromised email/sms) and you aren’t actively signing in, it’s
possible for the month to lapse.

Once the attacker has control and you try to reassert ownership, the attacker
gets a loud warning every time you try to login/change the TFA and a month to
respond.

~~~
Klathmon
That's very true, so I guess at the end of the day manual verification is
needed for just about everything where you absolutely need a user to be able
to recover their account.

A scheme like the above still helps cut down on the number of times that
manual verification will have to be used, and hopefully can be made rare
enough that you can spend the proper amount of time verifying each one to do
your best to prevent "stolen identities" from being used.

------
steventhedev
Consider the threat model:

An adversary takes over the email account, and checks if they reused their
password on your site. If they didn't, then they'll try to reset the password,
and you should check the second factor _before_ resetting the password. If
they did reuse their password, then you should check the second factor on
login (assuming it's coming from a previously unrecognized source). At this
point, the attacker will either give up, or attempt to contact your support
channels, impersonating the user.

It's up to you what restrictions you place on your support mechanism for
resetting 2FA. I would suggest a combination of the following:

\- photo of a currently valid credit card associated with the account

\- photo ID with address that matches billing address

\- mandatory 7 day delay in the reset

\- prove access to the payment method by issuing a payment for some fractional
amount and request the amount, then refund it (or don't and keep it as a
"security fee")

But no matter what you do, please please please be consistent. Train your
entire support staff (if any), keep records of when people talk with you,
don't disclose when the last time you talked was, and insist on following a
process. If your process fails, see how and improve it.

~~~
amf12
> photo ID with address that matches billing address

Please don't do this. There are people who move often to not have their
current address on their photo id.

~~~
DennisP
For this to be a problem someone would have to lose their 2FA device, and
their backup codes, _and_ change their billing address but not the address on
their ID. If all that does happen, they can solve it by updating their ID,
which most states require within 30 days of moving anyway.

~~~
zodiac
Or they could have used a billing address different from where they live to
start with.

~~~
steventhedev
True.

I'd argue that trumps all other control over the account. If you can show that
you control the payment method, then I'll accept you as the legitimate
controller of the account. So, notarized, translated, and apostilled letter
from the bank branch manager stating that you are the person in control of the
account, sent by certified mail with signature delivery and I'll send you back
a link to type in manually the same way.

As a shortcut, I'd say it's mostly safe to accept a picture of someone's face
holding up their photo ID with the same billing address.

Or confirming the amount and/or origin (some banks/credit systems do not
display the merchant name for some halfbrained reason) of a small transaction
(e.g. 1.37 USD from merchant account ACMECORP-294817) that is refunded after a
week.

------
LeonM
To add to the (mostly excellent) comments on this threat:

Consider the risk involved, and who is responsible for keeping the reset
procedure secure.

If you're building a bank app, make sure you have a proper reset procedure,
preferably with human validation, like how user 'steventhedev' described. The
bank (your company) is responsible for this.

If you build commercial/enterprise software, the 'admin' user should be able
to perform resets. Preferably a customer must have at least 2 admin users, to
prevent locking out. The customer is responsible.

If you are building consumer grade software, go with a reset procedure through
email. The consumer is responsible for keeping that secure. If their email
gets compromised, it can't be your responsibility.

~~~
steventhedev
> If you are building consumer grade software, go with a reset procedure
> through email. The consumer is responsible for keeping that secure. If their
> email gets compromised, it can't be your responsibility.

That defeats the whole point of 2FA.

~~~
move-on-by
I'd say on average anyone who is concerned enough about their security to turn
on an optional 2FA feature is also going to have 2FA enabled on their email as
well. If I were only allowed to have 2FA enabled on a single account, it would
be a very difficult decision between my password manager and my email. As you
point out, email access is the key to the kingdom. Also, the only password
that I do not put in my password manager is my email account password.

------
PaulAJ
One option would be on the sign-up side: get them to "test" the recovery
option. Keep bugging them about it every log-in until they do. This has two
advantages:

1: This sends the message that you think it important, which might help them
realise it is too.

2: They will have printed the QR code. Putting it somewhere safe is a small
additional step.

~~~
Klathmon
Even then a backup code like that isn't going to work in all cases.

This is the same issue that electronic/cryptographic voting schemes run into.

You can't in many cases just tell your user "too bad you lost the code", you
need a way for a user who has lost everything to get back in.

Shit happens, theft, floods, fires, other natural disasters, etc... And in
those cases it's somewhat common for the user to lose their phone (with the
2nd factor app on it), as well as their backup codes.

Sure, a game might be able to get away with saying "sorry, you lost your 2fa
and backup, so you are SOL" (the user won't be happy, but it's not the end of
the world), but for a bank account? For a utility company? For your email
account? Telling the user "so sorry you are fucked" is a very bad thing, and
could even be illegal in some cases.

Forcing the user to verify that they printed it out and saved it can help cut
down on the number of reset requests, but it won't completely solve the
problem. You still need a way for someone who has lost everything to get the
account back.

~~~
naravara
>Shit happens, theft, floods, fires, other natural disasters, etc... And in
those cases it's somewhat common for the user to lose their phone (with the
2nd factor app on it), as well as their backup codes. >Sure, a game might be
able to get away with saying "sorry, you lost your 2fa and backup, so you are
SOL" (the user won't be happy, but it's not the end of the world), but for a
bank account? For a utility company? For your email account? Telling the user
"so sorry you are fucked" is a very bad thing, and could even be illegal in
some cases.

In some cases you might be able to get away with using waiting periods. You
can establish like a month or so and ask them to re-request after that with a
recovery code you give them when they first make a request.

If nobody accesses the account in that time, you can have a bit more
confidence that the request is legitimate and the account owner really has
lost their credentials. And then when they re-request with their recovery code
that's the authorization to start the reset.

In some cases you could tide them over with a temporary account that has
limited privileges for the duration of the waiting period that can be merged
back into the original account once its unlocked. You could probably even do
some analysis behavior in the temp account to see how well it matches up with
points of contact, frequency of use, word choice, location, etc. on the main
account.

I wouldn't trust that for a bank or a primary email, you really need to verify
identity for that. But for a utility company it might be ok.

------
arama471
Put a timer on the reset - Allow them to start the reset process, but make it
so it takes a while (At least a few days), and during that time make sure any
successfully logged in person on that account sees large warnings that someone
is resetting their 2FA. This ensures that whoever actually owns the account
can react in time to stop a takeover, at the cost of making the reset process
kindda painful.

~~~
SlowRobotAhead
Counter that if I’m a hacker, I’ll already have knowledge of this and try and
time my attack when my target is unlikely to log in, but I suppose we’re
getting into weeds with that.

~~~
lisper
There is no staying out of the weeds when it comes to security. The weeds are
where the threats hide.

~~~
SlowRobotAhead
We all better get a cabin in the wood then ;)

------
3pt14159
Most answers here are things that won't work because people are human and will
lose or forget stuff one way or another. What I've seen that works quite well
is to have a user list a number of email accounts that they trust to vouch for
them. If they lose their 2FA and 2FA backup then they can do an email reset,
but only if n of m of their friends authorize it and only after a delay of
some kind (24 hours, say). Now an attacker needs to figure out what the likely
friendlies are, pop multiple email accounts, and the delay gives enough time
for someone to notice something and lock the account down.

------
derefr
Personally, I think true 2FA—of TOTP-type 2FA tokens that most people mean
when they say “2FA” these days—can only work in the context of a SSO service /
“identity provider” (in OpenID parlance) which requires KYC document
submission (birth certificate, passport, etc.) upon sign-up.

In order to be able to prove who you are to reset your auth credentials, you
have to have proven who you are when you set up the account, in a way which
_distinguishes_ your identity from that of others who share some-but-not-all
of your attributes (e.g. your legal name.) Otherwise, anyone with those same
attributes “has the key” to your account.

The only convenient way to create such a distinguished profile, is to hand
over some legal identifying document that is linked to a pool of other
identifying documents, such that if you later see a _different_ such document,
you can ask the relevant government whether it identifies the same person as
the previous document you saw.

This requires keeping around identity documents for later comparisons, which
is a fraught problem. I’d rather trust as few companies with my identity
documents as possible—especially if I know that they’re going to need to keep
them on file.

Thus why I say that probably only SSO providers can manage TOTP 2FA: without a
_secure_ 2FA-reset flow, they don’t “really” have 2FA; and only very few
companies (i.e. identity providers) are able to be trusted with the documents
required to implement such a _secure_ flow.

——

...none of which matters all that much, because the real problem is TOTP
itself, and the solution is to switch to a better type of 2FA. In the original
enterprise 2FA smart-card implementation, it wasn’t the company with the
account requiring auth that issued the 2FA token, but rather a separate 2FA
issuer. The client would then get their card _bound_ to each account they
wanted to use it to authenticate. The card had a signing key, and the services
just needed its matching public key.

With “real” 2FA impls like this, you aren’t supposed to need N 2FA tokens that
you would need to reset separately with each rinky-dink authable service, but
rather just one 2FA token, with token rollover—and the security around
it—handled by the issuer. Use better 2FA.

------
miketery
I've been pondering a trusted network using shamir secret sharing for this
case - where you can rely on other parties to hold the secret key and call on
them. For example, origin player loses 2FA to system A, origin player calls
out to their immediate backup personnel (origin player sets limit of how many
are required to recover secret). Each backup personnel can say OK - sending
partial to system A, once enough have been sent the secret is recovered.
Complex, and time in-detriment, and still prone to failure or breach of trust.

------
Lucent
This problem has me considering that TOTP/2FA is inherently less secure than
password only. If you're using a password manager and that site has a unique
password, you're almost certainly secure as long as the login process has rate
limiting against brute force.

Once you add in 2FA/TOTP, you're looking at the rate of resets skyrocketing as
well as social engineering getting much easier because it's so plausible and
frequent that code generators are lost.

* SMS reset is so bad it's comical. Hackers went from having to crack billions of possibilities to having to catch a six-digit number sent not even to my phone, but to my phone number. I've spent a lot of effort getting my number out of services who demand it as a reset option when I turn on 2FA. If you're using it as single-factor reset, I'm much safer with 2FA off.

* Email reset makes TOTP and passwords pointless. Just get access to the email and it's as if neither of those ever existed. No reason to even have passwords. Use magic links like Medium does for login. It's the same thing as a password reset with one less thing to remember.

* Documents like passport or license mean instead of cracking a password with 40+ bits of entropy, all I need is the person's real name and Photoshop and some motivation.

* Personal information like last 4 of credit card, birthdate, SSN turn those publicly available bits into passwords themselves which are also far easier to get ahold of than any password.

~~~
techsupporter
If the reset process allows for _both_ the 2FA and the password to be reset
using a single one of the four points you've mentioned then, yes, it's a
terrible design that should be scrapped immediately.

However, if any of the four points you've mentioned allow for only resetting
the 2FA option and still require possession of the password, then I think
you're more secure with 2FA enabled. Why? Because the reset step, if nothing
else, provides an additional hurdle to be crossed. Yes, SMS 2FA is terrible
and anyone who uses it should be barred from owning anything more complicated
than a light switch, but that doesn't discount all of the other, better
methods.

Even e-mail as a reset factor can be more secure if the e-mail account is
secured. In my experience, people are more willing to put up with "hassle" to
secure their e-mail because it has stuff they care about in there. It's been
far easier for me to get people I know to enable app-based or (shockingly)
even physical device 2FA with a Yubikey on their e-mail accounts. I even know
two older, non-technical people who already had it enabled because "I read
that it's better for e-mail so I turned it on and put that printout it made me
do in the safe."

So 2FA seems to me like it can be more secure as long as it is really _2_
factor auth and not "oh enter this other code...or also just use your phone to
reset all access methods" (like some banks do, damn it).

------
nimbius
aliexpress has a good hat-trick for it. If you're resetting your password, or
authentication, then all stored credit card data is wiped from your account.

~~~
CharlesW
That's brilliant. You could even hide other data (shipping addresses, purchase
history, etc.) until valid payment information is re-entered, or until the
next successful purchase.

~~~
sowbug
To generalize the idea: as long as anyone can create a new account, then the
value of a new account is zero. The value of the lost account is the value of
the differences between it and a new account. The recovery cost should be
directly proportional to the value of the account. Aliexpress turns this
formula on its head, starting the recovery operation by taking a high-value
account and turning it into a low-value one, then presumably using a
correspondingly low-cost recovery method.

There is an issue of not needing credentials to delete payment data as a kind
of DOS attack.

Your idea is smart as well: it turns the high-value component of the account
into a credential of its own.

------
e12e
You're running up against the issue of identity management. The schiboleth sso
technology of colleges and research institutions solved this by letting
institutions manage accounts. To reset your login, go to you it department
with photo ID and request a reset.

Obviously not very _convenient_. But one approach is to simply let a third
party, like Google, do the identity management. Have only third party sso
login, and don't do any identity management - only authorization.

I'm not aware of any frictionless, convenient and secure method. That was the
reasoning behind Mozilla's web auth/sso project (I forget the name); access to
email equals access to account recovery - so why not just allow proof of email
account access be proof of identity?

~~~
rrdharan
I believe Persona is the project you are thinking of:
[https://en.wikipedia.org/wiki/Mozilla_Persona](https://en.wikipedia.org/wiki/Mozilla_Persona)

~~~
e12e
Yes, thank you.

------
hluska
Honestly, I'd be a liar if I said that I knew. PaulAJ might have the best idea
that I've read - force people to test the recovery option. Though sadly, I've
never had much luck convincing really smart people to test that mission
critical things like backups work, so my inner marketer fears what that kind
of friction will do to user retention rates.

For me, the central problem always comes down to mobile providers. I've
managed to make some really serious changes to my mobile account without a
hint of authentication. And, I would switch providers, but frankly, I've had
that experience with every provider I have ever tried. When the secondary
device itself is a major attack vector under every reasonable threat model, it
makes the whole exercise seem like playing chess when your enemy is conducting
full scale war games.

The right answer might be a mixture of manual review, sending challenges to
the original device and conducting some profiling based on user agent,
location and networks used to connect to the service. However, it's also
entirely possible (and even likely) that our current means of authentication
are fully hacked, completely fucked and due for a complete replacement.

~~~
dmoy
> force people to test the recovery option

login.gov at least makes you prove you copied the 2fa backup number... at
least on the next screen. So far that's the best I've seen.

After dealing with the shitshow that is the treasury's login, I was pleasantly
surprised that login.gov appears to be pretty good. I was literally feeling
sick to my stomach when creating a login.gov account in anticipation of more
crap, but nope turns out it's fine :)

------
PeterisP
For valuable accounts, it may make sense to require physical contact in any
"I've lost all credentials" scenario.

While there's still a balance between convenience and security, this is an
effective deterrent, as it generally requires the attackers to risk being
identified (and makes it hard for non-local attackers who may rely on
effective immunity from prosecution because their local gov't won't care), so
the attackers will pick another target.

Depending on what's possible, things like requiring them to actually visit you
with an ID (some financial institutions do this), verifying identity and
documents over a video chat (much harder to fake than photoshopping a single
scan of ID, and in case of fraud, you'd have identifying info - video of face
and voice of a fraudster or their associate), delivering new credentials by
courier to the HQ of the company who's your customer, delivering new
credentials by physical mail to the billing address, things like that - things
that tie to the physical identity of the real customer instead of just their
online accounts, or things that require a potential attacker to surrender part
of their anonymity.

------
Dowwie
How about a "Reset Buddy"?

During registration, a user adds a reset email that was different from the
user's primary email. The email address is of someone you know who can give
you the reset key when it is emailed to them.

With this approach, your designated reset buddy's email would have to be
hacked as well then. So, even if you've been completely Pwn3d, your buddy
hasn't.

~~~
imhoguy
That is good approach for all invite-only and referal-based services.

------
StavrosK
Just don't let them proceed without generating and inputting a code. Why are
you just showing the QR code and hoping they save it?

~~~
jeremygaither
Services like AWS do this. Requiring them to provide at least one (if not two)
generated codes before proceeding ensures they have at least captured the 2FA
code.

------
balladeer
As of now there’s not much you can do other than educating your users.

Maybe add a workflow that checks whether they have the backup code or not and
if not prompt them to note it down again. Maybe on second login/usage after
setting up 2FA. If they still don’t do it just revert to email reset.

There isn’t much you can do if the user isn’t security conscious and doesn’t
intend to be.

Is it a particular demographic? I’d assume this is an issue faced by most of
the apps with 2FA.

------
LinuxBender
What are you protecting? Financial data? If so, have them go to a branch
office and prove their identity to a person.

Which is more important, retaining the person, or protecting their data? If
retaining the person, then give them some simple and less secure method like a
recovery email address. If protecting the data, I would leave them locked out
of their account. Unpopular opinion, but I do that a lot it seems.

------
MaxGabriel
If your app is team based, you could set it up so that admins of the team can
reset people’s 2FA device, similar to how AWS does it with IAM roles.

~~~
eropple
If their app is team based, they should be deferring 2FA to the IdP that that
team should already have.

------
Spooky23
Look at the NIST defined identity assurance levels and the guidance for MFA
issuance.

Trust isn’t cheap. Credit based verification services are better than email.
Adding verification via physical mail adds some value.

Fundamentally, you need to decide whether it’s important to know that I am in
control of the email address associated with “Spooky23”, or that I am a
particular human being.

------
parliament32
NearlyFreeSpeech has a pretty comprehensive guide for how they handle 2FA
resets, it might be worth a look:
[https://faq.nearlyfreespeech.net/section/login/losteverythin...](https://faq.nearlyfreespeech.net/section/login/losteverything#losteverything)

------
monocasa
Give them FIDO keys.

It's built on public/private crypto, so it's not like TOTP where the QR code
is the plaintext private key that has to be distributed around like it's
candy.

~~~
SheinhardtWigCo
What happens when a user loses their FIDO key?

~~~
DanBC
They use their backup key.

~~~
Klathmon
And if there is a flood that destroys that too?

------
lozenge
Don't use email or SMS as it weakens the security to that of their email or -
yuck - phone company customer service.

Manual review with proof of ID is the only way. Anything else will just have
people not following instructions and requesting manual review anyway.

If anybody asks for higher security you can add a profile option to disallow
manual review for their account. This should be visible on the settings screen
but I would suggest making them write a request to turn it on. This can then
open into a conversation about security if you are interested. And prevents
people who don't understand it from turning it on to "increase security".

------
spullara
Account recovery is the #1 problem with any authentication system. Facebook's
optional trusted contacts is probably the most scalable, secure version I have
seen.

------
jiveturkey
social. 3 out of 7 pre nominated contacts.

you have to do some diligence to ensure the contacts aren’t all the same
person, decide if they (or some minimum) have to also be 2FA, prompt the user
from time to time to confirm the list, etc.

ps. this is called the recovery problem and is indeed the hardest part of 2fa.
if you can punt entirely, eg like github, you can save yourself 95% of the
grief of supporting 2FA

