Security keys are "transformative" and "revolutionary" for information security

#1

Originally published at: https://boingboing.net/2019/04/10/those-fallbacks-tho.html

2 Likes
#2

MFA is good. Avoid the Google Titan key though, it is a poorly-made rebranded Chinese knock-off of the early Yubikey. http://www.hexview.com/~scl/titan/

1 Like
#3

Later we started sending codes to users’ cell phones. Worth noting amidst some other comments on Twitter, this form of two-factor authentication is still way safer than relying on a password alone ; let’s not let the perfect be the enemy of the good (I’m looking at you, NIST).

I’ve belabored this point before, but I think it’s worth mentioning every time:

When your bank forces you to enter a username, a password, and a code that’s sent to your phone, every time you log in, that’s actual two-factor-authentication like Risher is talking about. It’s a pain in the neck. It’s adding a bunch of distracting administration tasks that slow you down. It feels almost like a step backward. But it’s genuinely more secure.

When a big web player like Google or Yahoo or Facebook begs you to enter a phone number to associate with your account, then never asks you about the phone number again (unless you need to reset your password) – that’s not two-factor authentication. In those systems, logging in is easy and convenient. The SMS based password reset mechanism is easy and convenient. And it’s also a security liability, it’s less secure than not having that phone number associated with your account.

This bothers me. The big web player in question always describes the association of a phone number as a step you should take “to secure your account.” In fact it secures you personally against the possibility of losing or forgetting your password. And that creates additional risks for the account.

Security keys are great, and all, but they bring some characteristics of old-fashioned keys, too: They can be lost, damaged, “borrowed,” stolen, etc. The key doesn’t know who is holding it.

4 Likes
#4

At a previous employer, we had an app that would generate a one-time code that changed every ten seconds. Seemed pretty secure to me.

#5

sadly it’s my understand ios locks down their nfc so even though you could use one with an iphone you currently can’t

1 Like
#6

The one time code is time based. once the initial seed value is determined then anyone can generate the same “random” code.

I know this because I’ve duplicated my code generator before and into my own software. (like a command-line version of Google Authenticate)

1 Like
#7

I’ve given up on digital security and privacy.

It doesn’t happen anymore.

I still have pins and passwords and whatever but everything is man-in-the-middle-able …and it is easy to automate so that everything and everyone is a target.

1 Like
#8

Does this mean something like Okta is potentially compromised?

#9

It is. It is way better than nothing, and in many ways better than SMS authentication which itself is still better than nothing.

The advantage of the hardware tokens like U2F is that they are immune to phishing. Code based 2FA is nice because it doesn’t require any changes to the browser – it just looks like another password field. But that means that anyone who can make a convincing fake login page can grab your password and authentication code, and then use that to connect to the target server. Since it is a one time use code they can only create a single session, and most systems require an additional code for password changes and other highly sensitive operations.

U2F creates authentication between the browser itself and the destination server. Even if someone creates a fake login page and convinces you to press the button on your security key, they can’t actually use the generated key. One nice side effect of this is that it makes persistent sessions much less of a security risk. So most U2F implementations only require you to authenticate with the key once or occasionally, and future sessions only require a password. With code based 2FA, if you let the hypothetical phisher store a session cookie, they can keep a persistent session and log in at their leisure with just a password. This is really bad because if you are e.g., logging into your bank account and get your credentials nabbed, then try again and succeed you are likely to notice malicous activity taking place at the same time. If the phisher can store those credentials and sell them or use them at a later time when you aren’t paying attention that can be a much bigger risk. With U2F this is much harder to steal a session cookie like this.

1 Like
#10

I like the idea of an app on my phone serving as the security key. No reason it cant be made as secure as a dongle. That is basically what apple pay is. But the process of replacing the key if lost is indeed the weak spot. I had a paypal security key until I realized that deactivating it was just a matter of logging in without it and checking a box.

1 Like
#11

Google (and I believe other services) offers different levels of multifactor authentication. At the most basic level additional authentication is required if you log in from a different client. For most people this is fine. If you need more security you can require the a token for every login.

#12

for the average user, the process of using a SK with an OS or a browser needs to become easier to use. As things are now, the average user will just give up.

#13

SMS shouldn’t be used for 2FA anyway. It’s a poor security mechanism. SMS is more of an anti-bot measure than a way of securing your account. By requiring a phone number for verification (and blocking all VOIP numbers) you make it expensive and difficult for a bot army to register thousands of accounts.

2 Likes
#14

It never did. There has NEVER been any such thing as complete security. Remember “locks only keep honest people honest”? The ONLY thing that any security measures can do is convince people that they don’t have the time, the money, the tools, the expertise, or the patience to get through your security measures. The bigger the group so convinced, the better. But do not delude yourself into think there ever was or ever can be foolproof security.

1 Like
#15

This article is literally about how security keys are intrinsically more secure than phone apps. You can build the dongle into the phone which is basically what apple pay does (as I understand. I haven’t used it), but then it only works on the phone.

#16

I have a Yubikey that I got as part of some promotion, but I’ve never used it. I looked into it a little, then decided I had reached the point where my convenience was more important to me than one more layer of security. (I do use Google Authenticator everywhere I can.)

#17

Don’t!

https://micahflee.com/2013/09/dont-succumb-to-security-nihilism/

3 Likes
#18

As someone currently (as in I’m posting this very message as a form of procrastination) trying to fix Yubikey-based VPN access for a customer, these things have A LONG way to go before they’re practical enough for wide adoption.

Time to get back to RRAS and NPS…

1 Like
#19
2 Likes
#20

No, the article literally doesn’t mention phone apps at all. It is largely about the limitations of SMS which is a standard that existed way before phone apps were even a thing.

Or build it into an app on the phone. Yes there are security advantages to keeping it all in a single chip as apple pay and good dongles do, but you can get all the other, important advantages of a dongle in a well designed software app.

And usb dongles mostly only work on laptops. Most people carry phones more than laptops.

1 Like