
Getting 2FA Right in 2019 - dguido
https://blog.trailofbits.com/2019/06/20/getting-2fa-right-in-2019/
======
Dayshine
The main problem I have with TOTP (What you're using when you use Google
Authenticator) is that the migration path doesn't exist when you get a new
phone. This article complains that users are trying to mitigate this problem,
but doesn't seem to give any solutions.

It's entirely plausible you might have 20 accounts set up using TOTP on your
phone.

If you now buy a new phone (which users might be doing once every 18-24
months), you need to log into each account and generate a new TOTP key and
void the old. That's a couple of hours work.

Now, what if you _lose_ your phone?

You now have to _recover_ 20 accounts, which will take several days, and it's
very possible you won't be able to recover at least one.

The common response is "Oh, you should keep one-time keys somewhere". Right,
20 * 10 one-time keys in a single centralised location, and make sure to
update them to keep them valid. I thought we were trying to stop people
writing their passwords down and storing them next to their computer?

Edit: I'm not sure "treat your TOTP keys like passwords and store them" is
setting a very good example. Why are we developing systems that use TOTP if we
are encouraging users to treat them like passwords, undoing the vast majority
of the security benefit?

~~~
pvinis
I use 1password for TOTP too, and this detaches my device from it. Now if I
lose my phone, I just need to be able to access the app on my next phone and
I'm all set.

I know that keeping the password and the TOTP at the same place is kinda not
great, but I prefer this "risk" to the "hassle" you mentioned.

I'm open to better solutions!

~~~
tptacek
At this point, what is TOTP actually doing for you? If you're using 1Password,
it's already generating unguessable passwords for you. Your TOTP codes are
literally just an extension of that password.

~~~
sametmax
It mitigates phishing and password reset attacks. It also means you can give
access to some account to a friend or family over the phone one time, without
giving them permanent access. Also good on non encrypted public wifi or in a
company network with a proxy that sees and logs everything.

The real word is very unperfect.

~~~
goatsi
It mitigates the simplest forms of phishing. If someone is running a proxy
server[0] and passing everything along to the real website, token (or SMS)
based 2fa can't do anything.

[0][https://breakdev.org/evilginx-2-next-generation-of-
phishing-...](https://breakdev.org/evilginx-2-next-generation-of-phishing-2fa-
tokens/)

~~~
sametmax
Hence "mitigates" and not "cancels"

------
tptacek
_Recovery codes should not be mandatory. Recovery codes are not second factors
— they circumvent the 2FA scheme. You should, of course, allow users to
configure recovery codes. However, the default behavior for a two-factor
scheme should always fail closed: if a client cannot produce a valid second
factor and hasn’t voluntarily weakened the 2FA scheme by adding an escape
hatch, they should not be allowed to continue._

This is unrealistic. Users lose 2FA credentials regularly. Think of recovery
codes not as a defense for the _user_ , but for the _service_ \--- they're
keep some number of customers out of your terrifying, manual account recovery
flow.

~~~
woodruffw
Author here: that's fair; I admit that it's sort of an extreme position to
hold (and the framing is intentionally polemic).

Perhaps more fairly: services should only provide recovery codes by default
once they (1) fully understand the role of recovery codes within the 2FA
scheme, and (2) make efforts to relate that role to users and encourage best
practices beyond "don't save this text file to your desktop!".

~~~
idlewords
You're already asking a lot of users. Let them save the recovery codes
wherever they want! The real point of the codes is to prevent people
abandoning 2FA in frustration, even if it is at the expense of some security.

~~~
woodruffw
First of all: thank you for your work on securing congressional campaigns! I
can count on my hands the number of people I admire in the intersection
between technology and politics, and you're one of them.

I agree it's a lot to ask. But I think it's better to demand extreme security
considerations from users and fall slightly short in practice than to
encourage _any_ practice that improves account security beyond a single
password (e.g., SMS codes).

One frustrates users and makes them abandon 2FA, the other (IMO) encourages
some complacency and makes it harder to justify changes to users (especially
ones that are really great from both UX and security perspectives, like
WebAuthn).

~~~
idlewords
Thanks for the kind words!

Do I understand you right as arguing that having some people not use 2FA
because the requirements are too harsh is better than bringing people onto
"2FA lite"? Or are you saying something different?

