"Your YubiKey provides a second factor of security for your logins, beyond a username and password. Your YubiKey needs to be registered or paired with each computer, service, or site you use it with. "
Yeah, it's basically a smart card you can use with a bunch of popular sites like Google, GitHub, Dropbox, etc. (See http://www.dongleauth.info/ for a more extensive list.) Based on an open standard (FIDO U2F). Some versions also support storing PGP keys and the like.
- Clicking button is far easier and faster (it really does make a difference).
- Your smartphone is complex software and often attacked. Secrets can be stolen.
- Based on public-key crypto, no secret on the server.
- Built in phishing protection
- Your own private key is secure hardware that you can't read the key from
To be fair, a smartphone could also implement U2F and you would get some of the same benefits. Samsung phones for example already support UAF (the other FIDO) protocol.
Doesn't this mean that Yubi has the potential to know what your private key is (since they have to bake it into firmware before selling you the device)?
Most key dongles or smartcards let you load your own key on the device in a write-only fashion, or use the inherent secure cryptographic operations from the device to generate a key (which could subsequently tested if it is random enough through examining the public key portion and multiple tests).
> use the inherent secure cryptographic operations from the device to generate a key (which could subsequently tested if it is random enough through examining the public key portion and multiple tests).
It's not really possible to verify randomness this way - particularly for a device that already has a decent chunk of storage and crypto operahtions. Suppose the "random" number generator is actually an AES keystream coming from a key controlled by the NSA - how would you tell?
Unlike TOTP, U2F devices like the Yubikey protect against phishing attacks. The more expensive (not-just-U2F) Yubikeys also work as a GPG smartcard, which you can use for things like SSH authentication.
Can you explain how a smartphone-generated (or received via SMS) 2FA token is susceptible to pishing or other remote theft? I like the idea of the Yubikey but I just don't see how it's any different or better from receiving, say, a Google 2FA SMS on the smartphone that's always within reach.
I genuinely want to understand this so I'm hoping you or someone else can explain.
Smartphones are a very high target for everyone, from the FBI on down, and their attack surface is very large. So there is always (and will likely always be) security vulnerabilities in any smartphone, regardless of the brand/vendor/etc. These can be gotten at remotely because these devices have WiFI, bluetooth, etc in them, making them much more accessible remotely.
Yubikey's and the like are a high target item, but probably only for government-level adversaries, in general you have to be pretty well funded to attack these things, plus their attack surface is very very small, and most all of the attack surface is physical (i.e. you have to physically get the yubikey device to attempt any hacks on it). These devices generally only have a USB port, so to get at them remotely you have to first get remote access to the device(computer) they are plugged into, making it even harder of a target.
That's the general overview. Specifically, SMS received tokens are not secure (because of the SMS part not being secure). NIST recently declared SMS based 2FA to be a bad idea, for instance.
A phishing page can simply imitate the 2FA step in the login process and ask for the OTP to be entered, and then use it for its own login attempt. With U2F, the site basically authenticates itself as well, so a third-party phishing page wouldn't get anywhere.
Other comments expalain the vulnerbility of phones, but Linode's Time-based One-time Password implementation (tied to a phone app) may have been hacked server-side.
If a site looks like google and you enter your TOTP it will just take it and login.
The only thing TOTP protects against is somebody collecting logins and using them later. Today good phishers do attacks JIT, so TOTP is pretty useless for that attack vector (and that is the most importent one).
Your Yubikey can pretty much be connected to your computer all the time. So usability is actually better.
Plus there is of course the problem of smartphone security.
The 2FA apps on the phone (like authify and google authenticator) use a shared secret between the server and phone, plus the time, to generate the code. (This is the alphanumeric or qr code you set up with)
If someone can remotely root your phone, they can remotely retrieve your shared secret, and thus generate your authentication tokens.
It's somewhat easier (pressing a button on a USB device vs manually typing in a short code) and more secure (malware cannot steal the key from the USB dongle, and it's physically secure against tampering).
I use PingID for authentication and the manual code entry is only required as a fallback. When everything goes right, you just need to swipe to approve at the lock screen. Also, I'm doubtful there's any cause for concern about malware or physical tampering on iOS.
I do like the idea of being able to plug in to authenticate for ssh on any computer, however...
I invite to take a look at the just released Yubikey Handbook (https://github.com/ruimarinho/yubikey-handbook), an open source book on the many different Yubikey use cases and stories.
It has two modes. If you short press it, it will generate a one time password. A long press will output a static password. Both modes can be configured optionally.
The newer models support U2F, which is a challenge-response thing: the website prompts you to insert your YubiKey and tap it, and the key signs a response and sends it back to your browser.
I believe this adds protection against phishing because the browser communicates which origin (that is, which domain name) is sending the challenge, and that gets hashed into the signed response. So if trust-me-im-google.com proxies google.com, it can ask you for a one-time password, and the one-time password will be valid when google.com gets it, so the MITM can get your login cookie. But if you're using U2F, the signed response will say "Yes, I would like to authenticate to trust-me-im-google.com", and google.com will reject that.
That's very cool. Could you elaborate on the method in which the key accepts the challenge? I was under the impression that a Yubikey only acted as a USB keyboard - which ensured it's security by isolation.
The other answers are correct, but even before U2F the yubikey supported other methods as well. The have a classic HMAC based ChallengeResponse-Mode, a smartcard and PIV interface.
A yubikey 4 or Neo has 2 slots which can be configured for about 5 different things. OTP, challenge response, static password, and some other things I can't remember right now. It also has 3 slots for a PGP private key, signing key, and encryption key. It also has 4 PIV slots to use as smart card key storage for authentication (ssh), code signing, and other things I can't remember. Then there are additional PIV slots to hold expired keys you might want to keep around for some reason?
It has quite a lot of functionality for a little device. The main difference between Neo and 4 is Neo has NFC, where 4 supports 4096 pgp keys. 4 is the newer one, but nothing new has NFC yet.
I use it with luks for full disk encryption, ssh, and to store my pgp key for QTPass/Android Password Store. QTPass + passff extension for firefox is nice.
I haven't set it up as a 2FA for sudo yet, but that's possible also. I don't plan to use it for PGP encrypted email for the same reasons described here.
"Your YubiKey provides a second factor of security for your logins, beyond a username and password. Your YubiKey needs to be registered or paired with each computer, service, or site you use it with. "