On Security Tokens

Mark Risher of Google extols the virtues of security keys:

I’ll say it again for the people in the back: with Security Keys, instead of the *user* needing to verify the site, the *site* has to prove itself to the key. Good security these days is about human factors; we have to take the onus off of the user as much as we can.

Furthermore, this “proof” from the site to the key is only permitted over close physical proximity (like USB, NFC, or Bluetooth). Unless the phisher is in the same room as the victim, they can’t gain access to the second factor.

This is why I keep using words like “transformative,” “revolutionary,” and “lit” (not so much anymore): SKs basically shrink your threat model from “anyone anywhere in the world who knows your password” to “people in the room with you right now.” Huge!

Cory Doctorow makes a critical point, that the system is only as good as its backup system:

I agree, but there’s an important caveat. Security keys usually have fallback mechanisms—some way to attach a new key to your account for when you lose or destroy your old key. These mechanisms may also rely on security keys, but chances are that they don’t (and somewhere down the line, there’s probably a fallback mechanism that uses SMS, or Google Authenticator, or an email confirmation loop, or a password, or an administrator who can be sweet talked by a social engineer).

So while the insight that traditional 2FA is really “something you know and something else you know, albeit only very recently,” security keys are “Something you know and something you have, which someone else can have, if they know something you know.”

And just because there are vulnerabilities in cell phone-based two-factor authentication systems doesn’t mean that they are useless. They’re still much better than traditional password-only authentication systems.

Tags: , , ,

Posted on May 1, 2019 at 6:14 AM • 42 Comments

Comments

Sed Contra • May 1, 2019 6:57 AM

What I am trying to figure out is how lotsaGs is going to use this for surveillance capitalism.

Ergo Sum • May 1, 2019 7:06 AM

I tend agree with both, the virtues and caveats of 2FA. And yes, SMS is still better than just a password. On the other hand, even 2FA can be vulnerable to attacks…

The source of this issue is the malware-infected devices that had been with us for a long time and will continue in the near future. The bad news? The compromised host and/or client device enable cyber-criminals to bypass virtually every two-factor authentication system.

Based on history, securing the client devices and authentication servers is not likely to take place anytime soon. In which case, replacing password with other authentication methods may provide a seemingly marginal security improvement.

Do we really need to replace the password authentication method now, without addressing the system vulnerabilities first?

Doug B • May 1, 2019 7:49 AM

And just because there are vulnerabilities in cell phone-based two-factor authentication systems doesn’t mean that they are useless. They’re still much better than traditional password-only authentication systems.

Unless they actually provide a single-factor way to reset a password, no?

Alex • May 1, 2019 7:50 AM

If you use Google’s Advanced Protection for your Gmail account, the system won’t allow you have a weak fallback option.

You have to associate 2 keys with the account. I think they recommend you keep the second key in your safe deposit box. You can also print up a list of one time codes for the account, print it up, and keep that in your box as well.

Obviously a magic bullet that solves every security problem does not exist, and will never exist. And I know that Gmail is just one account, and most people won’t do this stuff.

But Google, at least, is trying to work figure out solid systems that users can live with.

Anders • May 1, 2019 8:04 AM

Security tokens are not silver bullets.
It’s only a matter of time when malware adds capability
to emulate those tokens in software. Once they thought that
HASP dongles are also secure…

Dave Aronson • May 1, 2019 9:09 AM

“something you know and something else you know”? Idjits who implement what they think is 2FA often make it “something you know or something else you know”. I call this half-factor authentication. (Also applicable to when this is used for a password reset.)

Andrew • May 1, 2019 9:11 AM

Since SMS (and phone calls) can be compromised, and email can also be compromised, is the combination of the two for backup key recovery any better? That is, you need something from an SMS or voice mail sent to you and something in an email sent to you.

And would those ubiquitous security questions be any better if you could specify the question and the answer both?

Cassandra • May 1, 2019 9:11 AM