~~~
woodruffw
Well, I guess that's the hazard: it's definitely better to have "2FA lite"
than to have no 2FA at all, but I don't think our mentality when it comes to
2FA advocacy should be resignation towards the mistakes that users make. But
that's a really hard line to walk.

~~~
tptacek
What mistake is a user making? Sophisticated users lose access to their 2FA
credentials all the time. The conventional advice is "enroll multiple TOTP
devices". Most users don't have multiple mobile devices to enroll. Now you're
asking them to enroll something on the desktop, which effectively undoes the
"something you have" benefit of TOTP (see: the 1Password thread above). At
least a recovery code _can_ be printed out.

I don't think the logic you're employing here is coherent. Consider it a bit
longer! This post could be a good longstanding reference, but this is a big
flaw.

~~~
woodruffw
Yeah, we discussed this a bit internally and concluded that opt-in recovery is
an unreasonable standard to encourage. I'll update the post shortly.

Edit: Updated.

~~~
tptacek
I like this post a lot!

------
kogir
I think this article conflates two very different motivations for using 2FA:

1) An organization has valuable resources it wishes to protect and secure from
understandable but avoidable user mistakes, like phishing. For example: an
employer. Notably, in most of these cases there’s an authority to which the
user can appeal to recover account access if 2FA access is lost. It makes
sense to be more strict.

2) A user wants to protect something they value, but the provider loses
nothing if the user’s account is compromised through user error. For example:
personal email. In this case the onus is on the user to ensure they don’t lose
access, and the provider may be unwilling or unable to accept the liability of
enabling account recovery.

The threat models for the two are very different, and in the second case, it’s
in the user’s best interest to favor availability of access over all else.

I secure my email with TOTP. I have the key stored in 1Password. In all cases
1Password (native app, not web version) is compromised, I’ve lost the battle
already. However, I’m not worth burning a zero day on or otherwise targeting
specifically. I also have backup codes saved in my personal disk backups.
Anyone willing to break into my house to get them could just threaten me more
easily.

Be very aware why you’re offering 2FA to your users. Are you 1, or 2?

------
supernova87a
This article may be right for a corporate environment where you can go to the
IT department and prove physically that you are who you are, and get your
account recovered should anything go wrong with 2FA.

However, if you (like me) use Google 2FA for your personal accounts, you must
(if you are sane) keep printed / screenshot copies of the QR codes, backup
codes, etc. to be able to recover your account.

With Google or any number of services who don't feel they need to get involved
in human-being operations, you have nowhere to go for help if you turn 2FA on
and then for any reason lose all access to your codes. What if your only phone
dies, gets stolen, lost, etc?

That is the tradeoff -- security at the expense of having absolutely no way to
circumvent it. So the only alternative to not lose your entire online life is
to keep several backups and not implement the rules that this guy lays out
(which would be appropriate elsewhere).

------
jandrese
I'm a little confused on this risk factor:

    
    
      Use the same QR to provision multiple TOTP applications  
    
      Poor understanding of what/where their second factor is.
    
      Documentation: Tell users to only provision one device
    

What is the risk here? If I have two phones and only one of them on me at a
time, why is it dangerous to configure my authentication app on both phones so
it's available regardless of which one is in my pocket?

~~~
DownGoat
It better to add two different devices with different secrets to the account,
than both sharing the same secret. This reduces the chances that something
goes wrong when a device is lost, or removed. The user can the remove the
other device with much less risk of locking themselves out of the account. It
also might provide some info in the cases where a secret is leaked, as it can
be tracked to the specific device.

There is no real security risk of the devices having the same secret, or in
adding a backup device. It is really a usability thing, the biggest pain point
a user will experience with TOTP is when they are switching phones, or when
they lose one. Decreasing the friction here can greatly improve the security
of the system.

~~~
jandrese
If the service supports that then it's fine. A lot of services only support a
single TOTP key per account though.

There's a small risk in provisioning multiple TOTP keys on one account too.
Each one reduces the search space for a brute force attack. Add in allowances
for drifting clocks and a lack of account lockout for missed attempts and you
might open up the window just enough for a brute force attack to be
successful.

------
scotchio
I wish all 2FA worked like when logging in with your Apple ID.

