SMS as a 2nd factor represents an engineering trade-off. Prior to its introduction, the only people who had access to 2FA were people who got $60 tokens from RSA. It blocks against certain classes of attacks, but is vulnerable to others (like malicious or insecure carriers).

Now, Apple users can use their fingerprint as a 2nd factor (e.g. for Apple Pay), but fingerprints have the unfortunate property of not being rotatable if compromised.

And there are FIDO U2F security keys, but you still need to issue $18-$50 tokens to each user, and you need host application support.

> fingerprints have the unfortunate property of not being rotatable if compromised

Coworker has a wonderful term for this. He calls fingertips "amputationware". It really drives the point home.

But there is another very good reason to avoid fingerprints auth methods. The scanners are by design doing some level of fuzzy matching, so if/when[0] someone finds a way to generate an input that reproduces the signal pattern from the reader well enough, it can be fooled. (Yep, done already.)

My personal take on fingerprint authentication is that they are not passwords. They are usernames.

0: http://engineering.nyu.edu/press-releases/2017/04/10/so-you-...

Fingerprints can certainly be "amputationware" if you refuse to give up your passcode and your threat model has a credible threat of amputations.

For most people, having their unlocked phone snatched out of their hands on the street[0] is a far more credible threat and somehow we don't have everyone saying you shouldn't unlock your phone outside.

[0] https://www.theverge.com/2016/12/2/13819288/uk-police-encryp...

Yeah - I was going to saw something about people with extreme eczema suffers (Which I happen to be one), can have issues with skin just splitting open on tips of the fingers. This is the reason I don't use my finger print scanner on my phone...

Do note however, that masterprints are not applicable for all current solutions.[1] Their statement is of course biased, but they nevertheless point out a significant flaw in the referenced study.

[1]: https://corporate.fingerprints.com/en/newsroom/faq-regarding...

How does it compare to the Vein scanning auth tools in terms of efficacy?

Obviously the non rotable issue remains (although less viable to amputation auth)

If you have a phone you can run a 2FA app though like Google Authenticator. Much more secure.

Note that one time codes do not protect against phishing the same way U2F does (U2F is always bound to secure origin).

U2F is great but everything is better than SMS.

SMS can provide transaction authentication:

"If you want to transfer $1000 to account 1243567890, confirm with code ABCDEF".

Assuming an attentive user, this protects against malware silently changing amount and recipient on a transaction the user is making - an attack the banks were struggling with. It also makes phishing much harder, since the attacker needs to convince the user to enter the code after reading this message.

Code-based 2FA is vulnerable to phishing where the attacker relays the phished credentials in real time. German banks were doing 2FA long ago, in the form of sheets of paper with one-time passwords (called TAN). Attackers were phishing those, so banks switched to "indexed" (iTAN) OTPs: The bank tells you which OTP to use, so someone who has just phished 1 or 2 won't be able to use theirs. Phishers started relaying the stolen credentials to the bank in real time, looking which iTAN the bank asks for, then asking the victim for the same.

Given these known capabilities of attackers, any 2FA method that is not phishing resistant and not bound to a specific transaction is not usable, and probably not better than SMS. Anyone can make a phishing site, running attacks on phone networks is harder.

Edit: Just realized that U2F would not be a suitable solution for banks, since it does not authenticate specific transactions, so malware could still swap recipient and amount.

U2F works because it is replay protected. Whatever you "authorize" the scammer to do means nothing to the bank when he tries to relay it.

Either he acts as a transparent proxy between you and your bank without attacking, or the authentication fails.

Edit: with local malware you're doomed unless you have trusted external hardware with a dedicated screen.

Excellent summary.

U2F was designed to protect login where you don't need more context except the site you're logging into and that's protected as part of the protocol. Abusing it for other purposes (tx confirmation) as you showed is not a good idea.

Transaction confirmation can be improved by using mobile banking app that displays the transaction info and has accept / reject buttons. The communication would go over HTTPS.

