For AWS you can use your yubikey indirectly for now via "Yubico Desktop" or "Yubico Authenticator" which emulate TOTP mode.
You can then go through the "Virtual MFA" flow in AWS and keep the TOTP secret inside the yubikey with a touch requirement.
This is nowhere near as ideal as U2F but it is a huge step above Google Authenticator which stores all secrets in plaintext in an sqlite database.
Also the 2FA support of 1password is entirely cosmetic if an attacker has malware on your machine. It decrypts your entire database against one secret.
This makes it sound like the secrets are just printed out and posted on a notice board somewhere, which is pretty much straight fearmongering.
The sandboxing between apps on non-jailbroken iOS (and to a lesser extent un-rooted Android) is such that having the secrets stored in an app's database renders them secure against basically any attack that doesn't involve physical access to the device.
Given that the app needs access to the symmetric TOTP keys for it to work, most of the available other options aren't appreciably changing the security model. Encrypt the DB with a magic secure-enclave-stored key? Now the app is just asking to decrypt the DB every time it's opened. What attack are you worried about where this new setup isn't equally vulnerable?
If someone gets a hold of your lost phone, without the secure enclave, rooting it is easy with physical possession. Whereas with a secure enclave, physical access with a locked device doesn't give the secret away.
> If someone gets a hold of your lost phone, without the secure enclave, rooting it is easy with physical possession.
Rooting an arbitrary Android phone is not easy, and rooting an arbitrary Android phone (especially the Nexus/Pixel flagship devices) without wiping the storage is really not easy.
After looking around, I agree that standard ways of rooting the phone do involve wiping it.
However, it still remains that the secret is sitting in plain text on a hard drive on the phone. If you unplug/unsolder the hard drive, you could just read it, like a PC.
Another advantage is that if the secure enclave is hardware/firmware linked to authentication (fingerprint / password), then there would need to be a vulnerability in that hardware process for a remote users to get a break.
This is the second factor of a 2FA, so I agree that in most cases, it won't be a large issue. Someone who phishes your password over email would empirically be unlikely to hack your phone.
> However, it still remains that the secret is sitting in plain text on a hard drive on the phone. If you unplug/unsolder the hard drive, you could just read it, like a PC.
"In plain text"... on a disk that is fully encrypted. Full-disk encryption has been available in Android for several years, and required for almost all of that time.
The sandboxing between apps on non-jailbroken iOS (and to a lesser extent un-rooted Android) is such that having the secrets stored in an app's database renders them secure against basically any attack that doesn't involve physical access to the device.
It's best not to rely on just one mechanism. Sandboxing mechanisms are also prone to exploits and bugs. For something as important as Two-Factor, Google engineers should be practicing defense in depth.
There is a perk to this method. If the user has a (encrypted) backup of their phone then the backup can be restored to a new phone and keys can be generated. If not replacing a smashed screen would result in the keys being lost, with very little gained in terms of security. I think this is one of the places where added security would risk making the user experience more hostile for little benifit.
(Talking about iOS here, but I’m sure it is similar on Android)
Yes Yubico Authenticator is super useful! Though...
The QR Code scan option does not work on Wayland, and you can also not manually paste the secret in Wayland.. You need to manually type it in which is a PITA. Luckily there is also a commandline version of the tool:
Hello, Yubico Authenticator maintainer here. Please file a github issue for the Wayland problem and we'll see what we can do. https://github.com/Yubico/yubioath-desktop
Yes, will do :) I'm afraid the QR code one is gonna be tricky, because of the way Wayland works. but the C/P issue is probably something with Qt + GTK3 that are confusing eachother
As a Yubikey fanboi since 2013, who was very excited about the prospect of using it for airgapping GPG and SSH keys circa 2014, 2018 me says: "you almost certainly don't want to do this"
Let's start with SSH. It's just plain unstable. If you try to set this up, you WILL have constant stability problems. I can assure you I have both personally experienced them and asked several other people who have attempted it to confirm that they too have various timeouts or other errors.
One alternative is PIV. PIV is even more of a pain in the ass to get set up, and has similar stability problems.
If I have a prescriptive recommendation for SSH, set up Duo for 2FA and use Yubikey-AES in "long press" mode (putting the key in slot 2). This gives you a strong hardware-backed authentication factor and protection against "Yubispam" (i.e. accidental credential leakage, a problem more severe than most would consider it)
As for GPG, well... GPG is a tire fire. I also went through the Yubikey GPG PIN bypass (not their fault, but since Yubikeys cannot be field patched, this involved physically rotating every key, which Yubico replaced for free, but still). GPG suffers similar random faults, and gpg-agent can die in a fire, but at least unlike SSH you're probably not using it as frequently. Still, getting things set up is ridiculously arcane, thanks to gpg being a byzantine tool and the crazy mutable state nature of ~/.gnupg
If you end up attempting to replicate this sort of setup, I can bet you dollars to donuts you will wind up asking yourself "Why did I think this would be a good idea?" after a few months
> Let's start with SSH. It's just plain unstable. If you try to set this up, you WILL have constant stability problems. I can assure you I have both personally experienced them and asked several other people who have attempted it to confirm that they too have various timeouts or other errors.
This has not been my personal experience at all. I've used this setup (Yubikey as SSH key) for 4 years now, and by "using it" I mean being connected on SSH 24/7, connecting every day, sometimes multiple times, from and to multiple machines. I have a USB drive on which I store a gpg binary for MacOS and Windows, allowing me to easily SSH from any machine.
GPG is a tire fire, I will give you that. But for the small subset of GPG that we need for yubikey+ssh, it can be made to work OK. You just need the latest version of GPG (2.1), have pcsc-lite and scdaemon installed and running, and put "enable-ssh-support" and "use-standard-socket" in your ~/.gnupg/gpg-agent.conf. This is not hard, and can be done in a 100% portable and sudoless fashion.
As for SSH, I'm not sure why you think it's a tire fire ? SSH works really well for its use-case. It might have problem if your internet connection sucks (like on mobile connections), in which case you can and should use mosh, which still works with this exact Yubikey setup (mosh initiates the connection and authenticates over SSH, and then establishes a UDP connection for the rest of the session).
I've been using this every day for about 2.5 years on each of the three machines that I use daily (each with its own Yubikey).
I sign anywhere from zero to 20 commits a day (providing my -- very long -- PIN each time) and open probably 200+ SSH sessions every day.
Once I've configured it on a new machine (e.g., I recently moved from Arch Linux to Fedora on these three machines), I have zero problems with it. There is no "unstable" issue for me at all.
Judging from my experiences as well as those of my siblings here, I have to wonder if perhaps "you're holding it wrong".
ETA: You will almost certainly run into trouble if you use Gnome (or, more specifically, gnome-keyring). I use XFCE everywhere, though.
That's my experience too (using gpg for ssh). While I remember that gpg agent can die once in a while it's very rare and the benefit of having keys in a separate device and using them on any machine instantaneously is certainly worth it. Not to mention U2F and built in TOTP. I can easily login in on a friend's machine without sharing any private/secret keys.
I definitely noticed the same thing on my MacOS computers vs my linux. What _seemed_ to be the solution for me was that ssh-agent gets auto started by Mac. My crazy workaround was editting that service with root permissions and have it launch gpg-agent instead
There's probably a better solution, but, that's what worked for me
FWIW, I have a MacBook Pro here that I've used it on as well. That was the primary machine I used all day every day until I built this workstation about a year ago. Nowadays I don't use the MBP very often at all, but I did just go check and, yep, it still works on there too.
"Works" in a one-off trial or with daily use? What I'm talking about is an unacceptable failure rate in the course of daily usage (by which I mean failures at least once or twice a day, sometimes considerably worse, over the course of establishing several dozen SSH connections daily)
If your OS X daily driver setup is truly stable, can you share all of the details? What OS X version? Yubikey model? GPG version? OpenSSH version?
I know at least a dozen people who have shared my experience so if there is a magic path to stabilizing it, I'm all ears.
It worked with daily usage from the time I set it up (shortly after buying that particular MacBook Pro, in October 2016) until the time I quit using that machine all-day every day (c. December 2017). In addition, it worked on the previous MacBook Pro I had as well.
It still worked when I spent five minutes on it earlier today. Obviously, that's not any extensive testing but I have no reason to believe it has somehow broken itself in the time it's been sitting on a shelf, turned off.
I'll grant you that it's certainly not the easiest thing to get up and running... but I also know that it can be done and that it can work quite well. TBQH, if it had been that much of a pain in the ass, I wouldn't have bothered.
FWIW, this is a mid-/late-2016 MacBook Pro, running 10.12.something (never updated it to High Sierra), with a Yubikey Neo. GPG came from homebrew, IIRC, and SSH as shipped with the OS. I'm on mobile at the moment but I'll try to remember to go back and check all the version numbers and such later, if you're truly interested in them.
It sucks that you experienced so many issues with this but I think there's enough anecdotal evidence here to show that this can all be made to work -- and work reliably.
Anecdotally, I can confirm that this is probably the deciding factor. I use a Yubikey daily on both macOS and Linux - Linux smartcard support is rock solid, but it's really spotty on macOS.
Sure. Let me go back through my notes from the installation and I'll add the relevant parts here. Note that my Yubikeys were already all set up, though (i.e., the GPG keys -- and "derived" SSH key -- were already present on them).
---
ETA: I've posted my "first attempt" at remembering/including everything in a gist [0]. It's very likely that I've forgotten something, though. Apologies for the formatting and such, I was hurrying.
I've been using a yubikey for at least 3 years on a practically daily basis for signing and decrypting email (all of my emails are encrypted) and for logging into my various servers via SSH on various Linux laptops and desktops, an Android phone (via NFC) and very recently a Macbook running OSX. My experience is nothing like yours. I have never had anything resembling a stability problem.
Same question to you which I asked in the comment linked below... if your OS X setup is truly, actually stable for a daily driver and not just something you use here and there, can you share details?
Are you perhaps reflecting on the OSX experience a couple years ago? Things have really matured since then.
I have deployed yubikey 4 based ssh auth, commit signing, and password management to enigneering teams at 3 companies in the past 2+ years.
The Linux experience has always been solid and as of gpg 2.1+ and High Seirra mostly fixing their smartcard stack, I can say the OSX setup is now quite reliable as well.
Aside: I would -not- recommend Duo to anyone. Beyond putting your security entirely in the hands of a third party with unknown internal auditing and security practices, there is no way to disable SMS 2FA for the admin accounts and support has steadfastly ignored requests to allow this to be disabled. This means sim porting + phishing and you cna control a duo admin account. There is also no secure element componet involved with Duo so malware on the phone can bypass it if sophisticated attackers are in your threat profile.
That's very much not my experience. I agree that the setup is harder than necessary and if you get something wrong the errors are not helpful. But once it works, it works. I've been using yubikey with gpg-agent for ssh auth for years and it generally just works. I've not seen the stability problems you experienced.
I don't know about Yubikeys, but with FST-01 SSH (via gpg-agent, essentially same setup as the linked article) just works. Using this for half an year and no complaints.
Sometimes it doesn't immediately see the key after reboot and I need to plug it out and plug back in. I think this usually happens when I dual-boot and switch between different OSes, as same-OS reboots are usually OK. Haven't exactly paid attention, though. I rarely reboot my desktop machine and I don't keep the key plugged into laptops.
Also, very rarely gpg-agent gets stuck and I have to KILLAGENT /bye. But I think that happens, maybe, once in 2 months or so. Docker (just a random example) gives me more headache.
This is essentially a diagnostic command, not really a fix ;)
For me, when gpg-agent gets "stuck", this command just fails. I forgot the exact message but it tells me that it can't find the device. `gpg-connect-agent KILLAGENT /bye` and then `gpg --card-status` (will automatically start a new gpg-agent daemon in the background) does the trick for me, but it's the first command that matters.
(Could be just `killall gpg-agent`, I guess)
Oh, I think on Windows, once I had to restart the Smartcards service, as restarting the agent haven't helped. Don't know what it was - I've experimented with OpenSC around that time so could be just about anything.
I've been using this setup daily for years, and, I've only 1 problem - annoying as hell - but something I can live with.
Whenever I use the key for U2F, the gpg access to the card will fail until I `killall -9 scdaemon`. I've had this same issue on both Ubuntu, and openSUSE. And yes, the -9 is necessary to actually kill the process and allow gpg to restart it.
An alternative to this is https://krypt.co/ which generates keys on your phone’s secure element/enclave and communicates with your laptop via bluetooth. It has a straightforward script to copy another public key from a backup phone to all your authorized servers, and the UI is excellent for signing git commits and authorizing ssh sessions. Doesn’t yet support U2F.
I really liked this but the notification requirement on iOS killed it for me. I can’t remember the exact details but it is (roughly) not possible to suppress authorization request notifications because on iOS notifications are the only way to wake-up a backgrounded application. Net result is a notifications every single time krypt authorizes via your phone.
This may not be a problem for many people but it drove me nuts. It is unbearable if you use auto-complete on the command line in eg SCP.
> Backing up your private key reduces its security to the security of the backup. We do not currently support backing up or extracting your private key. In the future we may add key splitting among team members or transferring your private key directly to a new phone.
All my data that the private key would be protecting access to is backed up, so I've ALREADY bought in to the idea that my security is bounded by the security of my backups. It is not clear to me that not letting me back up the private key actually does anything to help my security.
In fact, it may weaken it. Their FAQ says that if I lose my phone what I'm supposed to do is remove my public key from all my accounts, get a new phone, install Kypton on it, generate new keys, and put the new public keys on my accounts.
To do this, I have to have a way to access those accounts without using my private key. That means my security is bounded by the security of my non-Krypton access method.
If my non-Krypton access method is strong, that means I've got to be set up to deal with strong non-Krypton secret management...but if I have to do that anyway what do I need Krypton for? I can just manage my primary access method secrets myself too.
Also, what if the site requires two factor for the alternate access method? I'm probably going to be using my phone for that...but remember we're talking here about the case where I lose my phone, so I lose both my primary access (Krypton) and my secondary.
Note that on iOS, Krypt supports key generation using the Secure Enclave on the iPhone 5s (Sept 2013) and newer. In those cases it's impossible to extract the private key without finding a zero-day in the Secure Enclave coprocessor.
"App developers can do the following: [...]
Generate and use ECC keys inside Secure Enclave that can be protected by Touch ID or Face ID. Operations with these keys are always performed inside the Secure Enclave once it authorizes their use."
You are supposed to store a physical paper with some secret codes that gives you access, but you are always on an three day trip when you need to do these resets.
When the secure enclave came up in the context of contactless payments at a 34CCC talk, it was suggested outside of Apple as an iPhone vendor, the type of card operation requiring it are avoided by Google and others because lack of cultural and technical buy in from HW devs.
No real benefits that I’m aware of, and until Google starts to care about privacy more I wouldn’t expect them to invest in developing a secure coprocessor like the Secure Enclave, so you’ll probably be limited to 3rd party alternatives such as yubikey for the foreseeable future.
The Android team has actually made a lot of progress on this front, and unlike solutions by Apple, Google lets their solution be audited by anyone as they release all the source code.
Android has the hardware backed Keystore API for interacting with secure elements. Integration for this started in android 6.0 and is mandatory in 8.0.
I will check this out but as the guy in the 34C3 talk said, and he makes his living in building NFC payment solutions for bank and payment integration, heterogenous vendors with little reward is why they, meaning Google Android and others, moved to host card emulation with ephemeral tokens; structurally and technically only Apple has the supply chain and volume for their ecosystem to make it happen for secure elements, aka secure enclave as it is known in these payment processing workflows.
Google doesn't design android hardware outside of their own models. It's not within Google's power (realistically speaking) to force all hardware vendors to start manufacturing secure enclave.
This evolution in hardware design will start at the top companies and young startup companies (far and few between in the cellphone market) and trickle down to the rest as the price becomes commoditized.
In both cases you would lose access to your key, similar to losing a Yubikey. You can find instructions for provisioning a backup phone here: https://krypt.co/docs/start/backup.html . The upcoming teams product will make backup as simple as having multiple team admins that can re-provision each other in the event one loses their phone.
nice service! windows? i know.. but you cant get a used macbook for 50$. kr install didnt work by the way but the debian linux bash cmds worked in the win10 linux subsystem.
Windows support is slated for the first half of this year (you can follow this issue: https://github.com/kryptco/kr/issues/87 ). In what environment did the kr install fail? We only currently support Bash on Ubuntu(16+) on Windows.
How much will this (eventually) cost? I'm hesitant to adopt any new workflow tool without knowing what it's gonna cost me once I'm completely hooked on it.
Krypton Core (storing/using your SSH/PGP keypair) will be free forever. Stay tuned over the next couple months for updates regarding the teams product.
You want to enable user interaction flags to defend against someone with remote access to your machine.
$ ykman openpgp touch aut fix
$ ykman openpgp touch enc fix
$ ykman openpgp touch sig fix
This will require the yuibikey be physically touched for each sign/decrypt/ssh operation which while simple is something a remote attacker can't perform.
> you want to use "fix" instead of "on" to prevent an attacker from just turning it off again.
An attacker also must know you admin PIN (required to change this setting), so there is really no need to use "fix" instead of "on". To be able to toggle this off, you must reset your yubikey (paraphrasing the docs).
On Android, we provide the OpenPGP implementation OpenKeychain that now also supports an impressive list of Security Tokens (https://github.com/open-keychain/open-keychain/wiki/Security...). In our newest release, we also support YubiKey 4 over USB-C, which is a great alternative to NFC (which is only support by YubiKey NEO).
Using a sc like yubikey is great for security, but has performance implications for parallel tasks like salt-ssh across a bunch of hosts. Yubikey can only handle a single thing at a time, and is a touch slow, so if you are using salt-ssh to run a command on multiple servers, and if that salt-ssh happens to use GPG to decrypt pillars, then you're going to be waiting hundreds of times longer than you would using the vanilla, parallelizable ssh agent and scdaemon-free gpg-agent.
I use GPG signed tar balls for that, mostly it's just to run scripts on multiple servers, but also useful for file transfers. You still have to fix secure transfers between hosts but you do not authenticate the connecting clients, but your client just need to verify host keys to protect against MITM. Works on pretty large installations.
I started doing it like this when I only had Debian machines, and just used apt and Deb archives, but I never could find the time to hack Apt to be a perfect fit for it and it ended up being hell on other OS.
On a tangentially related note - I wonder, are there any OpenPGP Cards with EdDSA support with a "true" tamper-resistant HSM?
Gnuk-based tokens (FST-01, Nitrokey Start) support Ed25519 keys, but while there is no obvious security holes (i.e. debugging is disabled etc), they're most likely not safe if left unattended in hands of an untrusted third party.
Pretty sure the Ledger Nano S meets your criteria, but I gave up using it as a PGP card after some seriously questionable issues like the fact that pinentry would always ask for my PIN on the host machine even though I had it set to only ask on the “card”. It’s just a big mess all around. Same thing with FIDO. It only seems to work in chrome even though Firefox theoretically has support.
Firefox supports the FIDO U2F spec to the letter while Chrome requires legacy polyfill script that doesn't use the same exact API. So it's possible to support both but it's not as straightforward as it should be.
Nothing is safe if left unattended. It’s trivial to make a ‘proxy’ RF device that sends your PIN to the attacker and receives whatever data you would expect from your original hardware token.
at the end of the day no encryption is perfect... security is all about making it harder for an attacker.
A physical device certainly raises the bar..
that said the RF proxy attack is interesting, I'm sure it's non-trivial to do, as the device has to look legitimate. Nonetheless I better wrap my laptop in tinfoil from now on :)
Btw you can also do SSH, GPG and 2FA also with Trezor, which has the advantage that for all functionallity you can have a one "24 words" seed backup, from which everything is determined. Oh and you can of course use it as bitcoin wallet :)
We use Yubikey for our production systems and yes: every operator has two keys that have been configured and registered in our access database.
We decided though not to make our backup keys hot. It's a manual operation to enable it. The risk that everyone could simultaneously lose their key was lower than the risk of a backup key being lost and then used--since a person isn't likely to routinely check on their backup keys the later problem may go undetected for some time, whereas you know the day you lose your primary key and must report that situation anyway.
My Yubikey is provisioned with a SSH key generated on an air gaped laptop running Tails OS (live cd). The master key and subkeys were then saved on a separate encrypted SD card at the same time for backup.
Sortof. In practice, I have 2 "live" yubikeys per purpose, since I want a USB-A and USB-C set depending on whether my computer is plugged in to the hub on my desk or mobile.
That gives me redundancy in case I accidentally dropped one in a blender or whatever. But also for anything high-criticality (basically anything where losing both yubikeys would lock me out permanently without further backups), I have another yubikey sitting physically-secured. It works out nice, since that's the same approach I was taking w/ "security question" answers and other recovery tokens.
All the services I'm using it on require some sort of backup 2FA method, so I simply use an authenticator app (that I have to use anyway since not all websites allow U2F keys) as a backup method.
Never managed far in messing around to use Yubikeys for GPG and SSH. It's nice and all, but U2F keys are useful without it as well.
I lose things. Frequently. Key fobs have fallen off my key chain. Someone once snail mailed me a flash drive which I'd lost (and which contained a single scanned invoice). I don't like physical access tokens. House keys are kind of a necessary evil (and I'm paranoid of losing them). But that's as far as I'm willing to go. Everything else can just live in my head. Including the strong passphrases to various SSH keys, GPG keys and whatnot.
For anything I don't want to remember, I use pass.
I've, fortunately, never lost my keys -- including my Yubikeys -- but I keep spares just in case I ever do.
When Yubico shipped me two new replacement Yubikeys (recent RNG issue), I just tossed them in the safe. I've also got a USB flash drive in there (in a tamper-evident bag) with a LUKS-encrypted filesystem that contains a backup of my GPG keys. I've got another such USB flash drive safely stored at another location too.
I use the YubiKey for SSH auth on several servers but didn't go the GPG route. I opted for the challenge SSH mode using PAM.
Using username "gunni".
Using keyboard-interactive authentication.
YubiKey for `gunni':
Using keyboard-interactive authentication.
Password:
Last login: Tue Jan 14 14:07:02 2018 from X
[gunni@box ~]#
Works like a charm but I might look into the PGP variation if one of you can hard sell it to me.
Yubikey is a step in the right direction, but afaik it is still vulnerable at the pin entry level unlike a dedicated smartcard wtih pinpad reader. Likewise, gpg-agent, if I understand/remember it correctly, is also subject to attacks that would not be possible with the dedicated reader+card combo.
There is a module to make it work with touchbar MBPs fingerprint readers. Not sure if this is custom to our work or something that ubikey provides. It’s pretty seamless and much safer than using just a ubikey.
The "authenticate" bit isn't really material here. GPG keys are, at their heart, just asymmetric private keys (most typically RSA these days, but there are plenty of other options). The authenticate/sign/certify bits are flags that client tools use to know which key to pick, they aren't enforced anywhere.
The reason your auth key is used for auth and signing key is used for signing is just because most GPG tools are helpful.
It's also worth noting that an ssh agent using agent forwarding exposes use of all the keys it knows about, not just the one used for the initial connection. So if you SSH to 1.2.3.4 with "-A", that host has the ability to poke your agent and ask for any keys it's got loaded up.
The "presumably they are smart" bit is also rather concerning. Being smart is generally not protection against mistakes. This isn't to say that gpg-agent allows malicious action, but we should start from a presumption that bugs exist, rather than just assume they don't.
> So if you SSH to 1.2.3.4 with "-A", that host has the ability to poke your agent and ask for any keys it's got loaded up.
I'm sure you know this but just to be clear... if you're using "-A", that host has the ability to ask for operations to be performed using any keys it's got loaded up.
It can't just say, "Lemme have all those private keys you got!". That's the primary purpose of storing them in a separate device -- the actual keys themselves become inaccessible and aren't exposed. Again, the device keeps the keys internally and performs operations using them on your behalf.
Besides, in my case, even with an "offline master" key and three subkeys, the agent still only knows about the authentication key. The others don't get loaded into the SSH agent. I don't even use agent forwarding in the first place, but that's beside the point.
for this kind of gadgets to truly win the favor of security-minded folk, first it has to be durable, which most of the product (include this one) failed to show.
Yubikey is very useful as a 2FA authenticator. I wouldn't use it for SSH and GPG. I wish there were more websites that supported U2F out of the box, or supported using Yubikey as an authenticator without first adding a mobile phone number, which I don't share on a principle.
The blue Yubikeys sold as U2F keys can't be used for SSH the way this article suggests; it's talking about the Y4 keys, which are essentially tiny USB HSMs. Y4 SSH isn't a 2FA mechanism; it's a way to keep your SSH key on a piece of hardware where it can't be extracted.
I have a Yubikey on my keychain, and never use it. I'm still looking for that application that will make me want to use it daily. I was thinking about using it to unlock my Mac, hoping this would add to its security after Meltdown and Spectre. Maybe add a second admin account which would require Yubikey. Then if that fails, I have another admin account without Yubikey as fallback login.
My main problem is how to handle the loss of the key. Now I have one, but how do I handle the loss of one or more keys and can I lose access to my encrypted laptop? Same goes for Lastpass or other password managers where 2FA might be used. On the other hand, if I have an accident with head trauma and forget my passwords, what then?
> Now I have one, but how do I handle the loss of one or more keys
The same way you handle loss of keys to your home, car, etc. - you buy a second pair. If you're using OpenPGP you can provision them with keys any time so it's not a problem but if you're using U2F then you better add at least two to all your services (Yubico has a cheap U2F only key).
Yep. I got multiple U2F keys. One is on my keychain, another is in a drawer in my desk, and a third is in a safety deposit box at the bank with my other important documents.
For backup in case I loose my key I have multiple yubikeys, and whenever I setup 2FA on a site I take screenshot of the QR code and store it in an encrypted tarball in my password-store.
To duplicate my yubikey you'll need one of my yubikeys; and the password for the tarball (which is thus encrypted twice).
I use my yubikey with Password Store as well and absolutely love it. One of my favorite features is the ability to use my passwords in personal scripts / programs without having the save the password in the code. Instead I have the program call out to the password store binary to retrieve the password.
>My main problem is how to handle the loss of the key.
if using for 2fa, most offer a way to turn 2fa off temporarily in case of a key-loss.
I suggest buying more than one, associating them both with whatever task, and throwing one in a safe. It's less-than-ideal, but better than losing access completely when your keys are stolen or destroyed.
I don't give two craps about do the companies have my phone number or not, so I understand their argument.
Phone numbers are something all people have, so using it as a backup if you lose your Yubikey makes sense.
With that said, I do understand that someone using a Yubikey has probably already thought about "what happens if I lose it" and advanced threats against SMS, but if we want them to be used by everyone, this seems like a nice compromise.
The threats against SMS are not advanced. ESN porting attacks are still -easy- in the US and I have personally had to be a first responder due to an administrator at an employer being hit by it. Suddenly you lose your 2FA backup to everything and an attacker resets all your passwords and takes over all your accounts.
Any aging windows XP machine at a corner cell phone store has permission to port your number.
Even if that gets fixed, in the USA all cell service providers are required to retransmit a message with A5/1 encryption if asked which can be intercepted and decrypted with wireshark, a $20 USB TV tuner, and 2TB of disk space for rainbow tables.
Seriously SMS is downright dangerous as a 2FA method and it is idiotic that vendors support it as a password reset method.
You are better off using nothing at all over SMS to avoid a remote account takeover... or use something that -can't- be remotely stolen like a hardware TOTP/U2F device.
http://www.engineerbetter.com/blog/yubikey-all-the-things/
http://www.engineerbetter.com/blog/yubikey-ssh/
http://www.engineerbetter.com/blog/yubikey-static-secret/
http://www.engineerbetter.com/blog/yubikey-2fa/
I wish AWS supported U2F, it'd make my day a lot less frustrating.
We do a lot of pairing and rotating on shared machines, so it's really danged useful.