Security Tokens/Keys/Dongles need to be usable by your slightly bewildered aunt who doesn’t empty garment pockets before putting them through the wash, and isn’t entirely sure which day of the week it is. Passwords are easy to understand, easy to record and copy, and easy to keep in a (familiar to the user) safe place. If one is using a password manager, then the really important master password is the one which needs adequate security for the use case.

Technological solutions that are not accessible to the marginalised in society (the people living with reduced physical and mental capabilities) are a powerful force for inequality.

The day-to-day usability of tokens/keys/dongles needs to be much improved before they become adequate replacements for passwords for many people. How do you know when you can trust the device, how do you know it is working properly, how do you make a backup, how do you replace it, can you have more than one, can you allow your spouse/partner, brother, son, niece, neighbour, nurse, tradesman etc to use it in your presence, or remotely (i.e. can you lend it to someone?)? Obvious answers are there for those familiar with how the technology works, but for the average person for which it is just a magic box that allows them to make payments or read their emails, the answers are not obvious at all. People have all sorts of strange ideas about how technology works which don’t necessarily correlate with what is secure behaviour.

Cassandra

Vesselin Bontchev • May 1, 2019 9:43 AM

Many people (even infosec experts) seem to be confused about what “two-factor authentication” (2FA) really is.

Let me begin with some basics. There are 3 fundamentally different ways in which a human can authenticate themselves to a computer:

  • With something they know (password, passphrase, PIN)
  • With something they have (e.g., a smartcard)
  • With something they are (biometrics – fingerprint, face scan, palm scan, etc.)

Is authenticating via password and SMS send to your phone “2FA”? No, it is not! While the phone itself is “something you have”, it is not the phone that performs the authentication. It is you. You learn something (e.g., a number sent by SMS to this phone) and use this “something you now know” for authentication (together with your password). The correct term for this process is not “2FA” but “2SV” – “two-step verification”. You use two instances of the same factor (“something you know”) but obtained via different ways.

Why is this important? Because authentication based solely on a “something you know” factor(s) is vulnerable to phishing. If the attacker can con you that the page of his that you’re visiting is a legitimate login page, they can steal any “something you know” information that you enter for authentication purposes and use it themselves. The only inconvenience (to the attacker) that 2SV introduces is that the second step sent to the phone usually expires soon (in a few minutes) and is different each time, so it cannot be stored and used for a long time in the future. But this isn’t really the problem, because the attacker can easily automate the process of token stealing and immediate use.

Now, while most people are aware that SMS-based authentication is insecure because of this (and because of other flaws, like SS7, but let’s not get into this right now), they are usually quite surprised to learn that things like Google Authenticator running on your smart phone have exactly the same problem. The aren’t 2FA; they are 2SV and are vulnerable to phishing. Hardware tokens that display different numbers at the press of a button (like the RSA Token) suffer from exactly the same problem. Using them is not 2FA; it is 2SV.

This isn’t to say that a smart phone cannot be used properly for 2FA. However, for this purpose it is the device (the phone) that must perform the authentication – not the user. Such protocols are Apple Pay, SQRL, and others.

If you want to use real 2FA to authenticate yourself to web sites, use YubiKey or anything else that implements the U2F or FIDO protocol.

Note that contemporary “chip-and-pin” cards also use 2FA. The first factor (something you know) is the PIN and the second factor (something you have) is the chip on the card that performs the authentication.

Also note that the security even of proper 2FA depends very much on the threat model. For instance, proper 2FA would be authentication based on PIN (something you know) and a scan of your face (something you are). But this won’t withstand an attacker that can beat the PIN out of you and force you to look at the device for a face scan.

P.S. The 3 different authentication factors are also jokingly known as

  • Something you forgot
  • Something you left in the taxi
  • Something that can be chopped off

justinacolmena • May 1, 2019 10:09 AM

