Passkeys are generally available
github.blog
github.blog
1Password has a directory [1] of sites that have Passkey support, so one day I moved over those accounts.
I try always to disable email or SMS 2FA/recovery, because I deem them to be rather unsafe.
Btw Bitwarden announced to support pass keys soon ("in October").
You're opting to a lower security level by wanting something that can be synced.
I don't think most users care
If I can backup my passkeys, then I can disable them.
It's fine if you do that for two or three services. But my password manager has around 600 entries. If I would need to set up all of them on both keys and always switch the active one with the one in the safe location for setting up a new account I would go crazy. Having both of them in the same place kind of defeats the purpose of having two keys, as you would lose them together.
So better have a synced password manager and unlock the password manager with a hardware key.
iOS 17 plus the latest 1Password allows you to use passkeys saved in 1P across apps and websites.
Note that not all sites are handling it quite as well. For example I tried to add one at Home Depot. As part of this they emailed me a verification code. I entered the code, and it then asked if I wanted to enable login by Face ID or Touch ID.
I'm on a Mac which has neither Face ID or Touch ID so said no. It continued and I was logged in.
It turns out that if you say no it doesn't actually make a Passkey. It just does a one time password free login via entering that code that was mailed to you.
To actually make a Passkey for Home Depot you have to say yes to Face ID or Touch ID.
I also got locked out of an account (not Github) that I now can't recover without providing photo ID and god knows what other data, because something about their implementation changed and now my security key is no longer accepted.
Most of the few sites that accept security keys also only let you register one, which means you can't have a backup.
As I understand Passkeys "solve" this by effectively being backed up to your Google or Apple account, so once that's compromised, you've lost.
As long as you're using a password manager (which will not autofill on phishing sites), passwords still seem like the way to go, unfortunately...
Lowercase p, like passwords
> As long as you're using a password manager (which will not autofill on phishing sites), passwords still seem like the way to go, unfortunately...
Many password managers have rolled out passkey support; iOS 17 and Android 14(?) have support for third party passkey providers at the OS level, while some of these managers inject support directly into the browser via a web extension.
Having a security key handle unlocking your platform authenticator/password manager seems to be the middle ground that's being driven towards, and as somebody with multiple YubiKey's I'm perfectly fine with it.
Sure, authentication could also be done without resident keys, but resident keys simplify the authentication workflow a lot, since the relying party doesn't need some additional credentials to send the correct wrapped key.
(Disclaimer: I have several Yubikeys.)
> [The definition "passkey is a resident key"] has become so invasive that even FIDO now use it as their definition.
but the linked FAQ for "their definition" doesn't contain the word "resident" (anymore?).
> What is a passkey?
> Any passwordless FIDO credential is a passkey.
I would recommend [1] as an excellent overview of the FIDO2 and WebAuthn standards that underlie passkeys. depending on how you use your Yubikeys, you may already be using these standards.
if you already have a password manager you're happy with, the appeal of adopting passkeys is somewhat marginal. if you're using your Yubikeys for FIDO2-based MFA you're already getting the majority of the benefit.
This is where I'm at personally right now; basically just waiting for my favorite password manager to add support for passkeys. After that the transition will be pretty seamless; I'll just start storing passkeys in my password manager instead of passwords wherever possible, and get a nice UX improvement as a result.
For users who already have a very good security posture the security benefits of passkeys are pretty marginal. For example, I already use a long, unique password for each site via my password manager. If a site gets breached it will only affect that specific site, and even then only if they store passwords in plaintext. My passwords have enough entropy that even an MD5 hash is unlikely to be cracked in an offline attack. For me the biggest potential benefit of passkeys is better UX when signing in to websites.
Depends on how the password manager stores the passkeys.
I noticed that bitwarden stores TOTP keys such that the secret is exportable. Which means that if you're bitwarden wallet is compromised, even temporarily, the TOTP keys can be stolen.
If the password manager just stores the private key as an encrypted file, then it would probably be better to use a yubikey, iOS or Android device as those are designed to prevent the key from being extractable.
But maybe password managers will store passkeys a HSM.
I'll continue to use WebAuthn hardware keys as a second factor for the small minority of sites where that makes sense. For the rest I'll just use passkeys synced to my password manager.
"What is a passkey?" might as well redirect to zombo.com.
Oh great. So a physical security key could be a passkey, but only if it's used as 1FA not 2FA. At the same time, this weird "store key material in a device and optionally sync to the cloud" thing is called passkey, but if someone uses it as 2FA it suddenly isn't a passkey?
The other thing is that it is more convenient to have "discoverable credentials" (a.k.a. "resident keys") so the browser can check if there are passkeys stored on your FIDO2-authenticator for a specific website. (instead of asking for a username first)
Syncing is optional but if your passkey is not synced, it is usually called a "device-bound passkey" (e.g. Windows Hello).
It's really dumb and I hate github for it. I don't even have anything important on my account, I just use it to log some bugs in FOSS apps. It's time for the FOSS community to compete moving away from this platform as they started to do when Microsoft took it over.
But you still can't remove the TOTP and it will keep asking to 'verify' it every month or so.
How can I guard against losing permanent access to my github account?
Until know I have memorized a very long and random password, that I sometimes type in to keep it in memory. In case of a fire or some similar event in which I would lose my stuff (like devices recovery codes) I'd have no issue, but with the upcoming requirement on github which enforces 2-factor authentication I don't know how I would be able to get access to my account?
A TOTP seed backed up (on paper only) in multiple locations is also a good fallback.
The SMS 2FA is great point! Until now I was able to not hand out my number to bigtech, eg. for Chatgpt I bought an new SIM card with a 5 EUR deposit that I just used for the registration process, but those cards expire after a couple of months if you don't use them. Guess I have to give out cellphone number after all...
Printing out the TOTP seed and hiding the paper in multiple locations sounds somewhat wrong to me. Maybe the TOTP seed will be my new, even longer password to remember j/k
Hmm, but if you would cryptographically hide it in publicly available data, it would be easy to recover.
Thanks for the input!
It's meant to be a second factor, mostly there to prevent unsophisticated, remote/electronic attacks that affect millions of accounts.
Writing it down does not affect its ability to do that.
Agreed, it will prevent any remote attacks.
> As a result, we decided to enable cross-device registration of passkeys. That means, you can register a passkey on your phone while you’re using your desktop. The passkey lives in the phone, but users can connect it to their desktop and set-up and authenticate through the desktop’s browser. This enables Linux and Firefox users to set up passkeys.
This has always been the real no-go for me when I was implementing auth.
I looked into supporting passkeys and found that they're basically useless unless you can make some strong guarantees about who/what can access the keys stored on the device. Linux and the various BSDs can not do this today (and likely will ever be able to do this well given that someone can always recompile a malicious OS that pretends to be another well-trusted OS).
If a user needs to reach to their phone to log into something on their laptop - that's never going to be really secure. It's only a matter of time before everyone starts having "We will never ask for you to log in through your phone, don't do this if someone asks you to" warning labels and respawn the entire industry of anti-phishing mechanisms for this new attack vector.
I don't understand your concern here. Do you mean an evil-maid style attack? At some point you need to trust the user to keep their device secure. A Windows can also have malware.
I'm even using it on my FreeBSD desktop.
They are phishing resistant, even when using the cross-device QR code thing, but that does rely on some base level of trust in the user agent
At the end of the day though, if the browser is the malicious actor, there's simply nothing you can do. That is not a realistic or defensible scenario in most threat models
Passkeys do represent an enormous improvement in security for users, including in the scenario you've highlighted
I know in traditional auth setups, that kind of situation does tend to invite additional concerns, but (again assuming you trust the user agent) FIDO2 still provides full protection when that's happening
But how do you secure that against the threat of a keylogger running on a developer's Linux machine? Am I overthinking here? Is it already game over if the attacker runs software on that developer's machine?
https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.ht...
Yubikeys, and some others, also implement Ed25519 and discoverable key storage, so you can store SSH keys on the Yubikey itself.
From "man ssh-add" on a Mac:
-K Load resident keys from a FIDO authenticator.
You can store an SSH key on the security key itself, and you can use it on any machine you want without needing a corresponding key handle file. Downside to this is that anyone who has your security key potentially has your SSH key.
If you use non-discoverable keys, you need a corresponding key handle to use SSH with your security key. That key handle can be treated like any SSH key, in that you can password protect it and use many rounds of PBKDF2 to secure it. Without that handle you can't use the security key for SSH.
The first method requires you to enter your FIDO password any time you need access to the key, along with touching the authenticator. Using the second method, you can use a keyring to store your key handle's password and/or use an SSH agent, and you potentially just need to unlock it once with a password, then you only need to confirm via touch when you want to use the key.
My GitHub account currently has a 1Password passkey and an Apple passkey. IIRC I added the Apple-generated passkey before 1Password supported them, but both work, and neither prevents me from moving to a different pass* manager in the future.
I personally feel safer that passkeys aren't sync'd across multiple vendors' products.
https://www.yubico.com/resources/glossary/what-is-a-passkey/
Last time I checked into these hardware attestation was part of the specification but the ability export them from a vendors platforms is not. In practice that will mean unapproved platforms can be shut out and walled gardens strengthened. Which will happen sooner or later because it can. Apple supposedly zeroes their attestation but that is only a partial mitigation and relies upon the values of a giant corporation not changing its mind for any host of business reasons. And it does nothing to stop other platforms.
I believe it's there to support the use case of companies who want to ensure their employees are using company-approved devices and methods to interact with company systems.
It's a reasonable use case.
Security keyfob vendors have had attestations for years because they were selling primarily to corporate markets who have closed user bases and stringent authentication requirements, with some also provided to early adopter consumers.
Platforms and password managers are targeting consumer use cases, where preventing the user from leveraging the product would be a terrible thing, as would the 'user agent' problem where later entrants to the market have to beg to be on every site's allow list or lie and claim to be another product.
The synchronization doesn't break attestations. The idea of sites rejecting authenticators that synchronize means that attestations have become an anti-feature in the consumer space.
For me, it's precisely because I know I don't understand how they work.
With a password, I can hold it "in my hand". It's a string. I can export, and basically know that I have the whole thing.
With a passkey, I don't understand it enough to convince myself that my password manager is not able to lock me out of my accounts. The test for me is whether I can copy some piece of data out of the password manager and use it to authenticate. If authentication has to "go through" the manager, then my access to my account is vulnerable to the whims of the password manager. Or perhaps the whims of the new corporate owners of the password manager.
I've migrated passwords once from one password manager to another. I don't understand at all how this is supposed to happen with passkeys.
I'll be holding out either until I can understand satisfactory answers to these, or until support for passwords gets dropped from services I use.
I'm still strongly in favor of passkeys overall, though. They don't need to be used for every service, but strong, safe, phish-proof asymmetric crypto being used for user auth just makes sense.
Fair enough! It still seems a bit like magic when it works.
> With a passkey, I don't understand it enough to convince myself that my password manager is not able to lock me out of my accounts.
I'm not sure how a pass[word|key] manager would lock you out of your accounts, but if you don't use password managers for that reason, that same theoretical danger would be true of passkey managers.
I don't personally have any of my extremely secure auto-created passwords memorized either, so for me a passkey is not different in that respect. If I inadvertently delete a pass[word|key], I'll have to go through the "forgot my password" process.
Within 5 years, I can imagine services without password support. I'd expect that in "lost passkey" cases, those services will support allowing you to log in with a one-time code sent to your registered email address (or SMS) and/or with backup codes.
> I've migrated passwords once from one password manager to another. I don't understand at all how this is supposed to happen with passkeys.
Here's a real-world example: I played with Apple's passkey support before 1Password's passkey support was available. When 1Password added passkey support, I added another passkey to the sites that supported it and called it "1Password".
And here's what it looks like when your Google account has 3 passkeys: https://imgur.com/a/NQl8XPI
Your password manager acts as the middleware between the keys and the software you need to authenticate with. You just need it to speak to services that use passkeys, and you can swap it out for anything that is able to do the same.
Your "password manager" in this case can also just be a physical security key.
You can just use a yubikey unless I'm mistaken?
Yes, USB passkeys work!
You could use any FIDO2 software or hardware key with Passkey.
Though last I checked no browser had created an API for extensions to implement the passkey API. KeepassXC's implementation for example has to inject JS into every page to override `window.navigator.credentials` ( https://github.com/keepassxreboot/keepassxc-browser/pull/178... ). It works but is brittle, so a proper way through extension API would be nice.
For reference, I just 5 minutes ago opened GitHub in Edge on my iOS device, clicked "Sign in with Passkey", and 1Password correctly popped up and offered to sign in with the passkey I had created in Edge on my desktop. I then opened Safari on my phone, and did the same thing. So it definitely is getting there.
A pure web extension password/passkey manager currently has to go the injection route, and will not surface credentials in native apps. This generally means that if you use such a manager, you need to make not to select any options to remove your password, either from your password manager or from the account behind that native app.
It's entirely possible to use passkeys outside of either platform by using any FIDO2 security key with discoverable key storage. There are even existing open source apps that emulate FIDO2 security keys that you can use.
I also believe that passkeys can be backed up and exported on Android/iOS, either now or sometime in the future.
The FIDO Alliance is working on standardizing the backup and transfer of passkeys so that they can be exported and used however you see fit.
That said, I don't use the Android or iOS implementation of passkeys and probably never will. It's possible to use passkeys without ever giving closed platforms the keys to your castle.
But hey at least advertising agencies and the police can track you from one device to the next.
> But hey at least advertising agencies and the police can track you from one device to the next.
Passkeys are unique per login (not per device/user) and the actual synchronization provider is not in the loop - and for e2ee solutions like Password managers or iCloud Keychain, they don't even know what websites are being synced.
Libraries will come for every major language in time, we'll see how easy it becomes to implement. I'm hopeful.
This becomes a liability for security when everyone becomes a user and very few people are contributing. OpenSSL has been an example of this in the past.
Secure password auth is complex and because of externally imposed constraints like phishing, generally needs more work to support. You also need recovery flows, etc, since just losing access typically isn't acceptable. So I don't think password auth can really be "done in several lines."
Realistically, I think the takeaway is that no matter what you're talking about, storing private material on behalf of someone sucks complete ass, and is not easy to accomplish on a modern computer in a secure manner, no matter how you slice it. But we still have to do it. Luckily Passkeys do have actual tangible benefits beyond passwords (e.g. unphishable, no private key material stored by the server), so getting this right does come with actual benefits beyond the status quo.
A minimal implementation can be dramatically simpler; the problem comes in conveying to an application developer what their requirements are for implementing the minimal flow.
Isn't this just removing the password factor, for people already using a security key?
The confusing part is Google, Apple and Microsoft implemented a hardware-secured (hardware is by default the enclave of your phone AND vendor's HSM in cloud) form of passkey, which can also serve as the second factor, replacing both password and 2FA. Some website then decided to support this type of passkey only, NOT passkey + security key, some are even deprecating security key U2F support.
A U2F-only key does not have storage so it cannot implement discoverability on its own. So it won't work as a passkey.
A more modern Yubikey/security key will have the storage to do discoverability, as well as user verification (via pin or possibly via biometric) which some sites might also require.