Using Yubikeys Everywhere

You should basically assume your TOTP secret on your phone is as secure, and no more secure, than any other piece of sensitive information on your phone. If you don't trust your phone, that's a good reason not to use your phone to generate TOTP secrets. For users like that, you can configure a Yubikey to function as a TOTP token (but it's a pain).

For me, I trust my phone more than any other piece of computing equipment I own. I also rarely unlock my password manager on it, so there's no one attack that gets you everything you need by hitting either my phone or my computer.

If I had a generic, non-Google Android phone, or any kind of rooted phone, the equation would be different for me.

If this is a concern you might take a look at storing the secrets with keepass and keepass2android. It will keep them encrypted and let you generate them through the app once you've entered everything in (and can be configured to lock everything down again immediately). There's still other possible attacks but it should at least be as secure as your password on your database while not in use.

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.

> Google Authenticator stores the key unencrypted in an sqlite database, which you can look at if you have rooted your phone.

Interesting, actually that's exactly the reason why I like the TOTP algorithm over other two factor mechanisms. I can see what my private keys are, I can back up them, and I can even copy them to other phones I maintain.

Some would tell me it's not good for security, but I'd like to manipulate them in the same way I manipulate my SSH keys. It's just so convenient. If they are moved to TrustZone or something I'd be massively upset.

I don't use the Google Authenticator for this reason.

There are some Apps in the Playstore which make use of the Security Chip, if present which is the case for me, such that even if the phone were compromised with a rootkit the attacker would not be able to read the TOTP secret.

Yubico has "Yubico Authenticator", a Google Authenticator lookalike where all the codes are stored on the YubiKey and accessed over NFC (you need an NFC YubiKey, of course).

For general purpose operating systems, you can PGP encrypt the secrets and pipe them to a TOTP cli program such as oathgen (I wrote oathgen as a PoC when I was evaluating 2fa options a few years ago). This way, you have confidence in how your secrets are stored and used.

    https://github.com/w8rbt/oathgen

I share your concerns about mobile apps and browser extensions that do TOTP. All the ones I've seen store the secrets in clear text.

For Apple it won't matter since apps are heavily sandboxed and can only pass eachother data through predefined APIs. Jailbroken phones are another can of worms though, since you're literally leaving open an exploit to run unsigned code.

That would be up there with U2F. It's successor is the W3C Web Authn spec, Microsoft is shipping an early version of it where it integrates Windows Hello in the Edge browser: https://blogs.windows.com/msedgedev/2016/04/12/a-world-witho...

Its near impossible. Not only would they need to brute force it, but they'd need to brute force it in the 30 second window available before the code rotates again.

What makes you think that?

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.

I have this. It even knows that iOS isn't supported and doesn't ask for Yubikey but Google Authenticator code.

Indeed. And I was hoping that a rundown of 2FA from a BSD guy would mention this bug.

The firefox bug to implement native U2F has been open since 2014 [1].

1 https://bugzilla.mozilla.org/show_bug.cgi?id=1065729

gnome-keyring replaces gpg-agent and ssh-agent (on the system) but doesn't actually include all the functionality... basically, disable GPG/SSH agent support in gnome-keyring (if it's running -- and it's quite often automatically launched, even if you aren't aware of/expecting it), and explicitly use the real agent instead.

You can find the details on Google, but it's one of things that you wouldn't even know was a problem to be aware of.

Edit: Sorry... for LUKS, write a custom initramfs hook (shell script, in my case) to prompt the user for a "passphrase", use that as the challenge sent to the Yubikey, read the response from the Yubikey, write that to /crypto_keyfile.bin (in the initramfs, so not on disk), and the "encrypt" hook should use that file as the key to unlock the disk. You'll have to do it by hand once so that you can add the key (response) to a slot in LUKS. There's examples on Github of this but of course I didn't find them until I had already figured it out myself.

Amusingly I just ran across this[0] link an hour or so before this HN post went live.

I haven't done it yet, but it looks pretty reasonable. I prefer not to mix LUKS with random many-year-old GitHub repos.

[0] http://askubuntu.com/a/599826

Take a look at this: https://github.com/agherzan/yubikey-full-disk-encryption

The big win from a U2F device permanently plugged in to the laptop is as a defense against phishing.

I believe its like using it as an HSM; keys are protected against a remote intruder copying them, but physical access is another issue - you should still use it in conjunction with something-you-know, then it doesn't matter if the laptop is stolen.

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.

Imagine an employee works for a company where they can log into the company network with just a password (or alternatively, just an SSH key or TLS certificate). If an attacker gets their hands on this credential, by any means, then the attacker can use that credential to log in. These kinds of attacks can happen remotely in a variety of ways. Phishing is just one way. Malware is another - perhaps the employee downloaded apparently legitimate software that had a credential stealing trojan within it (e.g. keylogger or SSH key slurp). Or maybe the employee used their same password at another website that's been compromised, despite being told not to. Or maybe the password is just a bad password and the attacker brute-forced it.

An attacker who gains sufficient access to the right system can obtain your employee's credential, copy it, take it elsewhere, and use it later. They could use the employee's credential months later from anywhere in the world, and you could have difficulty identifying exactly how the credential was compromised originally, especially if time has passed and the attacker covered their tracks.

Now imagine a different employee who works at a smart company where logging into the company network (and accessing all company systems) requires multi-factor authentication using U2F or OTP in addition to a password. The attacker might be able to steal the employee's primary credential, through whatever means, but they have absolutely no way to obtain the employee's U2F or OTP codes remotely and electronically. The attacker simply cannot get into the company systems without having access to the MFA. This substantially raises the bar for a successful attack, and provides a great defense against attacking the company network and systems.

Yes, it's true that if you leave your MFA token in your laptop, then you could misplace your laptop and lose the token with it. In that scenario, though, the random attacker who discovers a random laptop in a cafe by chance won't know who it belongs to, or what company, and won't know the owner's password. Security is still preserved. The most plausible bad guy will sell the laptop to a pawn shop, not try to attack the owner's network. Furthermore, the employee should have been trained to call the IT helpdesk as soon as they realized their laptop and token were missing, cutting down the window for a successful attack.

To mitigate the risk of random loss, you'll want to employ full disk encryption, and disable the username auto-fill. This way an attacker can't get anything from the device without signing in, and has no information about whom it might belong to. Employ a policy that locks the screen after a few minutes of inactivity to make it difficult for attackers to swipe idle but still signed in laptops. These precautions all together make it incredibly hard for an attacker to get in the front door.

The only scenario in which security is compromised is if the employee's login credential has been compromised, and the same attacker has also physically stolen their MFA token. An attacker that is actively attempting to steal physical belongings from you in order to penetrate your organization is getting into Hollywood spy movie stuff. It's a real life concern for people doing certain types of work, to be fair, but those people usually mitigate the concern by keeping their equipment in secure facilities, and not taking their laptops to cafes to begin with.

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. ;)

Ssh?

https://lwn.net/Articles/590870/