Yubico Forum

I use my Yubikey with my LastPass and I love it. I use my Yubikey with GMail and.... well it is pointless. Google forces you to have your phone set up as a backup 2-factor auth. I have two Yubikeys and backup codes setup on my GMail and they still force the phone 2-factor to be setup. If you try to login and click the "I don't have my security key" button, you can continue using your phone as if the Yubikey was never part of the equation. This completely mitigates the security benefits of Yubikey. What makes this even worse is if you can get to my email account, you can reset my LastPass account too. So my phone is still the point of failure in my security setup at the moment even though I have upgraded to a dongle.

Has anyone else noticed this?

1. You don't seem to know what "completely" or "mitigates" mean. Not only do the words not make sense when combined, but they don't apply here. You seem to think that having the phone as a backup invalidates the gains of the yubikey when it does not.
2. Your phone should already be secured reasonably, and as such, the OTP if this method is used is reasonably secure. If you're using U2F, rather than auth, then your phone is actually more secure.
3. If you're using auth and just storing the tokens on the yubikey, then yes, the phone messages result in a very marginal reduction in security (it's still better than storing the keys on the phone, since there's no secret to be surreptitiously stolen, but it's not as good as yubikey + phone, since it only requires getting into the phone and your text message application; in my case that's yet another layer, since I use Signal).

Now, is it perfect? No. But it is definitely a significant improvement over the alternatives, both in convenience and security. As far as the phone being SPOF, that was the case either way. If they didn't have the phone number backup they'd still have access to the mail anyway as you've probably got it programmed on the phone. There's not really any getting around it, other than to look into using the yubikey itself to unlock the phone (this is doable, but requires root and a fair bit of modification; you also risk locking yourself out quite thoroughly).

_________________
Keybase User: sporkwitch
PGP Public Key: B54A 454A 2B29 9D83 0201 CB1B C136 07BD 83A9 E927

It's weird to hear the words "phone" and "reasonably secure" is the same statement. One advantage of tokens like YubiKey is that they aren't likely to carry malware, unlike most smartphones (regardless of whether you do install games on them or not ).

In my universe people don't say that PK-based U2F is less secure than a phone-generated OTP.

Having a phone as a backup is a valid option, but it definitely is of a lower security level than a PK-based YubiKey authentication (PIV, OpenPGP, U2F). I have no opinion on OTP.

Have to concede that some form of a backup is necessary because one can lose or damage his token (however unlikely that might be for some people). Pre-generated access codes work, and a smartphone as a backup works too.

P.S. Securing the phone itself with a YubiKey may work for Android (I suspect a good amount of contortions required to accomplish it), and practically impossible for Apple (iPhone, iPod, iPad) devices. If you know otherwise - please do enlighten me. And it does not defend against the phone being compromised by malware.

It's all relative. If you treat your phone like a computer, it's not really at much more risk than your computer is, at least as far as what you're talking about. You can make a phone reasonably secure (and if you're not satisfied with stock, there's things like Copperhead OS.

The reason I say that the phone is _more_ secure than U2F is simple: U2F merely requires physical possession of the token (this is why I still have a passphrase on my laptop _in addition_ to U2F from the yubikey, and not just U2F; think of U2F like the DRM dongles that were popular with expensive software in the 80's and early 90's). A text message, on the other hand, can be behind multiple passphrases (your phone's unlock code, and in my case, signal's separate passphrase; although the code was unencrypted in transit, the local copy is encrypted). Similarly, PGP and PIV both require the PIN to use.

As far as using the yubikey to unlock the phone, here's one example (not particularly difficult, but not without its trade-offs): https://nelenkov.blogspot.com/2014/03/u ... g-otp.html

EDIT: The Nexus 6 supports NFC unlock out of the box via the Smart Lock feature. Only hitch is to make sure you have the YubiClip application installed so that it catches the URI the tag opens (if you don't, it tries to open the OTP URI in your default browser; if you do have it installed it loads the OTP into the clipboard, which is much less intrusive, and more importantly, has less chance of leaking (if you modify the NDEF to have NFC give a static password instead of Yubico OTP, it opening the browser would leak the static password to Yubico).

_________________
Keybase User: sporkwitch
PGP Public Key: B54A 454A 2B29 9D83 0201 CB1B C136 07BD 83A9 E927

True, it's all relative. However there is a reason that security-conscious organizations move towards hardware tokens for keeping/using cryptographic keys (remote access, S/MIME) and for computer login.

But one important difference is - both your computer and your phone are likely to have malware that can harvest your keystrokes and browse through your files. A smart card is much less likely to be penetrated in that manner, so the keys it houses can be reasonably assumed to be secure (unlike anything that is stored on the computer, or on the phone).


Ha! I did not follow - thanks for mentioning it. Do you happen to know if it would run standard Android applications from Google Play Store? Or would everything have to be recompiled from the source?


I see your point. In the majority of my use cases the token is employed as a PIV card, so in addition to the mere physical possession you need to know the PIN. Returning to U2F though - consider the 2F part of it. You don't even get to touching the button on the token until you satisfied the remote end that you know the correct password. So the adversary needs both your password, and your physical token. Not impossible, but far less likely - especially for a remote attacker.


Once the malware (usually through a compromised application or one of many compromised ad-libs) gets on the phone (or on the computer), the unlock code does not matter any more. Somewhat better with Signal (presumably acting as a protected container within the phone space), but still - software is roughly equal to paper walls, practical for exploitation by remote attackers (something that is less feasible with U2F). But I see your point.


That is very nice to know, thank you!

Copperhead is still binary compatible with Android, so far as I know, so yes, you could install the usual Google services, but this would largely defeat the point (they're also not guaranteed to work, as Copperhead does tighten somethings down and isn't really concerned about making sure the stock google stuff is happy). I'm planning on trying it out as soon as I can afford a replacement phone (I have a Nexus 6, but I make a point of not doing custom ROMs unless I can afford to replace the device in case the worst happens).

_________________
Keybase User: sporkwitch
PGP Public Key: B54A 454A 2B29 9D83 0201 CB1B C136 07BD 83A9 E927

Well, since many people (myself included) want smartphones because of the applications they can run on it, rather than the pleasure of owning a powerful pocket-size computer with a secure OS - while I don't intend to download and run the entire Play Store warehouse, there are apps that I need to run (no, not games . So if Copperhead tightens things up so some apps might not run - I probably can live with that (since the apps I'm concerned for aren't "tricky"), but if only some apps would run while the majority won't - then I'll probably skip...

It uses the F-droid marketplace by default, but we're really getting into the realm of "google questions" at this point; these are things you could look up in less time than it takes me to notice and reply lol

_________________
Keybase User: sporkwitch
PGP Public Key: B54A 454A 2B29 9D83 0201 CB1B C136 07BD 83A9 E927

Completely mitigates the security, may be interpreted as ultimately weakens the security. Mitigate means to make less severe, but it also means weakens.

It really doesn't, unless you play a 6-degrees-of-separation game with synonyms. "Completely mitigates" is a nonsensical statement; mitigation, by definition, is incomplete. If it were complete, it wouldn't have been mitigated, it would have been fixed or some other term that implies finality and completeness.

Per Oxford:
1) Make (something bad) less severe, serious, or painful
1.1) Lessen the gravity of (an offence or mistake)

No other definitions are recognized. Most others (dictionaries) match or are nearly identical to the above. I cannot even find anything that gets close to your redefinition as "weakens".

_________________
Keybase User: sporkwitch
PGP Public Key: B54A 454A 2B29 9D83 0201 CB1B C136 07BD 83A9 E927