Two-Factor Authentication is a waste of time when the two factors are in cahoots with each other, which is always the case with proprietary dongles and tokens.

Engineered obsolescence is the law enforced by owners and operators of every chip fab and foundry.

  1. You must play the game.
  2. You are not allowed to win.
  3. You are not allowed to break even.

Anon==== • May 1, 2019 10:13 AM

  • Something you forgot
  • Something you left in the taxi
  • Something that can be chopped off

Do we need an iris or retina scan, too?

mare • May 1, 2019 10:28 AM

I can’t understand the resentments against security tokens, though.
Sure they are not silverbullets. There are actually no silverbullets. Security is always and always will be a trade off (that can be improved over time).

But, in my humble opinion, security tokens are the best approximation we have found so far.

Because the tasks for tokens are very simple (basically only holding a key, encryption and decryption), security tokens can have very simple architectures, that can easily be peer reviewed, if wished. (Of course, not all of them have simple and peer reviewed architectures).

If you don’t trust any particular vendor you can combine different vendors (2FA-nFa) to gain more trust.

Our multi-purpose laptops (I dont trust my laptop, do you) can keep their complicated layered (and unsecurable by design) architectures which are the source of so many of todays security-nightmares. But only if we outsource all our encryption and authentication to security tokens and let the multi-purpose computers do the other tasks.

Best of all, the Metaphor of keys for a door lock work quite understandable and transparent on security tokens. For most people, even grandma.

Of course, they need to be supported much more by websites as they are now. And of course in a standarized way (e.g. FIDO2 and Webauthn).
The standarization by the W3C seems to be very promising for the not very far future.

Leon • May 1, 2019 10:34 AM

To me the big problem is that we (as an IT industrie) seem to believe that we must fix the user. Because the user does not have to think for hem/her/…/ self.

Compare this to the lock on your frontdoor. Must people now nowadays what a good lock is and what isn’t. And that more security is more expensive. Sidenote: And of course there is a small group that would believe a “best lock for cheap” ad.

In the middle-ages people believed that a simple key was enough.

So it is about education. And Value for money.

Back to IT.

We should educate people (and site owners). Especially younger generations would easily grasp the concepts.
And yes, there will always be a group that is not able to grasp it, just as with the doorlock. Please stop focussing on this group.
We are moving from the “middle ages” to a digitized society, education should be part of this.

For your info: in my country (Netherlands) this IS done by campagains like How to bank safely (“check three times”) and Safe Passwords use

Leon • May 1, 2019 11:06 AM

Oh, and of course for Banking more advanced 2FA is needed than for a trivial site.

SFA • May 1, 2019 11:46 AM

@bruce and others,

Are you aware that Google Titan Security Keys are not sold on the Google Store in Canada, and presumably many other countries? Yes, grey market resellers exist but this is not trustworthy.

Also, Google’s Advanced Protection Program requires Titan keys so presumably this is also not an option for people without a US address.

Any idea what the story is behind this?

Thanks

Anders • May 1, 2019 1:11 PM

@Vesselin Bontchev

You are forgotting fourth factor – location.
This has been used also for ages. Some PDP-11 terminals
could be privileged. Novell Netware allowed locking user
login to specific workstation. Etc.

Petre Peter • May 1, 2019 4:30 PM

We have made progress. There is no doubt that I am more secure with a password than I would’ve been without a password. Two factor vs two step authentication is something I didn’t pay attention to, especially if different channeles are used for different factors or steps.

Q • May 1, 2019 4:30 PM

You know, when I lock myself out of my house & lose my key, a locksmith can let me back in and rekey my locks. Mind you, he doesn’t want to go to jail for burglary. So he’s going to want some verification that I am who I say I am.

We should find a way to reuse this model for Security Keys. We really need the physical visit part, and government issued ID part.

Drone • May 1, 2019 5:39 PM

“Unless the phisher is in the same room as the victim, they can’t gain access to the second factor.”

