
Using Yubikeys Everywhere - tdurden
http://www.tedunangst.com/flak/post/using-yubikeys-everywhere
======
tptacek
You can have a security key on Google without a phone number, but you have to
enroll with a phone number and then remove it. Google won't allow you to
remove the phone number unless you have some other backup 2FA method
available.

The best Google (actually: everywhere) 2FA "stack" in Q1 2017 is:

1\. Hardware U2F

2\. Software TOTP (Authenticator app on your phone)

3\. Physically secured backup codes

4\. Disabled SMS

My experience with the Y4 hardware and, particularly, software has not been
great. I'm using the Y4 for SSH access (through ssh-compat mode on gpg-agent)
and it's mostly OK, but if I try to use PIV mode on the same token I run into
all sorts of problems. I'm bullish on U2F, but bearish on Unix token
applications.

~~~
my_first_acct
I have a concern about software TOTP. As tptacek knows (but I'll mention as
background for other readers), the various authenticator apps use the
standardized TOTP algorithm [1]. This algorithm uses a private key that the
server and the client (your phone) have in common.

The question is, where is the private key stored on your phone? According to
some posts from 2012 or so [2], on Android, Google Authenticator stores the
key unencrypted in an sqlite database, which you can look at if you have
rooted your phone.

This seems insecure. Is this still an issue with Android? Are Apple products
any better?

[1] [https://en.wikipedia.org/wiki/Time-based_One-
time_Password_A...](https://en.wikipedia.org/wiki/Time-based_One-
time_Password_Algorithm)

[2] [https://www.howtogeek.com/130755/how-to-move-your-google-
aut...](https://www.howtogeek.com/130755/how-to-move-your-google-
authenticator-credentials-to-a-new-android-phone-or-tablet/)

