New Passkey Specifications Will Let Users Import and Export Them (9to5mac.com) 29
9to5Mac's Filipe Esposito reports: Passkeys were introduced two years ago, and they replace traditional passwords with more secure authentication using a security key or biometrics. To make the technology even better, the FIDO Alliance published on Monday new specifications for passkeys, which ensure a way to let users import and export them. Currently, there's no secure way to move passkeys between different password managers. For example, if you've stored a specific passkey in Apple's Passwords app, you can't simply move it to 1Password, or vice versa. But that will change soon.
As just announced by the FIDO Alliance, the new specifications aim to promote user choice by offering a way to import and export passkeys. The draft of the new specifications establishes the Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF) formats for transferring not only passkeys, but other types of credentials will also be supported. The new formats are encrypted, which ensures that credentials remain secure during the process. For comparison, most password managers currently rely on CSV files to import and export credentials, which is much less secure.
As just announced by the FIDO Alliance, the new specifications aim to promote user choice by offering a way to import and export passkeys. The draft of the new specifications establishes the Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF) formats for transferring not only passkeys, but other types of credentials will also be supported. The new formats are encrypted, which ensures that credentials remain secure during the process. For comparison, most password managers currently rely on CSV files to import and export credentials, which is much less secure.
Good and bad (Score:5, Insightful)
The inability to copy passkeys was originally touted as a benefit. Unfortunately that means, there always needs to be less secure means of authentication because hardware-based authentication must be replaced, sooner or later. This fixes that problem, returning us to all the old problems with authentication technology.
We've had TOTP for 12 years, why did it take so long to make a necessary and much-needed inter-change standard?
Re:Good and bad (Score:5, Informative)
TOTP, as in Google Authenticator does have the ability to do backups, as it is just a shared secret. Most PW managers allow easy export and backups of that.
PassKeys, on the other hand, are public/private keys. Unlike TOTP, where the hashing is symmetric, the security with PassKeys is public key. It also is highly resistant against phishing attempts [apple.com]. Normally they are bound to devices and can't get backed up. However, some apps like 1Password can back those up and allow them to work on different hardware.
Overall, being able to back up PassKeys is a good one. Less need of dealing with recovery stuff.
Re: (Score:3)
What could possibly go wrong indeed?
Re: (Score:2)
I'm just waiting for a hole in one of the passkey databases to see the world burn.
Every database used to store authentication data is a risk. The smaller the database is the smaller the consequences. If there's a breach of 1Password I'd expect a disaster. If my password file is broken I'd get some headache and might lose some files.
Re: (Score:2)
I'm just waiting for a hole in one of the passkey databases to see the world burn.
I suspect that's part of the justification for the original design discouraging transfer/use of passkeys on multiple devices. IE: let's not repeat the mistakes of past and store what is essentially the cleartext secret on the server side (password manager, or passkeys implementations like Google's and MS Windows Hello).
On the plus side, individual sites would only be storing the public key part, and there is no harm in that getting out in the wild.
Every database used to store authentication data is a risk.
Sort of. Everything that is storing user credentials/secrets
Re: (Score:2)
Overall, being able to back up PassKeys is a good one. Less need of dealing with recovery stuff.
If it can be exported intentionally, it can be exported unintentionally (stolen).
If it can be stolen, it will be stolen.
The better solution is to establish different passkeys on different hardware for the same user. Rather than having backup copies of the key, you have backup access via a different device.
Re: (Score:2)
Re: (Score:2)
with the newer SSH, can also do resident private keys for SSH access.
Re: (Score:2, Informative)
The inability to copy passkeys was originally touted as a benefit.
A touted promise that is, at this level, difficult to guarantee.
Passkeys slot in at the same level as session cookies, but being public/private key based instead of shared secret, that gave the optional benefit of secure private key management.
Options are good. It's the promise that option is always available that is bad.
PC 1 has a proper TPM chip that can store such keys, but PC 2 a year older with the same model number has an older TPM (or none) so falls back on some software solution that stores data on
Re:Good and bad (Score:4, Insightful)
Being able to copy Passkeys was touted as a feature from day one. They would sync accross devices, i.e. be copied.
The advantages were never anything to do with not being copyable. They were things like not working with phishing sites (because they are tied to a specific domain), and being much more difficult to crack than the average user's password.
Re: Good and bad (Score:2)
TOTP always had interchange via the original mechanisms (qr code or encoded string), even if apparently Google did not support them initially.
My take is that passkeys suffer from lack of adoption.
Re: (Score:2)
> there always needs to be less secure means of authentication because hardware-based authentication must be replaced, sooner or later.
Thats not the case; there is a much better approach which doesnt require a security compromise: spare passkeys pre-configured as fallbacks apriori.
Google already implements this by requiring 2 passkeys when you enable their highest security settings. One is the active/primary, and the other serves as a backup in case your primary passkey gets lost or destroyed. So you can
Re: (Score:2)
The issue with passkeys isn't that you can't copy them. It's that you can't usually store multiple. This is a non-issue if every 2FA site has the ability store multiple second factors and multiple of each type.
Less Secure (Score:3)
I was trying to come up with a joke, but I got nothin funnier than that titan of an understatement.
Re: (Score:2)
...or alternatively in raw SQL";DROP TABLE passkeys;
Re: (Score:3)
For a password manager not running in a secure enclave, it's not much less secure. Okay, you could leave a copy in a cloud email archive, but what's more likely to get hacked? Your PC or a cloud provider?
It's like all the blowhard accusations of disastrously poor safety when software doesn't encrypt stuff at rest even though it doesn't use its own password to start, often leveled at Firefox ... what's the bloody point if the decryption key is right there too?
Re: Less Secure (Score:2)
Indeed. On both counts.
Re: (Score:2)
You can have Firefox encrypt everything at rest and require a password to unlock. It's just a setting you have to turn on.
Now maybe Apple will quit badgering me... (Score:2)
...to turn on iCloud keychain, which i #donotwant
Re: (Score:1)
Any password manager will sync your Passkeys. iCloud does it, using a password manager is a must, if you don't have one, iOS will keep badgering you to get one, that is good.
Re: Now maybe Apple will quit badgering me... (Score:2)
I have a password manager I'm really happy with. Have had it for probably over a decade. 2FA, robust encryption, multiplatform, open source.
That doesn't stop the endless prompts from macOS that I need to enable iCloud keychain to set passkeys.
Re: (Score:1)
You can set your other password manager as the Passkeys manager in iOS/macOS and it will stop badgering you (somewhere in settings).
Re: Now maybe Apple will quit badgering me... (Score:2)
Interesting. Thanks, I'll check it out!
Re: (Score:2)
Yeah, no. After some looking, this is something one can do in iOS (something else I #donotwant after some experience with it), but not in macOS.
What does Apple think I want to do when I'm on Linux, Windows or Android?
What I dislike (Score:2)
I use a password manager, probably most /. people do. If I need to log into a website, I can copy/paste the password into the browser. Unless I let it, the browser does not remember or process the password in any way.
From what I'vecsern, that's not true with passkeys. They require a browser plugin, and your password manager has to hand off the passkey to the plugin. Like handing your car keys to a valet - maybe he's a stand-uo guy, and...maybe not.
It's an extra step, one more agent that has to work, and h
Re: (Score:2)
If you don't trust the browser then you are already screwed, because when you copy/paste your password in it can be snagged by malware.
Most peolpe use the browser's built in password manager, or something like Bitwarden via an add-on.
Re:What I dislike (Score:4, Informative)
They require a browser plugin, and your password manager has to hand off the passkey to the plugin.
That's not how it works, no. The browser asks the server to authenticate; the server gives it a single-use challenge, the browser passes the challenge to the password manager, which produces a response; the browser returns the response to the server. The browser never has the keys that would be necessary to respond to the passkey challenge.
Like handing your car keys to a valet - maybe he's a stand-uo guy, and...maybe not.
It's just the opposite. Every time you paste a password into a browser, you're trusting it (and the site, and any plugins with permissions) not to leak it. With passkeys that is not a concern.
export and import passkeys. (Score:2)
Maybe we could come up with a qr code that is readable by humans and they could use that with some kind of login name in place of a passkey, I would call it a password.