\- 2FA by default

\- Push notifications for the token to all your devices instantly

\- Not a text message

~~~
test1235
>Push notifications for the token to all your devices instantly

... including non-Apple devices.

I've been faffing with this for the past few days - I had to reformat and
reinstall OSX on my rather old MBA (2013), and I didn't notice at first, but
it only restored Mavericks (was previously Mojave).

As my only Apple device, I was SOL when it asked me enter my verification code
for me to log into the App Store to upgrade the OS (as Mavericks is pre-2FA).

There were no other options for verification and the only other device I own
is an Android phone (not entirely unreasonable).

I can't see a way round this other than getting ahold of another Apple device
to get the code. Am I missing something obvious?

~~~
Shank
You can use Command + Option + R to boot internet recovery instead of the on-
disk recovery. That'll download and install the latest version of the
operating system associated with your Mac.

On the 2fa front: if you only have one Apple device, you really can't leverage
the Apple 2fa system, I think. It always requires a past Apple device of some
kind to get the code.

~~~
test1235
ah .. I didn't know about internet recovery. Hopefully, I'll remember your tip
if this happens to me again (I borrowed an iPad, in the end).

Unfortunately, it doesn't look like you can turn off 2FA once you've had it on
for some time, so it feels like I'm being pushed into buying a second Apple
device?

------
ken
> with sufficient warnings for users who prefer their accounts to fail-deadly

This is unfair. A service, in general, can only know if it's fail-open or
fail-closed. Unless you're running a nuclear weapons service (where this term
came from) or the like, you don't know which way is "fail-deadly". I love
promoting security as much as anyone but let's not throw around scaremongering
terms.

I'd like my GitHub repos, for example, to be fail-open. If I can't get in,
nobody benefits from my junk there being lost forever. Certainly, nobody will
die. GitHub doesn't really support that, but at least they don't require 2FA.

------
idlewords
I don't understand the prohibition against having the same TOTP seed across
multiple devices. Seems like a very useful feature (tap phones to sync TOTP
seeds). This feels like a case where religious belief about 2FA has won over
real-world usability, especially when people migrate phones.

~~~
saxonww
I think the answer is that if you share seeds and lose a device, then you
really need to invalidate and reprovision all of your remaining devices. If
you use separate seeds and lose a device, you just invalidate the one device
and move on.

From a user's perspective, it seems like a good feature; I'm fine with
reprovisioning my 2-3 devices, no big deal, I'm in control of that. From an
admin or business perspective, it's less acceptable because if I see something
weird and need to invalidate a device, I'm actually preventing my user from
authenticating altogether - and that could require more work to recover from
depending on where my user is and what my provisioning process looks like.

~~~
idlewords
Why does losing the device require invalidating seeds? If I lose my phone or
its stolen, those seeds are still behind a lock screen, and even if they get
out, an attacker would need my password.

~~~
saxonww
Maybe 'requires' is too strong a word. It's hardly mandatory, but I'd argue
you _should_ invalidate a lost or stolen seed for the same reason you should
reset a lost or stolen password.

Of course it is not possible to access something protected by MFA if you only
have one factor. But I don't think it follows that making it easy for an
attacker to obtain a factor since you have two is OK; the whole point of MFA
is that single factors are too easy to guess or steal. Solutions that
encourage seed export and sharing make it easier to steal the seed, and
leaving a seed active if a device it's on has been lost or stolen is like
saying you don't care.

------
justnotworthit
When I see 2FA/password discussions, I check to see if anyone is talking about
Gibson's SQRL. They never are. I don't know if it's the best, but I have a
feeling we'll see each other in the "Getting 2FA Right in 2029" comment thread
too.