You bet the enemy is in the same room with you, it’s living inside your computer just waiting for you to plug that “security” dongle in – so it can read it and mimic it.

Anders • May 1, 2019 5:54 PM

@Drone

Sometimes it’s dead easy. Let’s take Estonian ID card into the consideration.
As long as the the victim has ID card in the reader (lot of people
keep it there constantly) and the reader is without physical keypad (again
very common situation), all you need is RAT with keylogger capabilities.
You capture ID card two PIN’s and game over.

Impossibly Stupid • May 1, 2019 6:28 PM

@Andrew

And would those ubiquitous security questions be any better if you could specify the question and the answer both?

Yes, to the extent that the number of bits each question represents as a challenge is much larger than the ~3 bits that are usually present for a pre-made list. Regardless, your response to the challenge should never be some basic fact about your life that is easy to find and/or shared by many sites. Always give them a random string with enough bits to satisfy your needs for security (e.g., a UUID).

@Vesselin Bontchev

Many people (even infosec experts) seem to be confused about what “two-factor authentication” (2FA) really is.

Worse, they use 2FA, or other protocols, in ways that completely negate their purpose. The greatest sin, as the article points out, is that the second communication channel is collapsed into a single channel, and/or there is no unique challenge that prompts the response. It’s simply too easy to sit in the middle of any authentication process that boils down to just sending information to an HTTP(S) server.

Is authenticating via password and SMS send to your phone “2FA”? No, it is not!

It could be if the protocol was more than just “now also send me the code I just texted you”. Again, the real issue that needs to be addressed is that the server connection can be spoofed.

You use two instances of the same factor (“something you know”) but obtained via different ways.

All factors reduce to “something you know” when they are used as nothing more than digitized information that is sent in one direction over one communications channel. That’s why biometrics are such a silly choice for remote authentication.

Also note that the security even of proper 2FA depends very much on the threat model.

Indeed. And I’m not even sure what threat Google thinks is significant enough to try to impose yet another dongle solution. There are all sorts of approaches that implement “the site has to prove itself to the key” that don’t involve that added expense/complexity. I’ve personally never been phished, mainly because my first step in registering an account with a site is to give them a unique email address (and, notably, one not controlled by Google).

Silent • May 1, 2019 9:00 PM

@SFA

Google’s Advanced Protection program may promote their Titan security keys but they do not require them. Any U2F/FIDO2 security can be used to secure your account.

@Drone

They way the security keys are setup, there should be nothing that can be read from the device via USB that would compromise the security of the system. The private keys remain inaccessible to whatever you plug the security key into.

Richard • May 2, 2019 1:10 AM

I like tokens, and other authentication factors like biometrics, smart cards, location-and behavior-based, etc. Passwords alone are mostly useless, and when passwords are replaced entirely with other factors, things will be much more well protected [and usable]. Until that happens, hopefully we can end password-reset links sent by email… and if were lucky, email too.

Jon Doe • May 2, 2019 4:29 AM

Well, I have a little story here about this, about 2FA, about Amazon.

I like many have an AWS account and I use it for my domain names and after the Linux kernel domain name hijack, where the owner had no 2FA configured, I decided it was high time I activated 2FA on my AWS account.

Now, your Amazon/AWS account can be the same account and for me they are.

I logged into my account and activated 2FA, with FreeOTP as my token generator.

Activation works, and I’m set.

Then to test the system, I log out, and log in.

Only, I can’t log in.

The 2FA code is not being accepted.

There’s then some text and a link indicating if this happens, you need to resynchronize. You enter two successive codes, and then Amazon knows where you are and it all works again.

Well, that page wasn’t working. I mean, the page wasn’t working; “internal error”. I couldn’t use it.

The next option is a support request. There’s a form you fill in but, crucially, you can’t send a message. All you can do is submit the form, which indicates the 2FA device is unusable.