But the problem of trust goes deeper - how do you know that account X is the correct number for your intended recipient? You usually have this saved in you banking system and when it is compromised you'd still be convicted that you're sending money to correct account. Unless of course you have a paper backup of account numbers...

Except SMS is better than nothing, right? Yes it's flawed. But it's a harder attack than simple password auth. An attacker has to to target an individual and know their phone number, and be able to spoof their phone.

It depends. SMS is better than nothing as a second factor, but SMS has a weird way of worming its way into single-factor status. I think people should avoid SMS 2FA, and should be skeptical of the security of companies that offer only SMS and neither of TOTP or U2F.

This frustrates me endlessly about Namecheap. They only allow SMS, and, for something as valuable as my domain name (figuratively the keys to my kingdom), that's unacceptable.

Have you tried using a (free) Google Voice number for 2FA purposes? Google Voice has no/minimal customer support, so it should be almost as secure as your Google Account.

Haha, I love the reasoning there. I haven't, but you're right, I should.

Well if you manage to do that, let me know. To my knowledge creating a text/voice compatible Google Voice number is not possible in europe.

I had created one when I was in the US, so I do have one. I can't add a European phone number to it, but I can receive SMS with it.

I transfered my domain to route 53 and let them know this was the reason why.

If SMS can be used for account recovery (ie, 'I forgot my password' functionality) then it is probably worse.

2FA altogether isn't necessarily better than nothing.

At its worst, it opens up a social engineering / customer support "lol lost my phone" attack vector that didn't exist before.

SMS 2FA can be defeated by hijacking someone's number. Happened to me. One day I opened my Macbook and saw the "A new iPhone has been activated for your iCloud account". They had access to my number for hours after I called up my carrier.

Ok, a 2fa protecting anything of value (such as money) should not be trivially breakable by state actors.

U2F is a kind of OTP, no?

No, or yes if you replace shared passwords with EC assymentic crypto with added protections (test of user presence, taking origin into consideration - signature for Google.com cannot be used on fake-google.com, attestation - you can check remotely if token is from e.g. Yubico if you trust only them).

But what happens when thieves steal my phone? How do I authenticate then? Most places use SMS as a backup, which gets us back to the original problem.

People with popular YouTube accounts have to deal with this all the time and the advice right now seems to be to buy a burner phone on a false name[1] and never share the phone number with anyone, which is just crazy.

[1] Fraudsters are able to convince phone employees that they forgot their phone number and left their phone at home.

Easier: register with an SMS-enabled VoIP provider, like Twilio or voip.ms, and use said virtual SMS number as your 2FA. Rather hard to steal.

You can then set the service up to forward received SMS messages to your regular SMS number—but, if your phone is compromised/stolen, you can go back to the account and immediately turn off this forwarding.

---

Sadly, this approach reduces the security back to single-factor, since you get into the SMS account with something you know, rather than something you have.