[https://www.grc.com/sqrl/SQRL_Explained.pdf](https://www.grc.com/sqrl/SQRL_Explained.pdf)

~~~
tialaramex
SQRL isn't able to square the circle on Phishing. The exact formula changes
(the document you linked was last updated this month though SQRL started many
years ago) but this remains true.

The idea in SQRL is that surely if we show the user what they're about to do
(e.g. sign into mybank.example), they'll realise they're being phished (e.g.
by "notmybank.example") and abort. But the whole _point_ of phishing is that
humans don't work that way.

In one of Microsoft's early experiments with this stuff they asked users to
put their own _real_ bank credentials into obviously bogus sites with a
variety of warning conditions to try to understand what's effective. _Nothing_
was effective, ordinary users click past the warnings of imminent doom in
order to complete the task. I've written here before about "Brick Wall UX" the
practice of designing security systems where there is no way to press on into
danger. The reason for Brick Wall UX is that it _works_ and that's what
WebAuthn/ U2F deliver for phishing.

In other respects SQRL isn't much different than other 2FA options like TOTP,
although it has more moving parts. But because it can't fix phishing, it's not
worth another look, if you decide phishing isn't scary enough to warrant extra
work, TOTP already exists. If TOTP isn't good enough because you're (not
unreasonably) scared of phishing, buy some Security Keys and do WebAuthn.

~~~
9000
WebAuthn is only secure because it entrusts to browser to pass verified
domains to your USB key. Why can't SQRL just do that with no other protocol
modifications? Then we don't trust the user with anything, protocol-wise.
Cause sure, if the site can pass a QR code or URL directly everytime, that's
an issue because you're still trusting the user to manually verify the domain,
but if the interaction is mitigated by a trusted party (i.e. the browser),
then I don't see the problem.

~~~
tialaramex
Technically the FIDO device ("USB key") doesn't get told the domain name. The
browser throws it into a compression function with the random values and a
bunch of other stuff to compute a value the server also will be able to
calculate for itself. Your key has no idea what facebook.com is, doesn't care.

The FIDO device is impressively dumb on purpose, makes it hard to attack.
Given an input and a hardware user interaction it responds, cheap ones aren't
storing anything or doing any conditional work, and the interaction means you
can't do any sort of brute force attack - if you somehow RCE the browser and
prompt the user "please press the button a million times" they're going to
report that as a bug and close the browser.

------
Alex3917
Every time my leg accidentally hits by YubiKey, everyone on Slack thinks I'm
having a stroke. I already set it to require a long press so that it takes a
couple seconds, but that doesn't help if my laptop is just at the wrong angle.
Anyone else come up with a good solution to this issue?

~~~
pat2man
I turn my OTP off, just use U2F:

> ykman mode FIDO

~~~
Alex3917
Oh nice, just did that, thanks! I wasn't even using the OTP to begin with, but
I didn't realize I could just disable it.

------
exabrial
> Major sites have begun to discourage the use of SMS and voice codes, which
> are thoroughly broken as second factors

Thank goodness. Cell phones and carriers are very soft targets.

~~~
DGAP
Agreed - but for non-technical consumer 2FA, there's really no other option
that users are actually going to use. And SMS 2FA is still orders of magnitude
better than just passwords when your threat model is credential stuffing and
weak passwords - not attacks on specific accounts.

------
danielpal
Founder of Authy here. I've been thinking a lot about this lately and came to
the conclusion that the only sensible way to do 2FA are U2F hardware key's.
Here's why:

First, SMS 2FA. People think SIM port is uncommon, its not (i saw thousands of
cases). Your cellphone number its public information - pretty much - and its
not a technically difficult attack, you just need to convince a carrier to do
it. Once the your SIM is migrated to the hackers possession he will hack into
all your accounts before you even realized what happened.

Second, TOTP. I founded Authy with the idea that TOTP was strong enough and it
is, technically, but in the wild deployments have lots of issues. Biggest one
is people constantly change/loose their phones. So you end up with a update
issue. At Authy we solved it by encrypting the seeds and storing them on the
cloud. But today most users just copy the QR-Code, or store their TOTP key
along with their passwords in the password manager. Storing your TOTP in your
password manager completely defeats the point of TOTP, it just provides you
with a false sense of security. Lastly, because it generates a lot of support
issues when people loose their phones, services have added ways to bypass 2FA
in their account recovery flows. You'll see backup codes or simply SMS as a
recovery mechanism. This means your TOTP is as safe as SMS if your recovery
allows it. TOTP today is so misused its just providing a false sense of
security.

Third, U2F Hardware tokens. Its finally possible to do U2F to the iphone via
Bluetooth and Feitan now has a key that supports it (Google sells one for
project Titan). You can buy 2 keys for $50 dollars. It's impossible to missuse
U2F tokens - you can't unsafely back-them up, you can't "screenshot them",
etc, hardware enforces their security. They are 100% un-phishable, its
impossible to trick a user into signing a login on a fake site - the key will
simply not sign it, and there is no way for the user to make an
"exception"(like you can if the SSL cert is invalid.). Also given the price
and form factor is easy to buy 2 or 3 and have a few stored as backups. In my
case I have 4 keys, 2 that I use on daily basis, and 2 I stored as safe
backups. If I were to loose 2, there is no way of knowing they belong to me
and tie them back to my account and I would just use the backup keys to logon,
remove the lost keys and buy 2 more. No unsafe recovery keys, no unsafe
backups. All my 4 keys are the exact same level of security.

Lastly, now Android allows you to use your android as 1 U2F key(new androids
have secure hardware enclave specifically for this), so essentially all that
users would need to do is buy 1 hardware key as backup.

If you are a service provider, I hope you consider about offering the ability
to use U2F keys as secure login mechanism and _enforce minimum 2 keys_ need to
be registered - then you disable any other recovery mechanisms. THIS IS THE
RIGHT WAY TO DO 2FA in 2019.

~~~
sufficient
I came to a similar conclusion: U2F hardware is the way to go. For some
people, smartphones are becoming the only device they use. However, I am not
fully convinced of using the device itself as a U2F key. Then it's no longer a
two-factor solution. Thus, I envision the use of U2F hardware with mobile
devices as the future of authentication.

Unfortunately, it is still difficult to find the NFC "sweetspot" at the back
of your phone. At Cotech, we work on a Hardware Security SDK that solves this
and works independent of Google Play Services. It brings support for U2F
Hardware over NFC and USB to Android phones:
[https://hwsecurity.dev/fido/](https://hwsecurity.dev/fido/)

------
bjt2n3904
> W3C and FIDO finalized the Level 1 WebAuthn specification back in March.
> Chrome and Firefox already have mature support for it, and Safari is
> expected to follow.

> Upcoming Android releases will allow users to use their phone as a security
> key, and iOS is expected to do the same.

This does not make me happy. Why does there need to be a web standard for
this? I do not want Firefox to store my keys for me. Or any browser. I do not
want transparent authentication, I want it to be explicit, and I want it to be
offline.

I have the same issue with hands free keyless entry/ignition for cars. The
feature is solely for convenience, and exposes far too much.

The way things work now is the best. When setting up 2FA, I write down my key,
and import it into Google Authenticator, or oathtool for the command line.
There is no integration, no automation. It works just fine.

In the future I'm imagining my 2FA secrets being stolen from my browser, or
being used to track me. Google "for my convenience" automatically logs me in
so it can track me? Or perhaps, my bank checking my battery level, WiFi hot
spots, and the model of phone when it pulls the 2FA tokens to verify my
location. Also, I can only log on with their app on my phone, because the
tokens are hidden, further making my desktop useless. Maybe a website figures
out how to use JavaScript to generate another logins tokens. It takes an hour
of tokens, and feeds it into hashcat on AWS to break my key.

No thank you.

The rest of it though is great. SMS 2FA can die.

~~~
woodruffw
Hey! Author here.

> Why does there need to be a web standard for this? I do not want Firefox to
> store my keys for me. Or any browser. I do not want transparent
> authentication, I want it to be explicit, and I want it to be offline.

WebAuthn doesn't specify key storage in the browser. It specifies a common
JavaScript API for registering and generating assertions via an authenticator,
which in turn stores keys internally.

Wanting offline 2FA is perfectly reasonable, and I don't begrudge you that!
TOTP is perfectly fine for that purpose, so long as you understand the
tradeoffs you make in terms of symmetricity/phishability/replays/etc.

~~~
bjt2n3904
Thanks for the reply. Despite my gripe about this one aspect, your article was
very complete and well written. I've bookmarked it to revisit when I need to
implement 2FA in projects I'm working on.

That being said, I do not like a JavaScript API that provides access to this.
JavaScript, JS developers, and the web in general has a horrific track record
for security and privacy. To me, this is like the API that provides access to
the battery charge state, or my accelerometer for device orientation.

Why? Entirely unnecessarily! But it's a cool feature, so let's include it.
Suddenly, my keyboard typing is being exfilled through the browser, and I'm
being tracked by my battery charge state.

Do not want!

EDIT: I've maintained this position for "WebBluetooth" too -- a similarly
terrible idea. The less my browser does, the better!

------
peterwwillis
Could we not all agree that the only reason we don't like passwords is because
people try to remember them, they are reusable, they are simple, and once
stolen we have a hard time telling if the user is genuine?

If that's the case, can't we default to sending an out-of-bound request (e.g.
push to phone, or fall back to TOTP) for authorization, and if that's not
available, require a long, random, website-and-account-unique password be
entered that is kept in a browser's password manager?

The last case, "user lost everything", is more sticky. Can they still log into
their e-mail? If so, they can initiate a password reset (and we'll assume that
one day e-mail will be secure) and store a new random password in a browser
password manager, and register a new external device for push-auth. The hinge
point here is the e-mail account, which may need more robust protection.

This scheme should work with existing systems without new standards, be
resistant to password reuse & cracking, default to a second factor, allow
somewhat reasonable recovery, and not require a hardware token. (The idea that
the hardware token is needed to defeat phishing is bogus imho; the browser
password manager can auto-fill the password field for the correct site, and
refuse to do so for phishing sites)

------
a-dub
I've always thought that Bitcoin multisig was the best implementation of 2FA.
2 of 3 keys, one you keep hot, one pay someone to hold and sign/log on your
behalf (and let you know if something seems off) and one you file away in case
the person you're paying to co-sign with you disappears...

------
jsgo
I don't know the security ramifications to what they've done, but as a user, I
find Blizzard's current implementation to be the golden standard that everyone
else's implementation leaves me feeling bummed by.

I login, I get the "hey, we just sent the code VH3Z (making it up) to your
phone/watch/whatever" and then on both my phone and Apple Watch, I get a
prompt saying the Authenticator has that code and do I approve or reject. I
tap approve on either device and then the current window I'm in within
whatever Blizzard app (whether web or Battle.NET) switches to the actual
content.

So long as the phone or watch are present and charged, this is such an easy
experience.

~~~
deif
Same with Monzo banking app (UK). You buy something from Amazon that goes over
a certain threshold: Browser: "Waiting for third party auth". Phone: "Hey did
you approve this purchase? Yes/No". Very user friendly, intuitive anti-fraud
measure.

------
rkagerer
That long list of ways users subvert 2FA guarantees shows this technology
isn't yet user-friendly. (In a sense, passwords aren't either, as seen by all
the folks who keep theirs on a post-it note).

I'd like to see web developers implementing this also put some effort into
ensuring their sites are password manager compatible.

Even more kudos if you adopt a sensibly layered approach, allowing more
innocuous functions with a traditional login, then prompt for 2FA the first
time more sensitive activity is requested.

------
Avamander
I wish someone made a way to securely sync two hardware tokens - for example I
agree before setting up any accounts on my tokens that two or three of them
agree to sync data. I only have to make sure I do it once in a while.

Right now if I lose my TOTP or U2F device without setting both up on all my
tokens, I lose access. That's super bad.

~~~
floatboth
Bitwarden, 1Password, Authy etc. have encrypted sync/backup of TOTP secrets.

With hardware tokens.. unfortunately the real solution is "enroll a backup one
to all services".

~~~
Avamander
It's not 2FA when you have your password and the TOTP secret in the same
place.

------
ChrisCinelli
FIDO2 - [https://fidoalliance.org/fido2/](https://fidoalliance.org/fido2/)

That seems the state of the art at the moment. I wonder why the article does
not even mention that.

------
rmbryan
TIL : [https://en.wikipedia.org/wiki/Time-based_One-
time_Password_a...](https://en.wikipedia.org/wiki/Time-based_One-
time_Password_algorithm)

------
jandrese
Any idea of when HackerNews will support 2 factor authentication?

~~~
kogir
I actually wrote code for this ages ago when I worked on HN. It’s probably
still there, if only in git. But it really only makes sense for the internal,
secret parts that are YC related. For the forum just use a unique password.

------
use-authy
The blog writer doesn't seem to be even remotely familiar with Authy. Most of
the issues he discusses have been resolved with Authy.

~~~
jessaustin
Please provide more details about how your service resolves these issues.