~~~
kabdib
The story for security on Android is really, really sad. Google should be
pressing really hard on the secure enclave button. Even game consoles have
better security [here I wanted to add: "... than the most secure Android
device", but that would be untrue, since I don't know all the Android devices
out there. Let's just say the situation is sad, verging on terrible because
it's Google, full of smart people who almost certainly know better].

Google probably can't get away with just trusting TrustZone, given the number
of manufacturers of SOCs and the opportunity for the folks doing chip-level
cut-and-paste of features to get things wrong.

I imagine there are patents in the way. Solve that with the realization that a
united front against adversaries (crackers, state-level actors) is better than
a fragmented one.

Solve the technical issues by getting the right 20 engineers in a room for a
week or two, to set a proper direction. Android could have great security in a
large set of phones inside of 18-24 months, with the right management.

Sigh.

~~~
tadfisher
While I agree with you, they do in fact have hardware-backed key storage these
days; it's just only available (and reliably useful) in recent Android
versions (namely those devices with fingerprint sensors).

Since we're on the subject, OP was talking about a perceived vulnerability
with _rooted_ Android devices. I highly suspect that even a decent secure
enclave solution would warrant some skepticism if the system around it is wide
open. For example, timing attacks or even plotting voltage draw on an
oscilloscope could leak some key information.

If you're rooting your device anyway, you should probably invest in a hardware
security key.

~~~
kuschku
Depends on where you live.

If you assume that the US government is not trustworthy, and a possible enemy
of you (possible if you're a journalist in these days), then an unrooted phone
might be less trustworthy than a rooted one with custom software (such as a
custom build of CooperheadOS)

~~~
tornadoboy55
Or just use an iPhone. The amount of marketshare Apple would lose if there was
even a hint of a US-intelligence backdoor in their systems keeps them with a
very, very vested interest to actively fight that.

------
drewg123
For Google 2FA, I'm pretty sure that it lets you remove the phone number once
you've added a 2nd 2FA mechanism. Eg, once you've setup Google Authenticator
_and_ a Yubikey. At least that's how it worked when I set it up a while ago.

Given that Ted uses OpenBSD, I'm surprised that he has not mentioned the
dumpster fire that is U2F on Chromium for BSD. This bug details the issue:
[https://bugs.chromium.org/p/chromium/issues/detail?id=451248](https://bugs.chromium.org/p/chromium/issues/detail?id=451248).
The last I checked, (~2 months ago), it was still a problem on FreeBSD. In
order to avoid the crashes, I needed to set a user-agent spoofer to Firefox,
so that I would not get a u2f prompt (and would instead be prompted for a
Google Authenticator code).

That became frustrating enough that I decided to try switching from Chrome to
Firefox so that I could use my Yubikey. I had to setup a u2f plugin for
firefox to use u2f on FreeBSD. And to even get u2f requests, I had to install
a user agent spoofer, and spoof a chrome user agent. Argh! So now I was
spoofing Firefox on Chromium, and spoofing Chrome on Firefox. My head was
spinning, and (because the spoofer spoofed old agent strings), I was getting
nastygrams from corp. sec. for running out of date, insecure browsers.

I finally just threw in the towel, and set up a Linux bhyve VM to run Chrome
under linux. The performance sucks, but at least I can finally use my
Yubikeys. On the plus side, I can use PCI-passthru to pass in a webcam, and
actually do hangouts on my desktop now.

~~~
bb88
You can't have a U2F Key and a Mobile Phone Authentication at the same time
with Google.

~~~
Thriptic
I believe you can have whatever auth mechanisms you explicitly allow. You will
get prompted to use the key if you enable it, but you can also select
alternative authentication methods when prompted for the key.

~~~
andmalc
You can't have a security key as well as the new Prompt method.

------
jlgaddis
I just recently started using my Yubikeys (in Challenge-Response mode) w/ LUKS
to unlock my drives at boot -- it's pretty neat!

On my primary system (a workstation, at home), I use the Yubikey to house my
GPG keys and I use the "derived" SSH key that lives inside of it for
authenticating to everything at $work. It was a bit of a PITA to get working
-- _points at gnome keyring_ \-- but it works great. I have a Nano I'm about
to set up the same way and just leave it in my primary laptop permanently.

~~~
elithrar
> I have a Nano I'm about to set up the same way and just leave it in my
> primary laptop permanently.

Do I misunderstand the purpose of a Yubikey/U2F device here? Is not leaving it
plugged in permanently effectively reducing the strength of the second factor?

With TOTP codes behind my iPhone lock screen I can be reasonably confident
that stealing my laptop isn't enough to break into my accounts (buying time
until I can contact our SIRT team), but with a device plugged in permanently I
lose that. Obviously an attacker would have to know my password, but that
assumption is a primary reason for multi-factor auth to begin with.

What am I missing?

~~~
jlgaddis
Leaving it in permanently is mostly for convenience. The keys are still
protected (by a "PIN") even if the laptop and/or Yubikey is stolen. There's
also FDE on the laptop itself, protecting the data.

~~~
hdhzy
You can also turn on touch-to-use policy so that you have to touch the yubikey
each time you want to use the key.

~~~
hvidgaard
This is important. Physical action outside the computer should be required to
access keys, otherwise a root access is enough to completely compromise the
system.

~~~
StavrosK
Where by "completely compromise" you mean "an attacker can use your second
factor while they have access to your computer and it's plugged in", which is
pretty far from actual complete compromise (i.e. "an attacker can use your
second factor at any time without needing to access anything of yours")

~~~
hvidgaard
In the context of it always being plugged in, and just handing out keys when
the system asks for it, I call it completly compromised.

------
TimWolla
Instead of using Yubikey through GPG to replace the SSH key one can also use
the PKCS#11 module they provide:
[https://developers.yubico.com/PIV/Guides/SSH_user_certificat...](https://developers.yubico.com/PIV/Guides/SSH_user_certificates.html)
This requires replacing GNOME keyring with SSH agents, though.

One can also use one of the 20 additional slots (82-95) the Yubikey 4 provides
over the Yubikey NEO by replacing the '9c' with '82'.

~~~
arianvanp
Using it through GPG already required you to replace Gnome Keyring with gpg-
agent. At least it did in the past.

------
Jaruzel
This article shows that U2F has LONG way to go before it is consumer ready.

Expanding on the 'key' metaphor, U2F (or MFA in general) needs to be as easy
as unlocking a door. Everyone knows how to do that; insert key, turn key, open
door.

Until things like Yubikey and their ilk are as simple as this (and I know it's
mostly the software that has to catch up), it's never going to be wildly
adopted on peoples personal logins.

I use Smart-card auth on my work laptop along with a 8 digit PIN to create
2FA, and although it's supposed to be universally supported across all the
applications I use, it really isn't. When I first started working here, I
spent several days very confused about where the smart-card did and didn't
work - I dread to think how the layperson works this stuff out.

~~~
homakov
I absolutely agree that it is not consumer ready. I'm trying to fix sharp
corners with Truefactor.io, any thoughts?

------
talkingtab
\- U2F is a standard

\- The FIDO Alliance is the body that maintains the U2F standard. U2F keys can
be "FIDO Certified" if they comply to the standard and have been tested.

\- Yubico is a company and Yubikey is a brand. Yubikeys often support more
than U2F so some Yubikeys are _much_ more expensive than a key supporting only
U2F.

\- Prices start at ~$10 for a FIDO certified key

\- U2F Zero is an open source project, not FIDO certified.

\- I have three U2F keys of various brands and they all seem equivalent so
far.

------
Animats
Too much trust centralization. How do you know Yubikey key generation hasn't
been compromised? They're an obvious target.

~~~
Godel_unicode
The logical end-state of this train of thinking is tamper-resistant key
generation and storage, with fully published sources and audited assembly line
production.

Except then they need to ensure that all the equipment on their line was
produced by trusted suppliers with the same level of disclosure. Ditto all
software which touches anything in the manufacturing process. It's turtles all
the way down, see also "on trusting trust".

~~~
nickpsecurity
Or just do it with open code & hardware on an ASIC whose process node is
verifiable by eye with a microscope against a reference image after samples of
it are decapped. Either by the owner or numerous third parties. You make it
sound _much_ harder than it is unless they're using unverifiable technology.
In that case, it might be pretty hard. ;)

~~~
Godel_unicode
That's ridiculous. People can't reliably produce good implementations of
crypto software, and you suggest they design and verify ASICs? My point was
that security is about understanding and accepting, not foolishly trying to
eliminate, risk.

Just a few of the mountains which need climbing: First, you'd need a
(actually) random sampling not just one (keep in mind any ASIC you test is
likely a write-off due to tamper-resistance). You'd also need a high assurance
supply chain to ensure your verification isn't premature (as well as
sufficient levels of tamper resistance/evidence). You'd further need to verify
the software around this hypothetical ASIC is free of bugs. You're restricting
yourself to software which can be performant on older slower process nodes.
You (almost certainly not an ASIC company) need to have an in-house ASIC shop,
or you need to vet an external one (sounds cheap and easy for the average
business). In fact, you need vetting of your internal staff at all stages of
this process.

You are making this seem _much_ easier than it is. There's a reason this
product, which there is definitely a market for, doesn't exist (and that
reason is much more mundane than the cryptolluminati not wanting it to "get
out"). Consider that Google did something like what you're suggesting. It took
them years (and they're Google), what chance does the average person/SMB have?

~~~
hvidgaard
I suppose you could use an fpga, but you still need to audit the assembly
line. It's not simple, and you will place trust somewhere.

~~~
hwh
So, more turtles waiting down there....

In the end, it is the attempt to create a positive proof in a system that is
not a defined formal system (real world vs pure mathematics). Impossible - as
you say, you need to place your trust somewhere. Even if it's your own
abilities. But that trust can always turn out to be not justified.

~~~
nickpsecurity
You need to make a simple interpreter or processor that's verified by eye,
brute force, or mathematically. An old example was FM9001 with newer ones
being VAMP (open?) and AAMP7G (proprietary). You do that on a node you can
verify by eye. You verify a random sample of the pile you ordered by eye. You
use it with cheapest, simplest, oldest parts for input and display that you
ordered in obfuscated way so they don't think source of order was important.
Then, you have hardware you can trust to do the rest of the calculations for
trustworthy hardware or software that's much better. Including image
recognition software to semi-automate your job of spotting things that don't
below in images of chips. ;)

------
nicolas314
There is still one issue left with Yubikeys: backups. When I loose my Yubikey
after I cautiously registered it with a hundred different sites and servers, I
would like to restore its secrets onto a brand new (blank) Yubikey and go
forward. The only official course of action given by Yubico today is to
manually un-register and re-register on all sites and servers.

Of course the key backup should be correctly protected, but that problem is
not hard to solve.

------
ehPReth
I ran into the same problem with ed25519 :/. Hopefully they upgrade and offer
this at some point!

~~~
dokument
neat. what are some use-cases for ed25519?

~~~
e12e
Ssh?

[https://lwn.net/Articles/590870/](https://lwn.net/Articles/590870/)

------
emgram769
>This doesn’t have any effect on the phone, however. I have to tap back,
return to the login screen, and enter my password again

I believe you can simply hit the login button (sans code) after validating the
login attempt instead of closing the application.

------
elchief
Tried my U2F yubikey on Chromium 48 on OpenBSD 5.9, but it crashed :(

------
dllthomas
eiecccevfhqwhgadshgnsdhjsdbkhsdabkfabkveybvf

