In some parallel universe, each computing device manufacturer is required by law to provide a storage so that the user can plug in their single, universal, transferrable set of security credentials (like passkeys). Instead of "many cooks" mentioned in the article, there is one standard.
I cannot bring myself to agree to any "switch to passkey" prompt from any device because I have no idea (and too tired to figure out) how and where that key will be stored, how do I deal with different devices, etc. I already have a universal solution for credentials: 1password, which is cross-platform. With Apple's keychain, and I suspect other companies' solutions, passkeys are connected to your account and at best synced between devices from the same manufacturer. But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.
Like with many other solutions, the current approach with passkeys is designed for an imaginary "user in vacuum" model each company dreams about, where people are 100% into one ecosystem, forever.
> With Apple's keychain, and I suspect other companies' solutions, passkeys are connected to your account
And from this account you may be locked out for various reasons anytime, as it happened to countless persons previously, violating exotic or even understandable rules, or just been in the crossfire of some galactic corporate incompetence (some f'd up), but this way you'd be locking yourself out of everything especially if you were that user in the vacuum, exposing yourself to the mercy of a single organization with changing managemenet and incentives as the wind turns in a city's dense downtown.
Using 1Password as your passkey backend seems like it would solve all the problems you're describing, except that passkeys are (for the time being, at least) locked in to 1Password [1]. It works on multiple OSes (as a native passkey backend on iOS, via browser extensions providing WebAuthN on all major OSes) and isn't tied to your Apple ID.
If you care a lot about exportable passkeys, Bitwarden (and Vaultwarden) can export them. Not sure if any other implementation can import them at the moment, but the data looks portable enough (i.e. it contains the ECDSA private key and all other client properties required).
>In some parallel universe, each computing device manufacturer is required by law to provide a storage so that the user can plug in their single, universal, transferrable set of security credentials (like passkeys). Instead of "many cooks" mentioned in the article, there is one standard.
Ignoring site support, this exists. It's called USB and yubikey.
”But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.”
Apple has recently addressed this. You can now create shared groups, and selectively assign passwords and passkeys to the groups. You could easily create a group with your two identities and move the credentials to that group.
>But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs
You can't save your personal passkeys on your work phone and vice versa, but when logging in to a service on one device, you should be able use a passkey from the other device via Bluetooth by scanning a QR code.
I think that we should consider passing a law that a vendor may non disable “log in with” and supporting functionality like password recovery, for a user account for some lengthy period of time after involuntary termination of the user.
But I think that the bigger issue is that I don’t think that large corporations should be allowed to disassociate with their users except in the case where criminal activity against that company is involved. This is especially important now that all the vendors want ecosystem lock-in AND have ToS that allow them to cancel pretty much arbitrarily.
Honest question, this isn't supposed to be a burn in any sense. But isn't it contradictory to want to know how and where your credentials are stored and use any credential management solution that isn't opensource and selfhosteable?
> With Apple's keychain, and I suspect other companies' solutions, passkeys are connected to your account and at best synced between devices from the same manufacturer.
iCloud Keychain/Passwords works on macOS and Windows, and there are extensions for Chrome and Edge. I don't know whether it works with passkeys though.
> But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.
As I understand it, Apple's BYOD support allows you to have a managed/corporate Apple ID and a personal Apple ID on the same device. You can also add a managed Apple ID to a personal device like an iPhone; on iOS (and possibly macOS?) it isolates the data between them so that corporate apps can't access personal data and vice-versa.
I believe it's possible to have multiple accounts with separate Apple IDs, and I think it is possible to add "secondary" Apple IDs to a single account, but I don't have experience with this.
I moved away from 1P some time ago due to their move to a subscription model. After trying other solutions and having high hopes for Apple finally shipping a passwords app I finally decided to move back this year.
It's costly but excellent. I have several accounts shared with my wife and was getting caught up in the passkey problems you mentioned. Even though 1P handling OTP is not really 2FA it's very convenient and still more secure than no OTP. I also don't always want to have to have my phone on me.
On top of that I like knowing that if I change my mind at some point I can export my credentials. Moving my iCloud keychain creds was an eye-opener: it felt purposefully painful. You can do it but much of the metadata is missing or lost in the process, with the titles being the URLs. Yuck.
> I cannot bring myself to agree to any "switch to passkey" prompt from any device because I have no idea (and too tired to figure out) how and where that key will be stored, how do I deal with different devices, etc.
There is a draft standard in the works for export/import:
> But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.
By design. This is what caused the ZenDesk, Atlassian, Disney and Sony hacks.
> their single, universal, transferrable set of security credentials (like passkeys)
That's an awful idea. Normal people already have a nightmare of a time with getting locked out of accounts, and now you want their entire lives to depend on a single hardware fob that can get lost?
> is required by law to provide a storage so that the user can plug in their single, universal, transferrable set of security credentials (like passkeys)
Wow, that will immediately become a prime target for hackers / phishers.
each computing device manufacturer is required by law to provide a storage so that the user can plug in their single, universal, transferrable set of security credentials (like passkeys)
Indeed and that law would provide overrides for the state. And which state, you might ask? All of them? The state where the device is manufactured? Hmm...
The article author skirts around the key true observation here, which is that passkeys were a great idea until cloud vendors waged war on hardware keys.
The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise.
The concept of a passkey as desired by Apple, Google, and Microsoft is that every user magically authenticates using their OS, and has no ability to authenticate otherwise.
The reason the UX is confusing is because the OS vendors don't want the users using non-OS software or hardware - they want you to use a cloud-hosted passkey instead of using a Discoverable Credential on a Hardware Authenticator, and instead of using a password manager providing its own sync facility. This is shown in the screenshots in the article.
The ideal future state is:
* the provider for newly registered credentials would be a browser setting
* the setting would come configured to use the OS vendor out of the box
* installing a password manager providing passkeys would prompt to change the setting to use the password manager instead
* one of the options in this setting would be "prompt me every time". Approximately nobody would choose that option
* there would never be a prompt for what to use on authenticate() calls, only register(). Authenticate would use whichever valid credential you provided first, whether that's plugging in a token or scanning your thumb to unlock a TPM or whatever
In this world, 99% of people are using OS-vendor-provided cloud-synced passkeys, but technical users get what they want too and everybody has both a secure and an easy experience.
The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor, and they have a conflict of interest because the OS vendors are also cloud services vendors.
> passkeys were a great idea until cloud vendors waged war on hardware keys.
> The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise.
This was never a great idea, it was totally unworkable for nearly everyone. Physical keys work because locksmiths exist, keys can be copied, and users get to choose when they lock the door/box/whatever. And even with those benefits they're rapidly being replaced for a lot of people with PIN codes or mobile apps precisely because physical keys are suboptimal.
Hardware keys as envisioned here cannot be copied without registering the copy separately with each and every service, have no equivalent of locksmiths besides "store these 10 recovery codes somewhere safe" (also unworkable as a solution), and between session timeouts and multiple devices users are regularly unable to predict when and where they will need to create a new session.
Hardware keys were designed for a spherical humanity, not for the humanity that has to deal with ADHD, dementia, babies, kids, fires, floods, and a host of other failure modes. OS keys inherit many but not all of the flaws of hardware keys, but at least they don't rely on a human being responsible!
I think a critical feature is missing that makes this almost entirely unworkable: usable handling of backup tokens. There is no way to register a token in a safe. There is no way to name a token to keep track of which one it is. There is no intelligent way to migrate from one token to a new one. Working with two computers with mutually incompatible ports is incredibly annoying.
NFC tokens have basically no security against a close range attacker. How much this matters depends on the threat model.
Also: the cloud vendor passkeys (Apple, Google, etc) are far more secure against an attacker that steals a device.
This is not to say that cloud based passkeys are amazing. AFAICT there is nothing remotely resembling an automated way to rotate a key. I’m not even convinced it can be done manually in a straightforward manner. This is not so great, given that a passkey is effectively an unlimited lifetime key pair with no revocation mechanism, that may well be stored without hardware security and that can be propagated to different generations of devices. Also, what happens if a device is stolen and compromised at least enough to keep its password manager running?
> The concept of a passkey as desired by Apple, Google, and Microsoft is that every user magically authenticates using their OS, and has no ability to authenticate otherwise. [...] The reason the UX is confusing is because the OS vendors don't want the users using non-OS software or hardware
Completely untrue. Both iOS/macOS and Android offer an API for third party passkey implementations ("backends"). macOS also offers a client API for that that browsers ("frontends") can hook into. You can use Strongbox (a KeePass implementation) with Chrome, iCloud Keychain with Firefox, a Yubikey with Safari...
It's really as open an ecosystem as it gets at this point, and for software implementations, there isn't even attestation that could allow relying parties to block any specific implementation.
> The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor [...]
No, this "ideal state" is in fact the reality I've been experiencing for the past few months.
> installing a password manager providing passkeys would prompt to change the setting to use the password manager instead
iOS supports this today. If a password manager app describes that it implements passkey management, iOS asks what you want to be the default and the UI changes a bit to allow easier choices between iCloud and your password manager app.
It sounds like macOS is the place where Apple is lagging the most on API hooks that applications can use to trigger the UX.
It's also possible that Apple is just prioritizing that macOS users are mostly bought into the iCloud Keychain and their cloud infrastructure whereas iOS does have a large known mixture of iOS/Windows users that may bring their own keychains/password managers.
Looks good until Mallory sets up a phishing site that tricks users into installing a thing that registers itself as their “password manager” and mitms their entire life.
Not saying there aren’t other reasons the OS vendors are pushing back on supplying that hook, but that’s one that is at least vaguely pro-user.
TOTP suffers from a similar issue - I use 1Password to store my TOTP codes, but both Google and the UK's HMRC tax website talk about using their own apps for codes rather than anything agreed like "one-time passwords". The digital world is rife with this kind of jockeying for position through language. It took me far too long to understand that "podcasts" are just mp3 files from an RSS feed.
Likewise, in the heyday of interactive TV in the early 2000s, when it was going to conquer the world because everyone had a TV but not a computer, an agency I worked for were invited for a demonstration of a choose-your-own-adventure game they were developing. They kept referencing a "carousel system" where all pages were sent in a looping system and when someone made a choice it waited until that page came round in the "carousel". I kept asking whether that was like Teletext - https://en.wikipedia.org/wiki/Teletext - but they absolutely refused to say that and kept saying "well, it's a carousel system".
This refusal to deal in everyday language, alongside trying to get people to use their own apps / sytems, really hinders the adoption of useful technologies.
Not sure what you are talking about TOTP suffering from a similar issue.
TOTP works via a secret key provided by the service. The TOTP(secret key + time) function generates a 6 digit code. This is a standard. The secret key can be stored on Authenticators and those authenticators sync to cloud services.
When adding the secret key for the first time to your authenticator, you have to also copy that to a notepad. This way if you want to transfer the keys, you have them available. Authenticator apps don't always allow you to export the keys. TOTP.app is a good auth app that does allow but there is no sync to cloud capability.
Most passkey stores refuse to let you export them, and the real reason is vendor lockin. (They also did this with TOTP keys.)
Bitwarden is one of the few that don’t - you can export passkeys, although for now, there’s nothing to import them to unless you want to run a roll your own open source solution.
While I agree with many of the points raised by the author, I guess I just had much much more pessimistic expectations than they did. If I were to write an article on the topic, I'd probably end up listing the exact same factual information, but with the opposite spin: "This is progressing much quicker and more smooth than I would have anticipated!"
Switching from passwords to passkeys is a big change in the entire security model of the modern user-facing internet. We shouldn't be at all surprised that people are both cautious and opinionated about how it should be done, how to migrate users, and how to deal with fallbacks.
Yes, the current situation is one that is messy and not significantly more secure than the previous status quo, but the direction of travel seems at least promising.
I wouldn't actually want my bank to overnight decide that passkeys are the way to log in, and if I use a passkey there should be no insecure fallback options. I want my bank to roll out a passkey, and figure out the infrastructure around it, probe for problems, and allow fallbacks that are equivalent to their previous systems. Similarly, I wouldn't want every passkey management implementation to instantly coalesce around one specific set of management practices and UX. I want various ideas to be tried out and see what comes out of it, even if some of those experiments are bad.
I think passkeys are a failed product. Time to give up and start over again.
I don't say this casually. I have been arguing for ending passwords for nearly 20 years now. I'm a software engineer and broadly understand a lot of security protocols. I spent hours understanding passkeys and figuring out how to use them in my environment. The core idea is great! But the usability is garbage.
I still can't use passkeys reliably. The combination of bad implementations in Windows, Chrome, 1Password, and various websites has defeated me. All passkeys do now is clutter up the one login flow that works for me (1Password form filling, as awful as that is.)
I seem to be in the minority of HN users that love passkeys. I use them for any login that I reasonably can. When creating a passkey I create one in iCloud Keychain as well as in 1Password. I do agree that there needs to be a better import/export story, but I have confidence that will come.
It’s invisible. A black box, non transferable. There’s no mental model that maps and you can’t back it up as a normal person. Implementations are half baked and still require all the rest, all the attack surface is even larger.
As a technical user who understands how these work and has none of the confusion issues the author describes, my biggest problem and the reason I stopped using them for google is they seem to arbitrarily set the session length for passkey authenticated sessions much lower. I found myself needing to reauthenticate with google every day or 2 when signing in via pass key. I assume the developers thought this would be seamless, but it is a very annoying interruption to workflow. Especially since I use 1password as the backend with my laptop screen closed it results in me needing to type my (long and complicated) password manager password every time and usually when I am trying to access something timely like a meeting invitation.
I think the elephant in the room is the total lack of website/framework/library support Fido has. Trying to implement support on any random site is about as insane as rolling your own crypto and having the single sign on bolt on is sort of how people selling FOSS+enterprise want it.
The end result is that it was more a standard for them more than for direct use by the little sites, and password managers getting involved only furthers that enterprise industry standard feel.
It gets worse. U2F keys were stateless, the site key pair was stored by the site (encrypted to, and by, the u2f key). Now, passkeys are stored in the device, and, you guessed it - they have a limited number of slots.
This piece reads very nitpicky, and I just don't identify with what it's saying. My use of passkeys in Safari on Apple platforms has been basically seamless.
I guess if you use tons of different browsers on tons of different platforms and want to work in hardware tokens, it's a pain, but most people aren't doing that.
The problems highlighted are real, but they don't rise to the level of "Passkeys aren't usable security". For users that would have otherwise not opted into 2FA at all (or don't know how to set up TOTP), passkeys are fine. I'm sure there are some warts to iron out, but they have to be evaluated within the context of the practical alternatives, not the context of the author's own personal security priorities.
This matches my experience perfectly. As someone who is technically skilled but has no particular security expertise, I've tried to gradually implement passkeys where available across the most important and frequently used of my accounts, and... I'd have to go read the goddamn spec to have any idea what's going on. Pretty much all I've learned is that sometimes I can use touch ID to log into stuff now, and sometimes I can't, and the reasons are totally damn opaque.
Passkeys are simply over-engineered. A passwordless login system need only the following:
- $AUTHENTICATOR is one of (browser extension, browser, OS, hardware)
- $AUTHENTICATOR stores mappings ($SITE,$PUBKEY) => $PRIVKEY
- $SITE can ask $AUTHENTICATOR to generate a new $PRIVKEY and give it its $PUBKEY
- $SITE can ask $AUTHENTICATOR to sign a challenge with the $PRIVKEY corresponding to one of the $PUBKEYs for that $SITE
- the user can pick which $PRIVKEYs are synced and which can be exported (depending on $AUTHENTICATOR capabilities)
Bonus points for adding a way to do the authentication off-device through QR codes, so $AUTHENTICATOR one one device can authenticate a session on another device (like using a phone to log into $SITE on the desktop, perhaps for the purpose of adding another authenticator there).
Anyone know what adoption rates for passkey looks like now? I think they are cool too, but the constant prompting to create them and invisible/variable UI everywhere is a problem. It presents as inconsistent as compared with the standardized username/password form that grandmas understand.
I will never use Face ID or Fingerprint for any device, but I agree, passkeys are a bit too much. Also, the OSs I use may not support passkeys. They are not on the list.
The magic of password is that you can write them to paper or keep them in your mind. No interoperability issue if suddenly having to use it temporarily or permanently with another device, like if you lose your phone. And you can also pretend they don't exist and no one can prove otherwise. Also if you don't use a password manager, no one (hacker or else) can extract it from your head like it can be forced from your devices.
Passkeys deployment reminds me of a cartel agreement among FAANG without the actual coordination. It's too good of a new tech frontier not to colonize.
I haven't used passkeys, I have not been prompted about it, asked to create one, been reminded to change to it, or anything like that. It is like they don't exist to me. Am I supposed to be nagged about it in order to change to it? Or is it something you have to hunt for in the account details of a site? Unsure if I am a late adopter or if the technology has not found me yet.
[+] [-] freetonik|1 year ago|reply
I cannot bring myself to agree to any "switch to passkey" prompt from any device because I have no idea (and too tired to figure out) how and where that key will be stored, how do I deal with different devices, etc. I already have a universal solution for credentials: 1password, which is cross-platform. With Apple's keychain, and I suspect other companies' solutions, passkeys are connected to your account and at best synced between devices from the same manufacturer. But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.
Like with many other solutions, the current approach with passkeys is designed for an imaginary "user in vacuum" model each company dreams about, where people are 100% into one ecosystem, forever.
[+] [-] mihaaly|1 year ago|reply
And from this account you may be locked out for various reasons anytime, as it happened to countless persons previously, violating exotic or even understandable rules, or just been in the crossfire of some galactic corporate incompetence (some f'd up), but this way you'd be locking yourself out of everything especially if you were that user in the vacuum, exposing yourself to the mercy of a single organization with changing managemenet and incentives as the wind turns in a city's dense downtown.
[+] [-] lxgr|1 year ago|reply
If you care a lot about exportable passkeys, Bitwarden (and Vaultwarden) can export them. Not sure if any other implementation can import them at the moment, but the data looks portable enough (i.e. it contains the ECDSA private key and all other client properties required).
[1] https://support.1password.com/save-use-passkeys/ mentions that "Passkeys saved in 1Password can’t be exported at this time."
[+] [-] _Algernon_|1 year ago|reply
Ignoring site support, this exists. It's called USB and yubikey.
[+] [-] pcl|1 year ago|reply
Apple has recently addressed this. You can now create shared groups, and selectively assign passwords and passkeys to the groups. You could easily create a group with your two identities and move the credentials to that group.
https://support.apple.com/guide/iphone/share-passwords-iphe6...
[+] [-] YPPH|1 year ago|reply
You can't save your personal passkeys on your work phone and vice versa, but when logging in to a service on one device, you should be able use a passkey from the other device via Bluetooth by scanning a QR code.
[+] [-] efitz|1 year ago|reply
But I think that the bigger issue is that I don’t think that large corporations should be allowed to disassociate with their users except in the case where criminal activity against that company is involved. This is especially important now that all the vendors want ecosystem lock-in AND have ToS that allow them to cancel pretty much arbitrarily.
[+] [-] loloquwowndueo|1 year ago|reply
[+] [-] paxys|1 year ago|reply
You can store passkeys in 1password so they work everywhere.
[+] [-] gchamonlive|1 year ago|reply
[+] [-] musicale|1 year ago|reply
iCloud Keychain/Passwords works on macOS and Windows, and there are extensions for Chrome and Edge. I don't know whether it works with passkeys though.
> But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.
As I understand it, Apple's BYOD support allows you to have a managed/corporate Apple ID and a personal Apple ID on the same device. You can also add a managed Apple ID to a personal device like an iPhone; on iOS (and possibly macOS?) it isolates the data between them so that corporate apps can't access personal data and vice-versa.
I believe it's possible to have multiple accounts with separate Apple IDs, and I think it is possible to add "secondary" Apple IDs to a single account, but I don't have experience with this.
[+] [-] ElFitz|1 year ago|reply
[+] [-] grahamj|1 year ago|reply
It's costly but excellent. I have several accounts shared with my wife and was getting caught up in the passkey problems you mentioned. Even though 1P handling OTP is not really 2FA it's very convenient and still more secure than no OTP. I also don't always want to have to have my phone on me.
On top of that I like knowing that if I change my mind at some point I can export my credentials. Moving my iCloud keychain creds was an eye-opener: it felt purposefully painful. You can do it but much of the metadata is missing or lost in the process, with the titles being the URLs. Yuck.
[+] [-] throw0101d|1 year ago|reply
There is a draft standard in the works for export/import:
* https://fidoalliance.org/specifications-credential-exchange-...
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] Mandatum|1 year ago|reply
By design. This is what caused the ZenDesk, Atlassian, Disney and Sony hacks.
[+] [-] crooked-v|1 year ago|reply
That's an awful idea. Normal people already have a nightmare of a time with getting locked out of accounts, and now you want their entire lives to depend on a single hardware fob that can get lost?
[+] [-] mystified5016|1 year ago|reply
[+] [-] exabrial|1 year ago|reply
[+] [-] gwbas1c|1 year ago|reply
Wow, that will immediately become a prime target for hackers / phishers.
[+] [-] mcshicks|1 year ago|reply
https://www.congress.gov/bill/118th-congress/senate-bill/884...
[+] [-] joe_the_user|1 year ago|reply
Indeed and that law would provide overrides for the state. And which state, you might ask? All of them? The state where the device is manufactured? Hmm...
[+] [-] Borealid|1 year ago|reply
The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise.
The concept of a passkey as desired by Apple, Google, and Microsoft is that every user magically authenticates using their OS, and has no ability to authenticate otherwise.
The reason the UX is confusing is because the OS vendors don't want the users using non-OS software or hardware - they want you to use a cloud-hosted passkey instead of using a Discoverable Credential on a Hardware Authenticator, and instead of using a password manager providing its own sync facility. This is shown in the screenshots in the article.
The ideal future state is:
* the provider for newly registered credentials would be a browser setting
* the setting would come configured to use the OS vendor out of the box
* installing a password manager providing passkeys would prompt to change the setting to use the password manager instead
* one of the options in this setting would be "prompt me every time". Approximately nobody would choose that option
* there would never be a prompt for what to use on authenticate() calls, only register(). Authenticate would use whichever valid credential you provided first, whether that's plugging in a token or scanning your thumb to unlock a TPM or whatever
In this world, 99% of people are using OS-vendor-provided cloud-synced passkeys, but technical users get what they want too and everybody has both a secure and an easy experience.
The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor, and they have a conflict of interest because the OS vendors are also cloud services vendors.
[+] [-] lolinder|1 year ago|reply
> The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise.
This was never a great idea, it was totally unworkable for nearly everyone. Physical keys work because locksmiths exist, keys can be copied, and users get to choose when they lock the door/box/whatever. And even with those benefits they're rapidly being replaced for a lot of people with PIN codes or mobile apps precisely because physical keys are suboptimal.
Hardware keys as envisioned here cannot be copied without registering the copy separately with each and every service, have no equivalent of locksmiths besides "store these 10 recovery codes somewhere safe" (also unworkable as a solution), and between session timeouts and multiple devices users are regularly unable to predict when and where they will need to create a new session.
Hardware keys were designed for a spherical humanity, not for the humanity that has to deal with ADHD, dementia, babies, kids, fires, floods, and a host of other failure modes. OS keys inherit many but not all of the flaws of hardware keys, but at least they don't rely on a human being responsible!
[+] [-] amluto|1 year ago|reply
NFC tokens have basically no security against a close range attacker. How much this matters depends on the threat model.
Also: the cloud vendor passkeys (Apple, Google, etc) are far more secure against an attacker that steals a device.
This is not to say that cloud based passkeys are amazing. AFAICT there is nothing remotely resembling an automated way to rotate a key. I’m not even convinced it can be done manually in a straightforward manner. This is not so great, given that a passkey is effectively an unlimited lifetime key pair with no revocation mechanism, that may well be stored without hardware security and that can be propagated to different generations of devices. Also, what happens if a device is stolen and compromised at least enough to keep its password manager running?
[+] [-] lxgr|1 year ago|reply
Completely untrue. Both iOS/macOS and Android offer an API for third party passkey implementations ("backends"). macOS also offers a client API for that that browsers ("frontends") can hook into. You can use Strongbox (a KeePass implementation) with Chrome, iCloud Keychain with Firefox, a Yubikey with Safari...
It's really as open an ecosystem as it gets at this point, and for software implementations, there isn't even attestation that could allow relying parties to block any specific implementation.
> The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor [...]
No, this "ideal state" is in fact the reality I've been experiencing for the past few months.
[+] [-] samcat116|1 year ago|reply
[+] [-] WorldMaker|1 year ago|reply
iOS supports this today. If a password manager app describes that it implements passkey management, iOS asks what you want to be the default and the UI changes a bit to allow easier choices between iCloud and your password manager app.
It sounds like macOS is the place where Apple is lagging the most on API hooks that applications can use to trigger the UX.
It's also possible that Apple is just prioritizing that macOS users are mostly bought into the iCloud Keychain and their cloud infrastructure whereas iOS does have a large known mixture of iOS/Windows users that may bring their own keychains/password managers.
[+] [-] fastball|1 year ago|reply
[+] [-] mikepurvis|1 year ago|reply
Not saying there aren’t other reasons the OS vendors are pushing back on supplying that hook, but that’s one that is at least vaguely pro-user.
[+] [-] frereubu|1 year ago|reply
Likewise, in the heyday of interactive TV in the early 2000s, when it was going to conquer the world because everyone had a TV but not a computer, an agency I worked for were invited for a demonstration of a choose-your-own-adventure game they were developing. They kept referencing a "carousel system" where all pages were sent in a looping system and when someone made a choice it waited until that page came round in the "carousel". I kept asking whether that was like Teletext - https://en.wikipedia.org/wiki/Teletext - but they absolutely refused to say that and kept saying "well, it's a carousel system".
This refusal to deal in everyday language, alongside trying to get people to use their own apps / sytems, really hinders the adoption of useful technologies.
[+] [-] nashashmi|1 year ago|reply
TOTP works via a secret key provided by the service. The TOTP(secret key + time) function generates a 6 digit code. This is a standard. The secret key can be stored on Authenticators and those authenticators sync to cloud services.
When adding the secret key for the first time to your authenticator, you have to also copy that to a notepad. This way if you want to transfer the keys, you have them available. Authenticator apps don't always allow you to export the keys. TOTP.app is a good auth app that does allow but there is no sync to cloud capability.
[+] [-] ffsm8|1 year ago|reply
[deleted]
[+] [-] trollbridge|1 year ago|reply
Bitwarden is one of the few that don’t - you can export passkeys, although for now, there’s nothing to import them to unless you want to run a roll your own open source solution.
[+] [-] eigenspace|1 year ago|reply
Switching from passwords to passkeys is a big change in the entire security model of the modern user-facing internet. We shouldn't be at all surprised that people are both cautious and opinionated about how it should be done, how to migrate users, and how to deal with fallbacks.
Yes, the current situation is one that is messy and not significantly more secure than the previous status quo, but the direction of travel seems at least promising.
I wouldn't actually want my bank to overnight decide that passkeys are the way to log in, and if I use a passkey there should be no insecure fallback options. I want my bank to roll out a passkey, and figure out the infrastructure around it, probe for problems, and allow fallbacks that are equivalent to their previous systems. Similarly, I wouldn't want every passkey management implementation to instantly coalesce around one specific set of management practices and UX. I want various ideas to be tried out and see what comes out of it, even if some of those experiments are bad.
[+] [-] NelsonMinar|1 year ago|reply
I don't say this casually. I have been arguing for ending passwords for nearly 20 years now. I'm a software engineer and broadly understand a lot of security protocols. I spent hours understanding passkeys and figuring out how to use them in my environment. The core idea is great! But the usability is garbage.
I still can't use passkeys reliably. The combination of bad implementations in Windows, Chrome, 1Password, and various websites has defeated me. All passkeys do now is clutter up the one login flow that works for me (1Password form filling, as awful as that is.)
[+] [-] samcat116|1 year ago|reply
[+] [-] jbverschoor|1 year ago|reply
Was super excited, totally not anymore.
[+] [-] thefreeman|1 year ago|reply
[+] [-] fredfoo|1 year ago|reply
The end result is that it was more a standard for them more than for direct use by the little sites, and password managers getting involved only furthers that enterprise industry standard feel.
[+] [-] sneak|1 year ago|reply
The fido2 situation is really bad.
[+] [-] the_clarence|1 year ago|reply
[+] [-] EPWN3D|1 year ago|reply
I guess if you use tons of different browsers on tons of different platforms and want to work in hardware tokens, it's a pain, but most people aren't doing that.
The problems highlighted are real, but they don't rise to the level of "Passkeys aren't usable security". For users that would have otherwise not opted into 2FA at all (or don't know how to set up TOTP), passkeys are fine. I'm sure there are some warts to iron out, but they have to be evaluated within the context of the practical alternatives, not the context of the author's own personal security priorities.
[+] [-] paultopia|1 year ago|reply
[+] [-] franga2000|1 year ago|reply
- $AUTHENTICATOR is one of (browser extension, browser, OS, hardware) - $AUTHENTICATOR stores mappings ($SITE,$PUBKEY) => $PRIVKEY - $SITE can ask $AUTHENTICATOR to generate a new $PRIVKEY and give it its $PUBKEY - $SITE can ask $AUTHENTICATOR to sign a challenge with the $PRIVKEY corresponding to one of the $PUBKEYs for that $SITE - the user can pick which $PRIVKEYs are synced and which can be exported (depending on $AUTHENTICATOR capabilities)
Bonus points for adding a way to do the authentication off-device through QR codes, so $AUTHENTICATOR one one device can authenticate a session on another device (like using a phone to log into $SITE on the desktop, perhaps for the purpose of adding another authenticator there).
[+] [-] cypherpunks01|1 year ago|reply
[+] [-] jmclnx|1 year ago|reply
[+] [-] greatgib|1 year ago|reply
[+] [-] high_5|1 year ago|reply
[+] [-] mongol|1 year ago|reply