It is not really obvious to many people how U2F is better than OTP for two-factor authentication; in particular I’ve seen it compared with full-blown smartcard-based authentication, and I think that’s a bad comparison to do.
Indeed, since the Security Key is not protected by a PIN, and the NEO-n is designed to be semi-permanently attached to a laptop or desktop. At first this seems pretty insecure, as secure as storing the authorization straight into the computer, but it’s not the case.
But let’s start from the target users: the Security Key is not designed to replace the pure-paranoia security devices such as 16Kibit-per-key smartcards, but rather the on-phone or by-sms OTPs two-factor authenticators, those that use the Google Authenticator or other opensource implementations or that are configured to receive SMS.
Why replacing those? At first sight they all sound like perfectly good idea, what’s to be gained to replace them? Well, there are plenty of things, the first of being the user friendliness of this concept. I know it’s an overuse metaphor, but I do actually consider features on whether my mother would be able to use them or not — she’s not a stupid person and can use a computer mostly just fine, but adding any on more procedures is something that would frustrate her quite a bit.
So either having to open an application and figure out which of many codes to use at one time, or having to receive an SMS and then re-type the code would be not something she’d be happy with. Even more so because she does not have a smartphone, and she does not keep her phone on all the time, as she does not want to be bothered by people. Which makes both the Authenticator and SMS ways not a good choice — and let’s not try to suggests that there are way to not be available on the phone without turning it off, it would be more to learn that she does not care about.
Similar to the “phone-is-not-connected” problem, but for me rather than my mother, is the “wrong-country-for-the-phone” problem: I travel a lot, this year aiming for over a hundred days on the road, and there are very few countries in which I keep my Irish phone number available – namely Italy and the UK, where Three is available and I don’t pay roaming, when the roaming system works… last time I’ve been to London the roaming system was not working – in the others, including the US which is obviously my main destination, I have a local SIM card so I can use data and calls. This means that if my 2FA setup sends an SMS on the Irish number, I won’t receive it easily.
Admittedly, an alternative way to do this would be for me to buy a cheap featurephone, so that instead of losing access to that SIM, I can at least receive calls/SMS.
This is not only a theoretical. I have been at two conferences already (USENIX LISA 13, and Percona MySQL Conference 2014) and realized I cut myself out of my LinkedIn account: the connection comes from a completely different country than usual (US rather than Ireland) and it requires reauthentication… but it was configured to send the SMS to my Irish phone, which I had no access to. Given that at conferences is when you meet people you may want to look up on LinkedIn, it’s quite inconvenient — luckily the authentication on the phone persists.
The authenticator apps are definitely more reliable than that when you travel, but they also come with their set of problems. Beside the not complete coverage of services (LinkedIn noted above for instance does not support authenticator apps), which is going to be a problem for U2F as well, at least at the beginning, neither Google’s or Fedora’s authenticator app allow you to take a backup of the private keys used for OTP authentication, which means that when you change your phone you’ll have to replace, one by one, the OTP generation parameters. For some services such as Gandi, there is also no way to have a backup code, so if you happen to lose, break, or reset your phone without disabling the second factor auth, you’re now in trouble.
Then there are a few more technical problems; HOTP, similarly to other OTP implementations, relies on shared state between the generator and the validator: a counter of how many times the code was generated. The client will increase it with every generation, the server should only increase it after a successful authentication. Even discounting bugs on the server side, a malicious actor whose intent is to lock you out can just make sure to generate enough codes on your device that the server will not look ahead enough to find the valid code.
TOTP instead relies on synchronization of time between server and generator which is a much safer assumption. Unfortunately, this also means you have a limited amount of time to type your code, which is tricky for many people who’re not used to type quickly — Luca, for instance.
There is one more problem with both implementations: they rely on the user to choose the right entry and in the list and copy the right OTP value. This means you can still phish an user to type in an OTP and use it to authenticate against the service: 2FA is a protection against third parties gaining access to your account by having your password posted online rather than a protection against phishing.
U2F helps for this, as it lets the browser to handshake with the service before providing the current token to authenticate the access. Sure there might still be gaps on is implementation and since I have not studied it in depth I’m not going to vouch for it to be untouchable, but I trust the people who worked on it and I feel safer with it than I would be with a simple OTP.
The funny thing with the Yubikey, they’ve got that small metallised pad that serves as a pushbutton that a number of people mistake for a fingerprint sensor.I’ve got one of the old OTP-only ones I received when I attended linux.conf.au here in Brisbane. I recall doing some packaging of the libraries and doing some hacking with it, had it integrated into PAM for 2FA authentication: you’d type your password then hit the button on the yubikey and it’d spit out its OTP, PAM would verify that against its local database (no network access needed).The old OTP ones verified by decrypting the OTP code (which was encrypted with AES-128), then extract the counter value from that and comparing to the one on the server, so it didn’t matter how fast you advanced the counter (unless you made it roll over).
As far as I can tell the Yubikeys are limited to a single u2f profile. That is a big limitation with any of these sorts of hardware tokens. On my phone I have at least 4 profiles in Google Authenticator. I wouldn’t want to have to carry around 4 Yubikeys.If they allowed the device to handle multiple profiles it would be a great idea.
A single U2F profile **does not mean a single site**. This is the main difference in convenience of the SecurityKey.You can register multiple (I’m not sure if limitless or with a high limit, Yubico does not provide a quantified limit) of websites against a single U2F profile. This is not OTP.But unlike Google Authenticator you don’t have to fish out which one of the four profiles you have to copy over, the browser only provides handshake from the requesting website.
It’s better than that, actually. Each website get’s it’s own “profile” with a U2F token, and you can use your yubikey for doing U2F on an unlimited number of websites.When you first add your U2F token to your account on a website, the yubikey token does a procedure similar to the following:* Generates a new private and public key pair.* Encrypts the private key using a secret symmetric key that is stored on the token. This is becomes the “key handle”.* The public key and key handle are then sent to the server.(it’s a little more complex than this, but you get the idea)To authenticate, the server sends a challenge to the token, along with the key handle. The key handle is then decrypted on the token to get the private key, which is used to sign the challenge. The signed challenge is then sent back to the server. The server verifies the signature against the public key and, if it matches, authenticates the user.In reality it’s a little more complicated because one of the really cool features of U2F: the ability to authenticate/verify the TLS channel that is being used — making it virtually impossible to execute a man-in-the-middle attack.The beauty of it is that there is no identifying information that the service can derive from its interactions with a U2F token. This means that services can’t compare notes and detect if you are using the same U2F token for each service. Using individual physical U2F tokens for each service is no more cryptographically secure than using a single token for all services (not to mention a lot more of a headache).
Is it better putting all your eggs at one company based in the US with servers running wherever by server provider someone running X amount of Y code with Z employees, contractors and 3rd party providers having access to between 0-100% of systems ?Im sure the lazy user will figure out a way to give away the lastpass pwd to some 3rd party. Which then will enjoy all the backend access rights really conveniently.
“…neither Google’s or Fedora’s authenticator app allow you to take a backup of the private keys used for OTP authentication, which means that when you change your phone you’ll have to replace, one by one, the OTP generation parameters.”authy solves this problem: https://www.authy.com/It also allows sync of auth codes on multiple devices, (chrome extension, phone, tablet, etc.)
@Gerald,getting a backup of the “private key”, which in fact is a “secret” key (since there is no public key, is printing the QR code, which contains the secret key in plain text.Voilà: Your backup! 🙂
it may sound hypocritical from me as I use authy myself, but is it really a good Idea to let some company that promises to protect those important shared secrets. also having those floating around anywhere essentially degrades the 2FA completely. the whole point of any good “possession” factor is that it can not be copied (or at least cant do so without leaving instant evidence. like a U2F or a smart card which should both be equipped with a secure storage chip that cant be read out without destroying the stick and kinda trying to get at the chip itself. and that is also only if the chip doesnt have a big tamperproof feature which destroys the key in case something like that happens.
well mostly right but not completely.1) at start we create a nonce (a number that may only be used once)2) the privkey is basically the HMAC (a hash created using a secret key in addition to the content) of the Nonce, the AppID (aka the website you are using) together with the device secret.3) the keyhandle contains the same nonce used before and an HMAC of the priv key and appid4) the website gets the pubkey, the keyhandle and the actual registration/auth data (the challenge, the internal counter of the device and a signature)about using 1 vs multiple keys:technically you could even use the same key for multiple accounts because unless the website tries to send ALL the yubikeys it knows for all accounts (not a bad idea) there’ll be just a different keyhandle and stuff each time you register.but you should have at least a second U2F key or some other kind of backup method in case something happens to your U2F key.