You then receive an email, telling you a couple of things which are useless, such as how to disable 2FA, as this requires you to have a working 2FA in the first place, because you need to log into your account (the instructions were actually out of the date, too – if you searched manually on Amazon you found the correct instructions) and how to use the recovery process, which requires two forms of State ID (I only have one, a passport) and which also does not work, because it requires you to log into your account, and trying to do so brings up “internal error”, and, finally, if nothing else works, to phone Amazon.

I don’t keep a phone number. I can’t phone them.

There’s no way to reply, because the email address is a no-reply address.

I contact customer support, normal customer support, and talk to them – who else can I talk to?

I eventually get an email address for the 2FA team.

These jokers tell me there’s nothing they can do, at all, flat out, unless I phone them.

At this point, activating 2FA has locked me out of my Amazon account, and there’s no viable recovery mechanism.

There’s no indication when you turn on 2FA of what you will need to recover if 2FA fails.

That’s interesting, compared to email based mechanisms. With email based verification, creating the account is identical to verifying and recovering the account. The mechanism in use is the same. If you can receive the email to create the account, well, then you have working email and so you know (barring long term changes of email account) where the recovery mechanism is also based on email it will work.

This is not the case with 2FA.

The mechanism to activate 2FA, and to use 2FA, differ from the mechanism to recover from broken 2FA. Three independent mechanisms.

It can be the first works, the second does not and the third does not – as was the case here.

When that happens, you are locked out of your account – by 2FA, which you now desperately regret ever having activated. Death by 2FA.

In the end, I was able to recover – it turned out there are a second set of resynch pages on AWS, not on Amazon, and they worked.

Michael • May 2, 2019 4:59 AM

Correctly me if I’m wrong, this is like using a keyless entry fob for automobiles, except that we must buy this fob from a third party manufacturer, and then you gotta attach your online identity to this fob via some sort of activation process? How is this different from a cellphone sim card?

Dennis • May 2, 2019 5:37 AM

@Jon Doe wrote, “The 2FA code is not being accepted.”

The 2FA/2SV code process is often coupled with some sort of analytical intelligence based on geography and many other factors, commonly seen in “anti-fraud” technology. Sites who employ this technique already filter your logins based on your location and other statistics. I’m not so sure if this is any less inconvenient.

vas pup • May 2, 2019 11:17 AM

Kind of related to the subject

Half a face enough for recognition technology:
https://www.sciencedaily.com/releases/2019/05/190501114602.htm

“Using artificial intelligence techniques, the team achieved 100 per cent recognition rates for both three-quarter and half faces. The study, published in Future Generation Computer Systems, is the first to use machine learning to test the recognition rates for different parts of the face.”

“We’ve now shown that it’s possible to have very accurate facial recognition from images that only show part of a face and we’ve identified which parts are most useful. This opens up greater possibilities for the use of the technology for security or crime prevention.”

xyz_ • May 2, 2019 12:54 PM

“with Security Keys, instead of the user needing to verify the site, the site has to prove itself to the key.”

Can anyone explain me how the site proves itself to yubikey with U2F?
U2F is just typical challenge-response protocol. I receive phishing e-mail, there’s link to false login page. I click it. Phishing site uses MITM and connects to real page, takes real page challenge, forwards to me, my yubikey happily signs it, this is forwarded to phishing page and from there bad guys log in to real page with signed challenge. What i’m missing?

xyz_ • May 2, 2019 4:14 PM

@CallMeLateForSupper

What’s your point? That yubikey knows real server certificate?
How?

There’s two completely separate https sessions:

  1. from my browser to fake login page
  2. from fake login page to real server

As long as there’s green padlock, noone really pays attention
to the fake certificate minor spelling quirks. That’s the phishing
purpose, making people to believe.

Erdem Memisyazici • May 2, 2019 7:47 PM

Indeed, also don’t mistake using a YubiKey to partially complete a password with a lengthy random static string for “something you have”. That’s still something you know, even though you don’t have it memorized and it’s in your token.

