Using FIDO keys(777.tf) |
Using FIDO keys(777.tf) |
* Why should I use a security key?
* What is it used for?
* How can I choose one ?
* What features should I look for?
We did cover FIDO2/Passkeys but also multiple other use cases.
Here are the slides if you're interested: https://tome.one/slides/amiet-pelissier-security-keys-worksh...
Aren’t all of them just public key authentication (with the private key in a mini-HSM, and public key either calculated in real-time, or stored, in the HSM, and synced externally)?
FIDO2 is a standard set up by a couple of authentication companies and stakeholders. U2F was basically an earlier attempt at that. FIDO UAF is a protocol for authenticating, CTAP is a protocol for communicating with hardware. 2FA is just a generic term for "multiple factors", like combining a PIN with your fingerprint. WebAuthn is the web API for authenticating with security keys.
Most of them do indeed come down to public key cryptography. The challenge is providing a public key API that works across hardware vendors, supports attestation, and allows for things like "use your phone to verify your login if your computer's TPM isn't sufficient". They all solve a different problem in the chain, and the names have changed a bit over the decades.
If you're building software now, use the word "passkeys". Apple and Google have stuck with those names, and they're named a lot friendlier than "WebAuthn".
CTAP is a protocol for say a PC, or a Phone to talk to an authenticator, maybe over USB or maybe Bluetooth.
WebAuthn is a W3C standard for how a web site can negotiate (via Javascript) exactly what we're going to authenticate and then perform the authentication.
Imagine you connect an external CD drive to your laptop. The CD can turn Red Book CD audio into PCM data, maybe the drive plugs in with a USB-C cable, and the drive uses a SCSI-based Mass Storage variant USB protocol to talk to the laptop, which has an XHCI USB controller, so your operating system needn't know the fine details of this precise PCI USB controller chip. Again, distinct technologies with their own names.
The goals of this whole thing have shifted, and it's hard to keep track of what was aiming at what goal. It started out as "actually secure 2FA" and now we're at "cloud-synced unphishable password replacements for non-technical users".
If it's the hardware token, then the "certificate" (which can either contain your username or not aka discoverable vs non-discoverable credentials) that private key required for authentication will be stored and cannot be extracted in the secure element (until an exploit is found).
Syncing the private key is like “symmetric authentication”, where the hashed password is sent to the website. That’s the old way of authentication.
I've since replaced them with yubikeys. Yubikeys have a better feature set (at least compared to by v1's) and at this point are fairly mature/stable. V2 is still pitched as alpha quality, and probably will be deprecated with a v3. As much as I want Solokeys to succeed, I just can't recommend them either.
apt-get install solo-python
What a wet dream for the internet controlling fascists when the adoption of "just wield your smart phone" auth would be in place and mandated every where.
Nothing compares to the secrecy of passwords.
Imagine being required to have and use your govID for simply everything, because there is no alternative.
This is not a risk of secure authentification, which passwords can also provide.
$Corps loved to harvest phone numbers as a second factor despite a second fall back email address would be at least as secure as SS7 communication. But phone numbers are tied more strongly to your identity so more valuable for the data brokers.
This is the same thing actually. Tieing identity to something you have and not something you alone know. Something external.
Having a single external dependency for all your identities sounds like a good idea to you? For facists and data brokers it certainly does.
To me, this is an attack on anonymity and i know that i sound paranoid. Lets wait for the enshitening.
FIDO is a standard algorithm and doesn't need a phone.
https://aws.amazon.com/about-aws/whats-new/2022/11/aws-ident...
Banks though, yeah they aren't good at this stuff. My safe† bank decided one day to completely up-end how logins work and almost locked me out. My good bank provide a very stupid, proprietary solution but at least it's an actual secure solution.
† Safe in that they're owned by the government, so, if they go bankrupt I have worse problems because now I live in a failed state. Big piles money of money sit in this bank because it's safe, but it's run by clowns who don't understand customer service.
Wish there were a way around this :/
- Google forces you to also keep their stupid "verify on another device", where you can't even untrust specific devices without fully logging out - proton apps don't support fido auth - microsoft account only allows it on edge and afaik not at all on linux - and so on..
I think the only service where I can fully disable other 2FA channels is github.
Edit: a word
Passkeys are a confusing mess for most users, and the limited storage on Yubikeys doesn't help. However, 1Password's passkey support manages to reasonably successfully hide the confusions that always exist when explaining passkeys to anyone.
For now, I'm happy with my Yubikeys+1Password for all the platforms I use.
Keys with lots of feature have a larger code base and this means more bugs in the long term.
I use my FIDO2 keys for proxmox, ssh ed25519-sk, vaultwarden, nextcloud, GAFAM accounts.
Unfortunately I know of no bank that has adopted FIDO2/webauthn.
Note: Paypal only allows one FIDO2 key AFAIK, so not an option there.
I wish there was stronger laws forcing banks to adopt stuff like that.
Sorry your SoloKey V2 experience isn't going so well. I have a V1 and it's been surprisingly robust over the past 3 years. For NFC, I can only get it working with my Pixel 7 phone of I remove the thick OtterBox case. Perhaps your issue is also related to your case thickness? Having to remove the case is a hassle, so I am sticking with multipurpose USB-A to USB-C adapters for now.
I've been using YubiKeys for like 10 years, but the 5C model I recently got suddenly stopped working out of nowhere. It only lasted me from October to November of this year. I've been wondering if the brand has had a quality drop-off.
Of the security keys in my possession, the Thetis U2F key has lasted the longest (~5 years) and has had no problems whatsoever. They've since released updated FIDO keys, and so I purchased 2.
Good luck on your hardware MFA journey!
Also I didn't knew about Thetis, I'm gonna look into those.
Anyone has one of those?
I think resident keys just complicate things for users and developers.
I currently have four Yubikeys: one on my keychain, one in my apartment, one to take with me while traveling, and one at my parents' house. I figure this should be adequate to ensure I never get locked out of Bitwarden or Google, which would be an utter disaster.
The OTP in the password manager one is another thing I’ve struggled to wrap my head around. There’s an interesting conversation about it with folks at 1Password for those interested: https://1password.community/discussion/101714/why-is-it-a-go...
Intuitively it seems like it should be possible for me to store on my main auth device some form of the backup device’s identity or public key material, and at enrollment time, ask the authenticating service to trust either the current device or also this other device to authenticate me.
I wonder what risks I’m overlooking-surely there must be good reasons the protocol excludes that kind of approach.
Periodically, I try to think if there is some other expected UX you might want that is somehow neither cloned nor independent keys. Like some hybrid of secret-sharing and group key schemes. Have a set of N keys which know about each other and can act individually to authenticate for the same identities, including for new identities enrolled by any key in the group, as in the case of a cloned key. But, include some capability for k out of N keys to "vote out" a member from the group in order to revoke the lost key and prevent it from authenticating any of the identities in the future.
I am not a cryptologist, but I can't really imagine any crypto mechanism to actually produce this combination of effects. A fully distributed group registration and authentication effect during normal use, so enrollment via one key can be followed by authentication using another. But at the same time, allowing ejection a member from the group to prevent future misuse. I can only imagine this as a protocol, where every authentication for the group would have to consult some centralized ledger or revocation list for the group membership. It could be decentralized/federated in a sense, but would require some kind of online check with the "latest" ledger state for a given key group.
Maybe there can be better UX around signing up, ie "give me your public keys so I can set them up in your account", but then you lose a lot of the privacy, because the public keys aren't different per site any more (and operators can then tell the same person has an account on multiple sites).
An alternative some people use is to register a TOTP code and print out the QR code. Then you can remove it from the app. It's not a full solution but it might be part of one that works for you.
> Wish there were a way around this :/
Sign in with Google/Facebook/Github. I wish sites supported custom OIDC but that's probably impractical.
There's also a nifty app that implements CTAP2 on Android Wear, and basically act like an NFC/Bluetooth security key. If you have an Android Wear and don't think your watch will be hacked and rooted, this could be a useful alternative, especially in places where Google doesn't sell their Titan keys.
The website being breached and the passkey public key being dumped is meaningless. They are more likely to compromise a site’s admin access that can get into user accounts than ever crack public key cryptography or simultaneously acquire all three factors necessary to gain access to my vault. And no matter what I do on my end (except only use sites that take security seriously) can stop that.
At this point, you’re just making shit up about something you don’t understand.
You're ignoring the fact that WebAuthn can require attestation, which will remove device choice from the equation.
> Nothing compares to the secrecy of password.
Because they are soley internal to you.
Yes, you can generate passkeys at will ... and then you give them away to a usb dongle or HSM, from which some day you might not be able to export them, because vendors love their locked in customers.
I am talking about control and yes, my concerns are speculation but reasonable to me, when you look at pretty much all the recent development. From not-WEI over DRM, to right to repair and on and on.
If I use a Security Key to sign into Facebook as "Melissa Smith" and use the same Security Key to sign into my GitHub account "acab420", even if Facebook and Microsoft work very hard they can't correlate the information they have to prove those are being authenticated with the same authenticator. The keys are different, as they would be if these were different authenticators.
You might think it's impossible for FIDO1 or in scenarios where it's "just" a second factor and isn't storing anything for the site on your key, but there's a really clever trick. The Relying Party (e.g. web site) is required to remember a large random-looking "ID" for your key. Those aren't really random - they're effectively your private key for that site, but encrypted using a symmetric key only your authenticator knows. It encrypted its own private key and just sent that, in plain text, knowing it's impossible to decrypt (typically AES-128 or similar) and when the ID is sent back, the authenticator just decrypts it. AEAD is used, so an authenticator can tell if this ID isn't one it made because the AEAD fails.
That being possible means the private key material has to be backed up, as opposed to being permanently locked into an HSM like Yubikey.
Think of ssh keys. Only your public key has to be transferred to the server for you to login.
Take laptop B. Log in to your FAANG of choice, syncing passkeys locally. Use laptop B to log into the same website.
Your FAANG of choice saw much more than a public key, for that to be possible. That might have been encrypted by something like your password to the FAANG, but still, it's the opposite of a tamperproof HSM.