You can at least treat the VoIP account like a password-manager: give it a long, unforgiving "master password." (Or a random password that's stored in a password-manager, if you use one.)

A lot of providers will block VoIP and SMS gateways being used as verification (see PayPal for an example).

There's a guy that does an SMS to web gateway with real telephony hardware. You pay by bitcoin and its accessible over TOR. You pay, he pops in a topped up PAYG SIM. You have a real mobile telephone number.

You can run your own private one at home with a Raspberry Pi/ttl serial adapter and a cheap SIM module. Or use a dongle.

AFAIK you can get a number from a different carrier and then transfer it to the VoIP carrier. When queried, it will still show up as "owned" by the original carrier.

It depends on how they classify; numbers are issued in blocks of 1000, and the allocations are public knowledge, but you can also do a real time carrier lookup, which changes after porting completes.

> Sadly, this approach reduces the security back to single-factor, since you get into the SMS account with something you know, rather than something you have.

I don't understand why Google Authenticator is supposed to be so conceptually different from a password. The codes it provides are a deterministic (and public!) function of a code shared between you and the party you're authenticating to. Or in other words, it's exactly equivalent to a password.

When I set up 2FA on github, they gave me a code to put into Google Authenticator, and also a bunch of "one-time reset codes" in case I lost my phone. Why wouldn't I just record the original code in whatever place I'm supposed to store the one-time reset codes?

The differences from a password:

1. Not shared across sites 2. Guaranteed minimum length 3. The portion going over the wire cannot be used more than once or after a few seconds 4. The phone app doesn't expose the seed or allow you to copy it off the device. Running on iOS has strong guarantees against access by other apps.

That's not perfect and U2F is a huge improvement but it's safer than SMS and given the number of google users who get attacked daily a reasonable incremental improvement.

Only your third point is actually a conceptual difference from passwords. In terms of the common idea that 2FA should be "something you have" plus "something you know", a TOTP seed is "something you know", not "something you have", but everyone talks as if the opposite were true.

Think about it a bit longer:

1. Passwords are selected by the user; you cannot prevent reuse. While it's technically possible that a site could allow you to set the TOTP seed nobody does.

2. Password entropy is notoriously hard to calculate programmatically – e.g. well known movie passwords or leet-speak are often judged as stronger than shorter true-random sequences – but you generate the TOTP seed.

4. As with #1, preventing reuse is hard. Knowing that all extent implementations offer fairly strong protections against accidents is a key difference.

Your finally point depends on how you judge the whole system: “something you know" can be told to someone else, which isn't true of TOTP. It's also always valid and reusable whereas the one-time code is closer to an on-demand verification. From the perspective of security boundaries, a desktop user accessing a separate token, phone, or arguably even an iOS user using a separate app is closer to something you have than something you know.

TOTP isn't the strongest form of MFA but it's closer to that end of the spectrum and, especially in consumer contexts, a huge improvement over nothing. In the real world, those kinds of security improvements are still meaningful even if they're not perfect implementations of a textbook concept.

> “something you know" can be told to someone else, which isn't true of TOTP. It's also always valid and reusable whereas the one-time code is closer to an on-demand verification

This is not correct. When I set up TOTP 2FA, the site generates a seed and tells it to me. It is always valid and always reusable, and it's no more difficult for me to communicate it to anyone else than it was for the site to communicate it to me.

Well, technically, everything that you have (and can provide as "proof") is susceptible to being interpreted as "something you know". If I know enough about that thing that you have, I can probably manufacture a good-enough replica that I can provide as "proof of ownership".

Think of the physical one-time tokens: If I know the data stored on it, I can replicate them too. So, are they "something you have", or "something you know"? The reason why they're "something you have" is that it's easier to have the physical ownership of the device, than to know they "secret" of the device. But, the same is true about Google Authenticator! In that respect, Google Authenticator can be, indeed, interpreted as "something you have".

Again, think of what that means in normal usage: it's technically possible but there's no UI to do it and in cases like iOS the system actively blocks it.

If you're building a consumer service, that's a big improvement over someone picking their dog's name and saving it in a Word doc on their desktop.

I don't know how google 2FA is implemented, but I'd just assumed the initial code is akin to something like an initialisation vector / nonce for a counter or CBC mode block cipher. With the counter being 'time', meaning the scheme works something like:

hash_fn(concat(IV, time)) -> func(somehash) -> [code seq. 1]

Then on the next round the IV is discarded and it becomes:

hash_fn(concat([code seq. 1], time)) -> func(somehash) -> [code seq. 2]

That's almost certainly an over-simplification / wrong; it doesn't seem very secure to just use the previous output as the IV for the next round. Maybe it chains all previous outputs together somehow, IDK. I should probably research this, given how much I rely on 2FA for security.

EDIT: The Wikipedia article on TOTP seems to suggest that you're right; the initial shared secret looks indistinguishable from a password (although the article is a bit vague): https://en.wikipedia.org/wiki/Time-based_One-time_Password_A...

With Google Authenticator you would have to use your one-time codes to reset it if your phone is lost. With 1password the 2FA is no longer linked to the phone, this way you don't have to reset.

Google will also let you move your Authenticator to a new device with access to the account from another trusted device without needing to 2FA.

So, for example, I can temporarily move Authenticator to an tablet if my phone is lost/stolen using my laptop, which is already trusted.

There are some potential security drawbacks to this but access to a trusted device seems a reasonable compromise between security and convenience.

Also worth noting: Google Authenticator is just TOTP[1] (X=30, Digit=6, HMAC-SHA-1 IIRC). You can just copy the URL from the QR code and use it from whatever you like, as long as your clock is somewhat synced.

[1] https://tools.ietf.org/html/rfc6238

Typically, you are asked to print out backup codes when you enable 2FA. In addition, you could copy these backups codes into your password manager and sync your password file with multiple devices, so whenever one device is gone you can access all your passwords, including 2FA backup codes from other devices.

If these backup codes are in your password manager, you're effectively* back to 1FA. Same with putting the TOTP seed into it.

* Yes, technically you need the 1Password file as well. But someone who compromises your machine will get access to both. Or if you have it synced to your phone and both are unlocked with a fingerprint, all someone needs is your device and a little effort to fool the fingerprint sensor.

Not that I recommend SMS, but if thieves steal my phone I turn off its Google voice connection and it stops getting text that particular phone #, which I can still get just fine in Google Voice. More to the point I do tend to feel like N-factor auth is often a sort of Matryoshka doll thing on one end or another more than anything.

This doesn't help if the bank shows your linked phone number when logged in.

You could also buy a dual SIM phone and buy a throwaway sim card with a phone number you do not share.

Take government issued ID into the bank. They can reset everything for you.

write down the secret from when you set up 2FA and store wherever you keep your valuables. Get a new phone and re-use the same secret.

The big problem that SMS solves that nothing else does is that you can be completely irresponsible/unlucky and it still works. You can lose your u2f key , lose any one time backup codes on paper, and so long as you can convince your phone company that you are you you're fine.

I don't think most people are responsible enough to deal with more secure MFA. Most people don't know how to keep custody of stuff like that.

> so long as you can convince your phone company that you are you you're fine.

Well I think the problem starts when someone else convinces your phone company that they are you. As we've seen several times now it becomes easier and easier to pull this trick.

As for U2F add more than one to your account (2 is minimum) and you are safe. The same applies to any kind of physical key (home, car, etc.)

I think there are plenty more people who would lose all their u2f keys than be attacked via the phone company. Sure, that's easy for you to manage, but not for most people.

I rather have to convince my bank I'm me as they have much higher security standards generally than the phone companies so less chance of someone else convincing them they are me.

Hopefully we'll get to a world where people keep a U2F key on their keychain, and use it for all their important logins.

We have a long way to go. People need to understand:

* How U2F works on their phone

* What if the U2F key gets lost or stolen (revocation)

* How to have a backup of the U2F key

* Are multiple identities possible (home/work/whatever)

I think a lot of this is close enough to the way mechanical keys work that it's not a huge leap. You can have more than one house key, you change the lock if a key gets stolen, etc. It's a little different, but not really more complicated.

One good thing is that we are moving towards where most devices will have USB type c as a port, so that mobile devices, laptops, and desktops can all share keys.

Well, people do have 10 fingerprints, but the bigger concern is how easy it is to find them and copy them. They're not secure. You'd actually be much more secure using toe prints as auth tokens, as gross and impractical as that sounds. Most biometrics are lame because they're so readily available. However, they are ridiculously useful because of how fast and conveniently they can authenticate you.

Honestly, this sounds like a much better technology: http://www.dailymail.co.uk/sciencetech/article-3220886/Forge... It transmits data through the human body. You could turn it on or off selectively, authenticate with anything you touch, and it would remain cryptographically secure.

Fingerprints are on file in police records. Whenever you get an US visa, a passport with biometrics or stuff gets stolen from the office and the police is called to investigate, you get fingerprinted.

That's true, but your toe prints aren't taken! xD Maybe someone can put toeprint scanners in shoes and add bluetooth...

I have high hopes for the W3C WebAuthn spec [1], it combines the security of FIDO U2F keys with the ease and ubiquity of devices with fingerprint scanners. Would be cool if Apple will support it too.

1: https://www.w3.org/TR/webauthn/

In the UK we got hardware authenticators for free. And most bank accounts for personal accounts are free too.

Security token devices for online banking is quite old now and came long before the trend of 2fa using sms, and they did not cost 60$. I have owned several by now and the first one one I owned was given as part of a gratis student package by the bank.

Yup. I had one from Symantec and was never charged for it. If I lost it, it would cost something like 10$. It was also quite small, close to a U2F key/USB flash memory stick but it did not have a keyboard to type a PIN on. Most do.

You can get a pre printed card for cheap for 2fa. No need for RSA token

You can even turn a profit here, I'm effectively paying a buck per preprinted one time code...

This is how it works often in Europe, a paper slip with a bunch of one-time tokens. I don't see how any technical solution would be better in security or usability.

U2F is just a button

There are plenty of second-factor mobile apps as well: Duo, Authy, Google Authenticator, and Symantec VIP access, just to name a few.

And now I'm trapped in this multi-app universe where every entity uses a different app. My employer uses Symantec, my school uses Duo, my bank has its own app (as does Steam), and a handful of sites use TOTP.

Argh.

At least TOTP (and U2F) are standards. All sites and organizations should be using them, not something they've created themselves.

DUO and other similar tools where you accept on the phone instead of getting a code and having to type it in can be more convenient than typing; and provided you get the push, you can take care of it from the notification so you don't have to find the app, so it's not terrible if you need seven different apps.

10 or 50$ per person is less than peanuts.

The challenging part is setting up the 2FA and integrating it into all your systems.

you could use a one time pad written one a paper.

I found that my Blizzard account 2fa app had been forgotten when I moved from my old phone, so I was locked out of an account I don't use very regularly. But they had an option to just text me a code, which worked and I got access to my account. I didn't know if I should be relieved because it worked or disappointed that their secure 2fa was so easily side stepped.

The Telco's here have been telling the banks this for years:

https://www.itnews.com.au/news/telcos-declare-sms-unsafe-for...

Apple's 2-Factor solution for Apple accounts requires a phone number, and SMS plays a role in reseting passwords in the absence of a secured device. I'm surprised more people aren't concerned about that approach. https://support.apple.com/en-us/HT204915 thread: https://twitter.com/spencerdailey/status/846516787533533184

It would be secure if mobile companies gave us APIs to pull information about number like has it been ported recently or number has been forwarded. Banks would even pay for it.

It's a clear text transmission on the signaling channel. Unless you encrypt the message from originator to recipient, having info on number ports or forwards won't changes the risk or susceptibility. It's nothing new either, how do you think the NSA captures text messages around the globe?

It's one time use. Even they did intercept it they would have it use before the person.

That's not the scenario. If I want into your account and I only have the password I don't wait for you to try to log in, I just try to log in and sniff the message to "prove" that I have the phone.

Easy enough if they requested it.

I thought the whole point of multi-factor authentication is to reduce the risk of breach by having different unrelated means of authentication, each of which is assumed not fully secure.

Wouldn't acquiring the 1st factor access (say, normal user credentials) be subject to similar social engineering attacks ?

Exactly why NIST declares that sending 2FA codes over SMS is insecure and should be avoided.

I feel mobile OS developers should create native multi-auth software on tbe phone.

Not just the phone company. Naive (ie old) people have been robbed by receiving a text saying "This is the bank, what's your password?" "Thanks. Now, what's the code we just sent you?"