Speaking of YubiKey I have this guy installed on my laptop https://developers.yubico.com/pam-u2f/ and I very much enjoy it in a medium level security setup. Keeps the people who peer over your shoulder to see your password away.

MrC • May 3, 2019 1:29 AM

@ xyz_:
TLS authenticates the webpage to the browser.
The browser tells the yubikey what domain the request is from.
The yubikey will only sign a request if the domain passed from the browser exactly matches the one previously passed by the browser at key generation time.

So, an ordinary phishing attempt using a lookalike url (e.g., g00gle.com instead of google.com) will fail, even if the bogus site has its own TLS certificate, because the browser will truthfully pass g00gle.com to the yubikey and the yubikey will say, “I don’t have a private key for g00gle.com -> fail.”

An attacker can still subvert u2f if they can fool the browser by subverting TLS (plus subverting DNS or routing) or they can compromise the browser to make it lie to the yubikey. But that’s a huge step up from run-of-the-mill phishing attacks. (Also, the compromise-the-browser attack is probably a “you’re already screwed” situation, so it arguably doesn’t count.)

xyz_ • May 3, 2019 3:15 AM

@MrC

So yubikey stores domain inside the key and this is
associated with each different priv key? I thought this was
FIDO2, where each site has it’s own private/public key pair?

But if something is possible to write to the inside of
the key, it could be also altered.

Silent • May 3, 2019 8:25 PM

@xyz_

The key pairs are generated and used as needed on the security key itself. Thus the security key itself does not need any permanent storage for things like domains, keys, etc.

The reason it would be unable to be phished is that when the attacker retrieves the key information from the real login page, the domain the registration took place on is part what was used to generate the key pair used for authentication. The phisher’s site (the one visible to the user and sent from the browser to the security key) would not have the same information so the security key would be unable to use that key for a different site such as the phishing site.

More information, including very helpful diagrams, can be found here:
https://developers.yubico.com/U2F/Protocol_details/Overview.html
https://developers.yubico.com/U2F/Protocol_details/Key_generation.html

TomS. • May 16, 2019 9:05 PM

Google Security Advisory: Bluetooth Low Energy Titan Security Key

https://security.googleblog.com/2019/05/titan-keys-update.html

“Due to a misconfiguration in the Titan Security Keys’ Bluetooth pairing protocols, it is possible for an attacker who is physically close to you at the moment you use your security key — within approximately 30 feet — to (a) communicate with your security key, or (b) communicate with the device to which your key is paired.”

“This issue affects the BLE version of Titan Security Keys. To determine if your key is affected, check the back of the key. If it has a “T1” or “T2” on the back of the key, your key is affected by the issue and is eligible for free replacement.”

Dark Reading links the Titan Security Key to FEITIAN Technologies
https://www.darkreading.com/endpoint/google-to-replace-titan-security-keys-affected-by-bluetooth-bug/d/d-id/1334742
https://www.ftsafe.com/replacement/

No CVE’s are given in any of the posts or websites. Dark Reading’s report credits Microsoft with the original discovery. I haven’t found any original research posted.

jeff birks • June 25, 2019 12:54 PM

We always talk about the user authenticating himself to the site/app, and forget it is just a important that the site/app provides authentication too.

Clive Robinson • June 25, 2019 1:44 PM

@ jeff birks,

We always talk about the user authenticating himself to the site/app, and forget it is just a important that the site/app provides authentication too.

And people also forget that it’s each and every transaction that should be authenticated not just the communications channel.

Also the authentication must go borh ways through the user and the token must not communicate in any way except through the Hunan UI and that it should not be upgradable “in the field”.

I’ve been saying this from the last century, but people are only just taking it on board… A quater century and counting to do the basics of security right and still not being even close should tell you quite a lot about why the industry is a failure except when it comes to making profit…

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.