Passkeys are generally available(github.blog)
github.blog
Passkeys are generally available
https://github.blog/2023-09-21-passkeys-are-generally-available/
123 comments
This was always driving me crazy about webauthn, that you couldn't sync it between devices. You always had to add at least a few devices, not to lose access if you lose a device. And keep track of all services, so you can add new devices if you change them. Not very practical.
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").
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").
Hardware keys don't want to transfer the private key out of the hardware gadget, because that compromises the security model. That's their whole point, you can't extract the secrets, the hardware would rather self-destruct than expose the secret. Lack of "sync" (while retaining ease of transferring the key between computers) is the the primary purpose of a hardware security key.
You're opting to a lower security level by wanting something that can be synced.
You're opting to a lower security level by wanting something that can be synced.
> You're opting to a lower security level by wanting something that can be synced.
I don't think most users care
I don't think most users care
I do care about security, but if I lose my yubikey and i can't backup it, then I need to keep some (insecure) account recovery options enabled.
If I can backup my passkeys, then I can disable them.
If I can backup my passkeys, then I can disable them.
Yubikey advise you to buy two keys and keep one with you and one in a safe space, only used for recovery. That requires the service you use it on to allow multiple keys though, and that’s unfortunately not always the case.
But you always need the second one to set it up for each service.
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.
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.
> I'm not really sure how to use Passkeys on my iPhone with 1Password, but I'm sure that'll come as Passkeys gain traction.
iOS 17 plus the latest 1Password allows you to use passkeys saved in 1P across apps and websites.
iOS 17 plus the latest 1Password allows you to use passkeys saved in 1P across apps and websites.
I wonder why they are requiring iOS 17? Apple's Passkey support includes iOS 16 so I had expected 1Password to also support 16.
Passkey support for users arrived in iOS 16, but the necessary API support for integration with 3rd-party password managers was released with iOS 17: https://blog.1password.com/apple-passkey-api-wwdc/
[deleted]
Looks like GitHub is handling Passkeys smoothly. I added one on my Mac stored in 1Password with no problems.
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.
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 went through this today. Kind of confusing but worked in the end
The rapid change in standards coupled with confusing/changing naming got me to the point where I have no clue what the currently best approach for "passwordless and/or actually secure 2FA" is.
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...
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...
> 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.
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.
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.
Thank you for the correction. I have been referring to them as Passkeys.
OK, so I guess I will have to learn about these passkeys. Which source do you recommend to tell me what it actually is without marketing hype from one of the providers and honestly lays out whether it's better than my current firefox password manager + yubi keys combo.
the FIDO Alliance has an FAQ [0]
> 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.
0: https://fidoalliance.org/passkeys/#faq
1: https://www.youtube.com/watch?v=DWrLBwi7ZBA
> 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.
0: https://fidoalliance.org/passkeys/#faq
1: https://www.youtube.com/watch?v=DWrLBwi7ZBA
> if you already have a password manager you're happy with, the appeal of adopting passkeys is somewhat marginal
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.
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.
> I'll just start storing passkeys in my password manager instead of passwords wherever possible
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.
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 don't plan on using an HSM to store my passkeys anytime soon. The security benefits are marginal for me compared to the huge inconvenience of having to manually update my credentials on hundreds of sites every time I buy a new 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.
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.
You have a (constantly expanding) choice in what software or hardware your passkeys are provided by, and can decide based on your own risk/convenience trade-offs.
There's a nice security improvement to passkeys, as well. No more passwords getting leaked from poorly-run websites, security breaches, etc. You can dump an entire user database and nobody is compromised outside of the obvious privacy implications.
The biggest security benefit of passkeys is that they raise the floor of security posture for the least security conscious users. E.g. You can't use "bob1989!" as your password on every single site, write it on a post-it stuck to your monitor, and enter it into every phishing site that sends you an email claiming to be from "M1cro3oft Supp0rt".
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.
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.
> 0: https://fidoalliance.org/passkeys/#faq
"What is a passkey?" might as well redirect to zombo.com.
"What is a passkey?" might as well redirect to zombo.com.
> Any passwordless FIDO credential is a passkey.
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?
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 term is often used without a clear definition. As a passkey should be used instead of a password, it means that you need "user verification" (PIN or biometrics) to protect the access when the device is lost.
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).
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).
Is there a more technical explanation anywhere? I would like to know what they are not what they are used for and why they are so great.
Exactly what I was looking for, thanks!
https://www.stavros.io/posts/clearing-up-some-passkeys-misco... (courtesy of u/stavros)
They will turn our security keys into junk: https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-tu...
At the risk of setting up a straw man (but the sentiment of your comment seems negative), but should we slow down improved security for the for the whole population, so that a bunch of tech people who have hardware keys with a measly 20 or 32 slots can keep using them?
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.)
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.)
Interestingly, this link says
> [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?).
> [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?).
Personally I think the rk requirement is just fine, the long-tail goal of Passkeys is to simply credential management for users and the UX of key wrapping stands in opposition of that.
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.
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.
The super annoying thing with github is that while it supports passkeys now, it still requires you to set up TOTP (eg Google authenticator) as the main MFA method and requires you to "verify" it often. Leading me to have to go find my phone, open the MFA app etc when I could just simply tap my Yubikey.
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.
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.
GitHub has a "Preferred 2FA method" method that you can set to passkeys.
Using passkeys as an additional login method I can understand, but I have a problem that I don't know how to solve:
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?
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?
Given GitHubs policy of "no account recovery if you lose 2FA, ever, if you screw up you lose that account forever", lockout seems a bigger threat than takeover. Luckily, Github lets you add SMS 2FA. That isn't secure, but at least you should be able to get access to your phone number in case of a disaster.
A TOTP seed backed up (on paper only) in multiple locations is also a good fallback.
A TOTP seed backed up (on paper only) in multiple locations is also a good fallback.
I agree - at least for me, the lockout scenario seems more likely.
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!
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!
Why would hiding the TOTP seed in multiple locations be wrong?
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.
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.
It reminds me of post it stickers on the monitor. Well, to be fair more like post-it stickers in a hopefully locked desk drawer.
Agreed, it will prevent any remote attacks.
Agreed, it will prevent any remote attacks.
You can set up multiple 2FA- I have two yubikeys and a TOTP key registered.
1password can store passkeys for you and sync between multiple devices. Then I add a Yubikey Bio to add of these accounts as a backup.
Thank you for the answer! I don't want to use a cloud service for sync, I will take a look if an opensource solution has a direct device to device sync, I haven't thought about that. I will also checkout the yubikey bio - I guess as it's hardware so no pesky account cloud connected? Thanks for the ideas!
> We found that Linux and Firefox users struggled to use passkeys, as those platforms don’t yet have strong support for passkeys.
> 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.
> 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.
> 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
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 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.
All forms of FIDO2 authentication do fundamentally rely on being able to trust the browser to not misrepresent the "relying party" (the RP, aka the registered domain, github.com in this case)
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
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
Did any Linux distro showed any interest to implement Passkeys? Ubuntu and Fedora are probably most likely to do something about it first. Ubuntu already has encryption that uses TPM chip.
If you mean "FIDO2 platform authenticator", this project looks promising: https://github.com/AlfioEmanueleFresta/xdg-credentials-porta...
Linux supports Yubikeys though, in Chrome and Firefox. It's a really secure way of using the same mechanism that is passkeys.
I'm even using it on my FreeBSD desktop.
I'm even using it on my FreeBSD desktop.
I think a weakness with Github might be ssh-based pushes. Hopefully the user uses an ssh passphrase (typed at every remote git interaction, or typed once per session via ssh-agent. MacOS does something special with their secure enclave thing.)
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?
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?
You can use FIDO security keys with SSH and a keylogger would be useless unless someone has physical access to your security key.
Thanks, this looks interesting. Are you using Yubikeys or something else?
https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.ht...
https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.ht...
Both. FIDO2 compliant devices need to implement ECDSA at minimum, which means you can use non-discoverable keys for SSH at minimum.
Yubikeys, and some others, also implement Ed25519 and discoverable key storage, so you can store SSH keys on the Yubikey itself.
Yubikeys, and some others, also implement Ed25519 and discoverable key storage, so you can store SSH keys on the Yubikey itself.
Yes be aware that the discoverable slots are very limited (I forget but I think it's 8) and they are also used for passwordless use with websites. There's no way to reassign those slots right now short of wiping the whole key.
At least with Yubikeys, there are 25 discoverable key slots and you're able to pick and choose which keys you want to delete or save at any time using the Yubico Authenticator.
Hmm I don't have that option. Perhaps my firmware is too old. Unfortunately Yubikeys can't be updated anymore since the early NEOs :(
I use a Google Titan key for this purpose, have a ssh key password that I can "cache" for the session on my macos key chain, but I have to tap the Titan key for every pull/push
Can this be "emulated" on macOS with the keychain?
On a modern Mac with secure enclave doing "ssh-add -K /path/to/private/key/file" and entering the passphrase once does this. It's really neatly implemented.
From "man ssh-add" on a Mac:
From "man ssh-add" on a Mac:
-K Load resident keys from a FIDO authenticator.
You can also use the `-K` flag without specifying a path if you store your SSH key on the security key itself.
Is this the way to go, and if so why?
Like anything, there are tradeoffs between them.
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.
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.
Secretive might be what you're looking for: https://github.com/maxgoedjen/secretive
I still don’t understand why anyone who isn’t in the walled garden business would consent to passkeys.
Maybe you misunderstand how they work?
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.
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.
> Maybe you misunderstand how they work?
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.
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.
> 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.
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
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
If you know how public key authentication works, then you know how passkeys work. Passkeys are private and public key pairs.
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.
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.
Saying "I can swap it out" is different from me actually knowing what buttons to press to make that happen. It is at least partially lack of familiarity, but I'm not seeing how to do that with passkeys.
From looking at the 1Password app, exporting Passkeys isn't an option. that's a bit of a usability nightmare IMO, one which I hadn't considered.
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.
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.
Good points, maybe 1Password will pull a Unity post-IPO and demand 1 cent per login. Right now, 1Password is really good, but who knows if it'll stay the same.
> I personally feel safer that passkeys aren't sync'd across multiple vendors' products.
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.
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.
FIDO itself specifies that attestation can be used but it's extremely likely browsers aren't going to ever support it for the same reason Apple has publicly said they won't: because attestation is a misfeature for Passkeys, because it completely eliminates the (very important and large) ability to synchronize Passkeys across devices using third party apps or built in browser mechanisms. Having to manually re-enroll every device is like a step backwards 10 years into the past from a usability POV. Device-attestation for passkeys was always 100% DOA for this reason, because without it, they can't form a suitable password replacement in the existing ecosystem, where synchronization is basically expected.
Bizarre they would make room in the specification for a DOA misfeature no one is going to use and everyone hates. Why not remove it from the spec and place the requirement of synchronization support into the spec instead?
Not that everyone hates it. Competing models of usability/openness.
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.
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.
I can't read anyone's mind. I assume it's simply because passkeys can be used outside the browser, in theory for arbitrary applications, and like every standard, it tries to satisfy a large set of users, there are tradeoffs, and some might want attestation. It's just that browsers and password managers are two use cases of the standard that don't want it, because it largely eliminates one of their major selling points, which is that they're synchronized like a password is today, so there's a clear UX flow/user upgrade path.
> Why not remove it from the spec and place the requirement of synchronization support into the spec instead?
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.
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.
I don't know that I've encountered a service that allows exactly one passkey. Everything I've tried either doesn't support passkeys at all, or supports multiple. In the latter case, add an iOS/Android passkey and something separate like a YubiKey. If one gets lost or you stop using it, the other still works.
Are there good open-source, self-hostable alternatives to 1Password that do this?
I'm also still waiting for the answer to this question. No way I'm going to let apple or google control half of my access to everything I use online...
FWIW, passkey support doesn't mean that Apple or Google controls anything. It's all standards-based. Use a Yubikey or whatever you like.
https://www.yubico.com/resources/glossary/what-is-a-passkey/
https://www.yubico.com/resources/glossary/what-is-a-passkey/
Fyi it’s in the works for KeepassXC:
https://github.com/keepassxreboot/keepassxc/issues/1870#issu...
Because you don't understand passkeys. And you probably don't know password managers can store passkeys as well as the OS
If your only exposure to passkeys is through their Android and iOS implementations, I could understand this initial reaction, but they don't only exist on Android and iOS.
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.
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.
A password manager can easily implement passkeys just like it implements passwords.
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.
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.
It's a really recent addition to Chrome/Edge to support that, and it only was supported on iOS in v17 which came out last week. Actually, 1Password probably released their support for Passkeys last week precisely because iOS 17 was finally out.
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.
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.
[deleted]
Android and iOS 17 have native API to supply passkeys via system API, which will surface in browsers as well as native apps.
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.
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.
I can’t speak to other platforms, but iOS natively integrates with third party password managers for passkey support, including inside Safari.
The 1Password extension in Chrome does this so I assume there is some API
Every password manager browser extension does a similar injection, including 1Password.
I agree. An open API in browsers would simplify things a lot.
From my understanding they're basically an extension of FIDO?
You can just use a yubikey unless I'm mistaken?
You can just use a yubikey unless I'm mistaken?
Good. Now I can access someone's entire life including their banking just by guessing the pin on their phone. We went from bad passwords to even worse pins.
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.
So step 1 is stalk someone to see their passcode, and step 2 is steal their phone. Is phone theft of this level rampant where you're from? Even if a phone is stolen, going far enough to commit wire fraud by stealing money from someone's bank is too much to ask for over selling it to China for $200+.
> 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.
> 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.
How are passkeys worse than passwords for tracking you across devices?
Works smoothly with MacOS and TouchID.
I think the biggest roadblock to widespread adoption outside major corporations is how complex they are to implement on the server side, in particular in comparison to passwords which are trivial. Every implementation I've seen so far has been multiple thousands of lines, whereas password auth can be done in several lines.
Libraries will come for every major language in time, we'll see how easy it becomes to implement. I'm hopeful.
Libraries will come for every major language in time, we'll see how easy it becomes to implement. I'm hopeful.
> whereas password auth can be done in several lines.
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.
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.
Safe password authentication is also not trivial to implement, especially not with a second factor. Let's hope even more people will use authentication frameworks created by experts, instead of some badly salted password databases.
> Every implementation I've seen so far has been multiple thousands of lines…
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.
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.
A webauthn library will likely support things which you don't need for simply accepting passkeys, such as attestations and extension support.
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.
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.
Is it correct that a yubikey with U2F / webauthn can be used as a passkey, it's just the physically portable kind?
Isn't this just removing the password factor, for people already using a security key?
Isn't this just removing the password factor, for people already using a security key?
In theory, passkey replaces password. Single factor passkey is more secure than single password, and it doesn't matter where it's stored. A passkey in whatever password manager we use (KeePass etc) makes sense. Such a passkey should not replace 2FA - you'd better still have a second factor.
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.
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.
The passkey terminology is describing a "primary factor" user experience, which requires certain WebAuthn features to be implemented.
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.
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.
Passkey is really just a type of webauthn. It doesn't necessarily have to remove any other factors. I think the primary goal is to replace single-factor passwords with it.
Very nice! Passkeys can't come soon enough to more services.
jjgreen(1)
1Password has a directory [1] of sites that have Passkey support, so one day I moved over those accounts.
[0]: https://1password.com/product/passkeys
[1]: https://passkeys.directory/