Getting the most out of YubiKeys for your business(blog.congruentlabs.co)
blog.congruentlabs.co
Getting the most out of YubiKeys for your business
https://blog.congruentlabs.co/getting-the-most-out-of-yubikeys-for-your-business/
76 comments
I use my YubiKey to store a full set of subkeys while keeping my primary key offline on paper. No secret keys are ever written to disk. I boot a live Linux system and restore my primary key when I need to generate new subkeys or sign other people's keys.
Same use case here. While setting up the yubikey with the gpgkeys is a long process it's totally worth it in my opinion.
I went through this as well, and it was a really fun task. Then I realized that I do not use GPG nearly as often as I thought I would.
I ordered some CDs online once in the late 90s from CDNow, and they let you email them credit card information in a PGP encrypted message. How times have changed, eh?
I ordered some CDs online once in the late 90s from CDNow, and they let you email them credit card information in a PGP encrypted message. How times have changed, eh?
Eh we enforce GPG signing of all commits at my shop and I use the gpg/SSH key magic so end up leaning over to touch my yubikey a lot! Large rebases are particularly gun, lots of touching there.
What kind of baackup do you have in case the yubikey is borked/lost/stolen?
Another YubiKey that's been prepped in advance and kept in a safe place.
One nit about this article. It claims that the Yubikey does not support TOTP (Time-based One Time Code). I believe all of the Gen 5 versions that plug into your computer's USB port support TOTP.
There is an app called Yubico Authenticator that can scan for a QR code on your screen and import the secret key from a website, into the Yubikey, when setting up TOTP as supported by Google Authenticator. You can also require a touch in order to generate the One Time Code, which I would recommend.
There is an app called Yubico Authenticator that can scan for a QR code on your screen and import the secret key from a website, into the Yubikey, when setting up TOTP as supported by Google Authenticator. You can also require a touch in order to generate the One Time Code, which I would recommend.
Oh yeah good point, I always forget about the OATH part of the YubiKeys - unfortunately it's like the OTP feature in that I haven't had enterprise customers asking me about it at all (they're all hyped about U2F), so I start to forget its there.
I'll have to add it in to the article :)
I'll have to add it in to the article :)
I feel like I'm really missing something on why Yubikeys are such a popular form of 2FA. My previous employer utilized a phone app that would spawn a notification when you were trying to do something requiring a 2nd authentication factor. You had to either enter a 6 digit pin or use a fingerprint to authorize. My current employer utilizes Yubikey, and it just feels clunkier and less secure? I still have to have a piece of hardware, but its one I'm vastly more likely to lose or misplace and doesn't require any verification that whoever is activating it is who they say they are. Is there something I'm missing?
You leave the Yubikey in your computer, at least for the duration of your session, so you're just moving your hand a couple of inches to tap it. Contrast with fishing out an entirely different device, waiting for the push to arrive or navigating to the Duo app, etc. Push 2FA is also subject to the vagaries of your phone's current network connection and its latency.
For the specific combination of Macs with Touchbar and U2F and Chrome, you can already get this experience with onboard hardware. I expect most client devices will converge on having some kind of hardware-backed U2F credential built in. But Yubikey is more general right now. OTP is easy to implement and eminently compatible; it just presents as a keyboard and sends keystrokes. HMAC is great for not just authenticating but signing specific transactions. The GPG applet is just another GPG key, and the PIV applet is just another X.509 cert, so a number of applications can be upgraded to hardware-backed credentials with little or no change.
For the specific combination of Macs with Touchbar and U2F and Chrome, you can already get this experience with onboard hardware. I expect most client devices will converge on having some kind of hardware-backed U2F credential built in. But Yubikey is more general right now. OTP is easy to implement and eminently compatible; it just presents as a keyboard and sends keystrokes. HMAC is great for not just authenticating but signing specific transactions. The GPG applet is just another GPG key, and the PIV applet is just another X.509 cert, so a number of applications can be upgraded to hardware-backed credentials with little or no change.
It depends on the context really - I love the push-driven MFA products, but they specifically require you as a user to be carrying a phone with you at all times, and are usually considered "low" assurance of the user's identity.
If your business is seeking "higher" assurance (yes, assurance levels are very subjective) then certificate-based MFA can meet the needs better. Or, if your business is working with sensitive data/systems, phones may be banned from the office (e.g. military, intelligence, banks, etc.).
If your business is seeking "higher" assurance (yes, assurance levels are very subjective) then certificate-based MFA can meet the needs better. Or, if your business is working with sensitive data/systems, phones may be banned from the office (e.g. military, intelligence, banks, etc.).
If you can’t use a phone as a factor, it’s likely you’ll be issued a smart card (such as a CAC in the case of the military).
It feels like Yubikeys are a shim until the phone UX as a factor improves (and there’s more server side support) and/or smart card adoption for identity improves. If Touch ID and Face ID are good enough for most secure transactions in the Apple ecosystem (including Apple Pay), seems like a reasonably high assurance.
It feels like Yubikeys are a shim until the phone UX as a factor improves (and there’s more server side support) and/or smart card adoption for identity improves. If Touch ID and Face ID are good enough for most secure transactions in the Apple ecosystem (including Apple Pay), seems like a reasonably high assurance.
Some of the U2F-only tokens are their own thing, but the flagship Yubikey is literally a smart card bundled with a reader. The USB token form factor makes a little more sense for an individually assigned laptop.
I have found Yubikey evangelism terribly difficult in both my enterprise and defense industry engagements, hence my smart card statements. For whatever reason, Yubico still has some perception challenges.
[deleted]
You can MITM OTP, but you can't MITM U2F. You can copy/steal the OTP secret from a phone app, but you can't copy/steal the U2F private key from a Yubikey (easily).
With Push MFA it's even easier, the sequence goes like this:
Crooks know Barry's password but Push MFA is needed to sign into his account and conduct some crime
Crooks somehow get Barry to go to a site they control believing it is for Work [there are a lot of ways to do this step, links in email, hijacking forgotten subdomains, typo squatting, the list goes on]
The site says "Hi Barry, we need to do Push MFA"
Crooks sign into Barry's real account with the password, causing a Push MFA to happen.
Barry was expecting Push MFA because the bogus site prompted saying it would happen so OKs it.
Crooks have now successfully passed the MFA
Crooks know Barry's password but Push MFA is needed to sign into his account and conduct some crime
Crooks somehow get Barry to go to a site they control believing it is for Work [there are a lot of ways to do this step, links in email, hijacking forgotten subdomains, typo squatting, the list goes on]
The site says "Hi Barry, we need to do Push MFA"
Crooks sign into Barry's real account with the password, causing a Push MFA to happen.
Barry was expecting Push MFA because the bogus site prompted saying it would happen so OKs it.
Crooks have now successfully passed the MFA
I think the intuition is that it is supposed to be like a key. People generally do a pretty good job securing their keys. In addition, it is easy to have a backup key stored somewhere safe.
One nice thing about Yubikey instead of phone, is that since it only does one thing, you are far less likely to need to upgrade it. In the past, I have lost a 2 factor on my phone when upgrading since it is not backed up.
One nice thing about Yubikey instead of phone, is that since it only does one thing, you are far less likely to need to upgrade it. In the past, I have lost a 2 factor on my phone when upgrading since it is not backed up.
It’s like a physical key, also inside a combination lockbox, hanging from your keychain. It follows the Unix Philosophy in this regard of doing one thing very well and I think that’s a large part of the appeal.
Granted it does many things well, I think the most common case with Yubikeys is we only use them for one or two of their possible functions, and they’re cheap enough that this is okay; like a screw driver with half a dozen bits in the handle, but I just use the Philihp’s Head bit. In earlier Yubikeys, they could get stuck in PIV mode (like getting a bit stuck in your screwdriver), but I doubt anyone ever noticed.
Granted it does many things well, I think the most common case with Yubikeys is we only use them for one or two of their possible functions, and they’re cheap enough that this is okay; like a screw driver with half a dozen bits in the handle, but I just use the Philihp’s Head bit. In earlier Yubikeys, they could get stuck in PIV mode (like getting a bit stuck in your screwdriver), but I doubt anyone ever noticed.
That makes sense, and initially that is how I treated it, but essentially everyone I work with keeps theirs plugged in to their laptops 24/7. In fact, the keys we get as backups/replacements are the low profile ones designed to be plugged in and not removed without significant difficulty.
The effect this has is to make the laptop a "Something you have" factor. This works fine so long as the business is strict about ensuring people treat laptops appropriately and report losses quickly.
e.g. my last big corporate employer would sometimes randomly take any laptops that had not been properly physically secured during a meeting or over lunch. You'd come back and somebody groans "Oh no, we were only gone a few minutes". Yes we were, and you didn't bother locking your laptop so now you're going to have to grovel to somebody to get it back.
e.g. my last big corporate employer would sometimes randomly take any laptops that had not been properly physically secured during a meeting or over lunch. You'd come back and somebody groans "Oh no, we were only gone a few minutes". Yes we were, and you didn't bother locking your laptop so now you're going to have to grovel to somebody to get it back.
That’s why I love my 17 inch Alienware gaming laptop. If it is missing, I can usually spot the thief straining under the load of trying to carry it, and it is too bulky to fit in a normal backpack.
The only way to lock laptops to things I have seen have been Kensington slots, and those are literally security theater. You can cut them straight through their cables with a simple plier and zero effort, in one motion.
I don't like taking my phone out while I work, since this is often a source of distractions. I also have to worry about keeping it charged and on me (it is much larger than the yubikey). I have to keep the authentication app, which is often proprietary, installed and up to date. I have to worry about retaining access if I lose, break, or want to upgrade my phone. I have to apply a different security model to my phone. I have to trust a third party (duo), and rely on their push notification infrastructure. There is an additional delay while I wait for the push notification.
There is something I intrinsically like about pressing a hardware button.
These are all relatively minor things, but they add up to a strong preference for the yubikey (I've used the simple blue u2f key with a button).
After reflecting on this list, I think the security model is probably the biggest one. In more colloquial terms: I'm already used to keeping track of my keys with a certain amount of care. A yubikey does not require me to adjust my habits; it's just another key.
There is something I intrinsically like about pressing a hardware button.
These are all relatively minor things, but they add up to a strong preference for the yubikey (I've used the simple blue u2f key with a button).
After reflecting on this list, I think the security model is probably the biggest one. In more colloquial terms: I'm already used to keeping track of my keys with a certain amount of care. A yubikey does not require me to adjust my habits; it's just another key.
TouchID on macs are another reasonable option.
My employer uses Duo, which supports phone push, yubikeys, or webauthn/touchID in chrome.
I almost always use touch ID. I do have a yubikey and phone push as a backup, but I really want to minimize using my personal device for work (and don't want to carry two phones).
A yubikey is much less obnoxious to carry around than an extra phone.
My employer uses Duo, which supports phone push, yubikeys, or webauthn/touchID in chrome.
I almost always use touch ID. I do have a yubikey and phone push as a backup, but I really want to minimize using my personal device for work (and don't want to carry two phones).
A yubikey is much less obnoxious to carry around than an extra phone.
Well that is kind of the the point of multi-factor authentication.
* Something you know (your username/password).
* Something you have. The Yubikey or other hardware token.
If you lose your Yubikey, by itself it should not allow access to anything. I keep mine on my keyring with my keys, which I haven't lost yet.
* Something you know (your username/password).
* Something you have. The Yubikey or other hardware token.
If you lose your Yubikey, by itself it should not allow access to anything. I keep mine on my keyring with my keys, which I haven't lost yet.
I want to get some sort of retractable lead for mine. My keys are heavy-ish and sometimes it can be difficult to get the key in a usb port without tension.
When I had more keys on my keyring I used something like this https://www.amazon.com/Lucky-Line-Keychain-Nickel-Plated-707... (not this particular one, which is just the top result that looked similar). It worked pretty well for a single key, but if you want to use more than one it adds a lot of extra bulk so your keychain gets even bigger.
I also tried something like this https://www.amazon.com/Spider-Accessory-Split-Rings-Pack/dp/.... It worked pretty well for a few weeks, but then the central piece loosened up and the keys started falling off in my pocket; not recommended unless you can find one that's really sturdy.
I also tried something like this https://www.amazon.com/Spider-Accessory-Split-Rings-Pack/dp/.... It worked pretty well for a few weeks, but then the central piece loosened up and the keys started falling off in my pocket; not recommended unless you can find one that's really sturdy.
in california, if your employer requires you to have a phone for 2FA or other purposes, they must reimburse you at least partially. yubikeys are cheaper.
as to being clunky, it’s because your employer doesn’t care about it, so you have the clunky (and much cheaper) yubikeys.
lack of verification of who is using it is simply not an important part of the threat model.
as to being clunky, it’s because your employer doesn’t care about it, so you have the clunky (and much cheaper) yubikeys.
lack of verification of who is using it is simply not an important part of the threat model.
You should have to enter a pin to unlock the yubikey and if you fail so many times it can be locked forever.
If you are using the PIV applet of the Yubikey, then yes, a PIN is required. Failing the specified number of retries will result in the device being locked. The PIN can be unlocked with a PUK. Failing the specified number of retries with the PUK will brick the PIV applet. You can reset the PIV applet but all previous data will have been wiped.
Does anyone use YubiKeys on OSX for business use? I've tried integrating them on my personal mac before, but the U2F PAM experience was pretty clunky, and caused weird messages from services like Keychain that (I guess) couldn't decrypt without normal credentials being provided at logon.
[deleted]
How were you integrating them on your personal OSX system?
Luckily I wrote down the steps I took. Based on this, but the original seems to be gone now: https://nicluo.com/projects/secure-your-mac-with-yubico-u2f-...
brew install pam-u2f
mkdir -p ~/.config/Yubico/
pamu2fcfg > ~/.config/Yubico/u2f_keys
<Press the U2f device>
cat ~/.config/Yubico/u2f_keys # should output <your username>:<really long hash>
In /etc/pam.d/screensaver
Add to the top:
auth sufficient pam_u2f.so
In /etc/pam.d/authorization
Add to the top:
auth sufficient pam_u2f.soYes, I use one daily and haven't had any issues.
Actually just started some work on some biometric FIDO2 webapp testing, and there are frustratingly few device options available to use for testing, particularly in linux. It works fine on most modern mobile devices, but I need to get into the guts of things, so I need an actual FIDO2 biometric device so it has been a little frustrating. - I don't suppose anyone knows of any device emulators/simulators our there, to test a webapp?
The fingerprint reader on my Thinkpad X1 Carbon (gen 7) can work as a FIDO device. I just re-tested it on https://webauthn.io/ with Firefox in Windows 10. I'm guessing other fingerprint readers will too. You need to know that it will be considered a "Platform" device rather than a "Cross platform" device, which is what YubiKeys are considered.
Related but not answering your question: I haven't found any major website that support Platform FIDO devices. I'm guessing they only want 2FA devices which can roam between computers. I think that's unfortunate. Perhaps a good policy would be to allow Platform devices to be used after a Cross Platform device has been registered first. But there are few websites that support multiple FIDO keys to begin with.
How nice would it be to log into websites with your builtin fingerprint reader? The client side stuff seems ready to go.
Related but not answering your question: I haven't found any major website that support Platform FIDO devices. I'm guessing they only want 2FA devices which can roam between computers. I think that's unfortunate. Perhaps a good policy would be to allow Platform devices to be used after a Cross Platform device has been registered first. But there are few websites that support multiple FIDO keys to begin with.
How nice would it be to log into websites with your builtin fingerprint reader? The client side stuff seems ready to go.
Something rarely mentioned with SSH, but which there have been a few recent articles on HN about, are SSH certificates and the fact that you can use the PIV of a yubikey to do certificate management.
e.g. You can create a certificate which you load the public key of in to your servers (using initial access or baked in to some image) which the private key is loaded in the PIV of the YubiKey. Someone can then generate an SSH keypair and provide you their public key and you can generate an SSH Cert which allows them access to that server for the time and specific users you specify in the certificate. It requires using OpenSSH instead of something like libSSH2 (which most iOS clients are using instead unfortunately).
This is all the same thing actually as running your own TLS CA by the way so you can also use a yubikey to securely store a sub-CA used to create certificates for internal use.
e.g. You can create a certificate which you load the public key of in to your servers (using initial access or baked in to some image) which the private key is loaded in the PIV of the YubiKey. Someone can then generate an SSH keypair and provide you their public key and you can generate an SSH Cert which allows them access to that server for the time and specific users you specify in the certificate. It requires using OpenSSH instead of something like libSSH2 (which most iOS clients are using instead unfortunately).
This is all the same thing actually as running your own TLS CA by the way so you can also use a yubikey to securely store a sub-CA used to create certificates for internal use.
It’s worth noting that for “SSH certificates”, the leaf certs are not x509-based, and that you can’t put a CA-signed SSH user key onto a yubikey.
When yubikeys are used for SSH auth (either in GPG or PIV mode), they’re using the raw private key (either via GPG-agent or opensc, generally). The SSH client/server doesn’t get context about the identity, its trust relationships, etc.
This limits usage to trusting individual keys, rather than being able to trust “all keys signed by the CA”.
When yubikeys are used for SSH auth (either in GPG or PIV mode), they’re using the raw private key (either via GPG-agent or opensc, generally). The SSH client/server doesn’t get context about the identity, its trust relationships, etc.
This limits usage to trusting individual keys, rather than being able to trust “all keys signed by the CA”.
This seems to indicate you can:
https://developers.yubico.com/PIV/Guides/SSH_with_PIV_and_PK...
('If an external key has been imported and a certificate already exists, skip step 2' - you can import a certificate signed by a CA, and OpenSSH allows you trust certs signed by a given CA.)
Am I missing something here where that doesn't work in this combo? Or are you referencing 'ssh keys' specifically, as opposed to 'certificates being used for ssh'?
('If an external key has been imported and a certificate already exists, skip step 2' - you can import a certificate signed by a CA, and OpenSSH allows you trust certs signed by a given CA.)
Am I missing something here where that doesn't work in this combo? Or are you referencing 'ssh keys' specifically, as opposed to 'certificates being used for ssh'?
That doc doesn’t use a CA at all.
Step 1 has you import an existing RSA private key or generate one on the device.
In step 2, you self-sign the certificate. As noted in the doc, “The only use for the x509 certificate is to satisfy the PIV/PKCS #11 lib”. You can skip this, per the note in step 1, if your key is already signed.
In future steps, when you’re SSHing with the pkcs11 library, it’s using the public/private components of that RSA key. The certificate (any certificate) has to exist because PKCS11 needs that to cleanly view the public key, but the actual cert metadata, including issuer, is fully unused. Importing a cert signed by a CA has no impact on the result.
On the OpenSSH side, their “CA” support does not create signed leaf x509 certificates. You trust a cert public key, and it signs an OpenSSH-specific representation of user/host public key. OpenSSH then has a special public key type for authenticating using that signed key. As such, PIV/PKCS11 keys, as far as I’m aware, cannot be used as part of OpenSSH’s “CA” support.
Step 1 has you import an existing RSA private key or generate one on the device.
In step 2, you self-sign the certificate. As noted in the doc, “The only use for the x509 certificate is to satisfy the PIV/PKCS #11 lib”. You can skip this, per the note in step 1, if your key is already signed.
In future steps, when you’re SSHing with the pkcs11 library, it’s using the public/private components of that RSA key. The certificate (any certificate) has to exist because PKCS11 needs that to cleanly view the public key, but the actual cert metadata, including issuer, is fully unused. Importing a cert signed by a CA has no impact on the result.
On the OpenSSH side, their “CA” support does not create signed leaf x509 certificates. You trust a cert public key, and it signs an OpenSSH-specific representation of user/host public key. OpenSSH then has a special public key type for authenticating using that signed key. As such, PIV/PKCS11 keys, as far as I’m aware, cannot be used as part of OpenSSH’s “CA” support.
What token hardware does support x509 certs (and thus compatible with an SSH CA?)
The Yubikey supports x509 certs (this is the PIV app). And you can use them for SSH authentication via opensc or similar. But this just uses the RSA private key, not the cert.
SSH’s built-in CA support uses a certificate authority private key to sign regular SSH public keys. The resulting public key cert isn’t compatible, as far as I know, with any hardware keys.
SSH’s built-in CA support uses a certificate authority private key to sign regular SSH public keys. The resulting public key cert isn’t compatible, as far as I know, with any hardware keys.
Anyone know how to use a Yubikey for FIDO or WebAuthN from INSIDE an RDP session?
I've personally never seen it work that way - usually because RDP doesn't pass through direct USB devices, only their abstracted forms (e.g. smartcards don't get passed through, only the "Smart Card" device registered in the OS, and only if you enable that to be passed through in an mstsc session.
There are products like Silverfort (https://www.silverfort.com/) that can handle agentless auth, and might be able to do that kind of MFA inside an RDP session. But, products like this usually require some 3rd device (i.e. your phone) to perform the MFA action, which is kind of not really just a simple WebAuthn logon...
There are products like Silverfort (https://www.silverfort.com/) that can handle agentless auth, and might be able to do that kind of MFA inside an RDP session. But, products like this usually require some 3rd device (i.e. your phone) to perform the MFA action, which is kind of not really just a simple WebAuthn logon...
It's kind of a pain, but possible. You have to redirect it as a generic USB device. I wrote a guide here:
https://queensidecastle.com/guides/use-a-yubikey-remotely-ov...
https://queensidecastle.com/guides/use-a-yubikey-remotely-ov...
Why is there so little competition for these? $50 for a key that maybe costs $5 to manufacture (yes, including software development, at their volume) is a little too rich for my blood.
There are a few competitors: Google Titan, Thetis come to mind plus traditional smartcards. Some of the competitors only support FIDO/U2F, meaning that a number of applications like LastPass that support OTP or Smartcard won't work (if you're interested Yubikey's Security Key only supports those two protocols and only costs $20). Yubikey's build quality tends to be superior and they've got a nice plug and play UX. For many IT departments, it's easy to justify an extra $5-$10 a unit if there is minimal support needed and it's unlikely to need to be replaced due to breakage (lost devices yes, breakage no). Anecdotally I've got an older generation yubikey that appears to still work after 6-7 years
Yeah Nitrokeys are probably the closest device, but cost even more https://www.nitrokey.com/
And usually it's twice what they charge, because you need a backup device to handle losing the first one.
I'd like to see a competitor come out with a combo PIV card & FIDO device. At least from the enterprise perspective it would cover 99.9% of MFA situations. And the majority of my personal uses of YubiKeys.
And usually it's twice what they charge, because you need a backup device to handle losing the first one.
I'd like to see a competitor come out with a combo PIV card & FIDO device. At least from the enterprise perspective it would cover 99.9% of MFA situations. And the majority of my personal uses of YubiKeys.
Assurance that you’re getting the right $5 device is tricky—when the factory has so many incentives to do otherwise.
Yubikey is the competition, before they turned up the equivalent devices were vastly more expensive and less functional.
It is a fairly niche (although growing) market, and you also don't want to buy the cheapest product in the space as it might not work securely.
It is a fairly niche (although growing) market, and you also don't want to buy the cheapest product in the space as it might not work securely.
It is probably more pricing of different products in their selection. If you just need U2F you can get their security keys [0] for 20$. 18$ if you order 50, and probably even cheaper if you ask for > 1000 (i.e. an entreprise customer).
And 5$ manufacturing for 20$ resale is pretty much a standard ratio in consumer goods. I would also argue that a competitor would have a hard time making those at only 5$, making it harder to compete based on price alone.
[0] https://www.yubico.com/product/security-key-by-yubico
And 5$ manufacturing for 20$ resale is pretty much a standard ratio in consumer goods. I would also argue that a competitor would have a hard time making those at only 5$, making it harder to compete based on price alone.
[0] https://www.yubico.com/product/security-key-by-yubico
Adding to the list of alternatives: https://solokeys.com/ Open source hardware
I suspect YubiKey doesn't face price competition from the cheap AliExpress USB flash drive manufacturers because a U2F token from a no-name supplier isn't much better than a mobile app.
[deleted]
I feel like a broken record, but:
If I have a startup of 5 people, how do I deploy 3 Yubikeys per person? How do I issue a new Yubikey to a person and connect it into systems if one of the old ones gets stolen? How do I disable a stolen Yubikey or all the Yubikeys if that person quits?
And how do I do this when the IT department is one person a couple hours a week?
If I have a startup of 5 people, how do I deploy 3 Yubikeys per person? How do I issue a new Yubikey to a person and connect it into systems if one of the old ones gets stolen? How do I disable a stolen Yubikey or all the Yubikeys if that person quits?
And how do I do this when the IT department is one person a couple hours a week?
Hi! I'm actually the product manager for the product mentioned in that article: https://enterprise.signata.net.
Are you heavily SaaS based for the tools you use in your startup, or do you have some on-prem infrastructure? That'll kind of dictate which path you should go down for provisioning the keys to your users. Our product will be perfect if you're using AD & a Microsoft CA internally (or are willing to set one up), as you could then just set up 3 YubiKeys for each employee, all loaded with certificates for authentication.
And, should one be stolen or an employee leaves, just revoke the certificates on it to kill the access immediately.
Any path you go down should really still only take a bit of time upfront and almost nothing longer term, unless your team grows fast.
You can also hit me up at [email protected] and I can give you more advice if you don't want to mention specifics publicly.
Are you heavily SaaS based for the tools you use in your startup, or do you have some on-prem infrastructure? That'll kind of dictate which path you should go down for provisioning the keys to your users. Our product will be perfect if you're using AD & a Microsoft CA internally (or are willing to set one up), as you could then just set up 3 YubiKeys for each employee, all loaded with certificates for authentication.
And, should one be stolen or an employee leaves, just revoke the certificates on it to kill the access immediately.
Any path you go down should really still only take a bit of time upfront and almost nothing longer term, unless your team grows fast.
You can also hit me up at [email protected] and I can give you more advice if you don't want to mention specifics publicly.
did you not read the question? it’s 5 ppl and either outside IT or random joe employee 1-2 hrs per week. they are not managing AD and CA infrastructure.
[deleted]
Yeah that's why I added the "if" - But I have seen a lot of very small teams running AD (or Azure AD if they've chosen the Microsoft path), but they tend to just be paranoid about security or running in countries with poor internet connections.
Microsoft also provide pretty cheap deals for startups if they want some basic infrastructure for the office (excluding the hardware of course), so it's not entirely out of the equation on the licencing side either.
Really small teams typically will find U2F auth easiest to work with in the beginning, and then after hitting like 20 users they'll bump into problems like a large enough number of connected systems that they need to manage 2FA for.
Microsoft also provide pretty cheap deals for startups if they want some basic infrastructure for the office (excluding the hardware of course), so it's not entirely out of the equation on the licencing side either.
Really small teams typically will find U2F auth easiest to work with in the beginning, and then after hitting like 20 users they'll bump into problems like a large enough number of connected systems that they need to manage 2FA for.
Honestly I found PIV to be way more complicated the PGP. We use the GPG agent for SSH. It's a simple thing and works beautifully!
The PGP standard needs to have a WebAuthN or U2F thingy portion added to it.
The PGP standard needs to have a WebAuthN or U2F thingy portion added to it.
i don't like how the yubikey has it's own timeout for passphrases. for example, when i first insert my yubikey, i'm prompted to enter a passphrase to unlock it. it then becomes unlocked until it's removed. this is behavior is not always desired. I'd like the ability to always prompt for a passphrase each time the key is accessed.
I have my laptop set up to permit sudo without a password if the yubikey 5 is inserted. Is there a way to require a touch as well?
Virtually every u2f implementation I've ever seen allows otp as a backup, reducing the security of one to the other. U2f is so much nicer than otp but hardware keys have devolved to being convenient not more secure than otp.
Just because you're allowed to do OTP backup doesn't require you to switch it on. If you have two FIDO keys that's fine.
What isn't fine is one FIDO key and no other backup. The good ones aren't fragile, but you can still easily lose them.
If there's a site you use on the phone too, newer Android devices which know how to keep a secret (e.g. a Pixel) can do WebAuthn for themselves and be that second option for you.
What isn't fine is one FIDO key and no other backup. The good ones aren't fragile, but you can still easily lose them.
If there's a site you use on the phone too, newer Android devices which know how to keep a secret (e.g. a Pixel) can do WebAuthn for themselves and be that second option for you.
I think the point was that most u2f implementations around don't just allow OTP as backups... they require you to set up OTP first before u2f can be enabled.
It does make a bit of sense. Users can't be trusted not to lose their single token. But rarely is the option to enrol a second u2f key as backup permitted.
It does make a bit of sense. Users can't be trusted not to lose their single token. But rarely is the option to enrol a second u2f key as backup permitted.
The only place I've used WebAuthn/ U2F that did not allow me to enrol multiple keys was AWS. I have two (or more) keys enrolled at Facebook, Google, GitHub, and for my government services.
WebAuthn (which is the one that's actually a documented standard) not only goes out of its way to make multiple tokens practical it explicitly calls out the intent that you should allow users to enrol multiple tokens.
WebAuthn (which is the one that's actually a documented standard) not only goes out of its way to make multiple tokens practical it explicitly calls out the intent that you should allow users to enrol multiple tokens.
Google won't let you enroll with just one key. You need at least two.
Also, if you happen to have a Ledger for crypto crap, those support U2F as well. It's less convenient because you need to connect it to a PC, enter the PIN, and then open the U2F applet.
Also, if you happen to have a Ledger for crypto crap, those support U2F as well. It's less convenient because you need to connect it to a PC, enter the PIN, and then open the U2F applet.
[deleted]
The major advantage of u2f is phishing resistance.
If you always use u2f for auth, you can be sure that you are not fooled by fake login pages. It ain't just matter whether secondary otp is available. (it's just a backup for when you lost a hardware token!)
If you always use u2f for auth, you can be sure that you are not fooled by fake login pages. It ain't just matter whether secondary otp is available. (it's just a backup for when you lost a hardware token!)
I used this guide: https://github.com/drduh/YubiKey-Guide to set up my YubiKeys with GPG keys that are also used as SSH keys. This gives me, in a single setup:
* secure 2FA for sites with WebAuthN * ability to encrypt backups and other information using GPG, with decryption only possible with a physical device * ability to securely log in via SSH to all my infrastructure
I use keys, in case one gets lost. I did try to use the PIV features, but I just don't live in a world where this is useful — but the FIDO2 and GPG functionality is fantastic in itself!