Apple Previews New Import/Export Feature To Make Passkeys More Interoperable (arstechnica.com) 29
During this week's Worldwide Developers Conference, Apple unveiled a secure import/export feature for passkeys that addresses one of their biggest limitations: lack of interoperability across platforms and credential managers. The feature, built in collaboration with the FIDO Alliance, enables encrypted, user-initiated passkey transfers between apps and systems. Ars Technica's Dan Goodin says it "provides the strongest indication yet that passkey developers are making meaningful progress in improving usability." From the report: "People own their credentials and should have the flexibility to manage them where they choose," the narrator of the Apple video says. "This gives people more control over their data and the choice of which credential manager they use." The transfer feature, which will also work with passwords and verification codes, provides an industry-standard means for apps and OSes to more securely sync these credentials.
As the video explains: "This new process is fundamentally different and more secure than traditional credential export methods, which often involve exporting an unencrypted CSV or JSON file, then manually importing it into another app. The transfer process is user initiated, occurs directly between participating credential manager apps and is secured by local authentication like Face ID. This transfer uses a data schema that was built in collaboration with the members of the FIDO Alliance. It standardizes the data format for passkeys, passwords, verification codes, and more data types. The system provides a secure mechanism to move the data between apps. No insecure files are created on disk, eliminating the risk of credential leaks from exported files. It's a modern, secure way to move credentials."
As the video explains: "This new process is fundamentally different and more secure than traditional credential export methods, which often involve exporting an unencrypted CSV or JSON file, then manually importing it into another app. The transfer process is user initiated, occurs directly between participating credential manager apps and is secured by local authentication like Face ID. This transfer uses a data schema that was built in collaboration with the members of the FIDO Alliance. It standardizes the data format for passkeys, passwords, verification codes, and more data types. The system provides a secure mechanism to move the data between apps. No insecure files are created on disk, eliminating the risk of credential leaks from exported files. It's a modern, secure way to move credentials."
self defeating? (Score:3)
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
If your IT department isn't competent enough work with FIDO, then it probably has even more deeply rooted issues.
Where I work, we use it on basically everything that can use it. And for what can't, we typically come up with our own way of making it work. I'm personally involved in the development of a lot of that.
And more on point, Apple is the biggest turd when it comes to supporting FIDO. They basically don't support it at all for logging into apple devices of any variety (not even PIN backed, where Windo
Re: (Score:1)
Re: (Score:2)
That boat sailed years ago, people have been synchronizing passwords between devices for a long time. It's overall better for security because the alternative is that people just use the same password for everything, and one hack nets potentially millions of accounts across hundreds of websites. The only mitigation is annoying stuff like forced 2FA where they sent you a code by email or SMS, both crap solutions but the only universal ones.
Passkeys are far, far better. They take the hassle out of it for the
Re: (Score:2)
Re: (Score:2)
Passkeys are a superset of FIDO2, which is more likely what you're referring to. And if you're relying on just one, that's part of your problem.
I personally have three FIDO keys: One that's always connected to my desktop machine, one card in my wallet, and one on my keyring. All three of them require a PIN. If I ever lost my keys and my wallet at the same time, I've always got the other one back home.
They're a lot nicer than the stupid 2FA shit a lot of companies use. No fucking texts or emails, a hell of a
Re: (Score:2)
Passkeys are account bound, not device bound.
The user could already be tricked into giving up his account password, this has about the same consequences.
Mac User. #donotwant iCloud keychain (Score:2)
As of today, there's no reasonable way to use passkeys on your choice of browser on macOS without enabling iCloud keychain, which I am not going to do.
I can use my Yubikey as 2FA, but not as a passkey without involving Apple's cloud.
Nope.
Another way Passkeys fail.
Re: (Score:2)
I was confused by this when they announced it, because I couldn't think of any reason why you'd want cloud sync for device keys. And it turns out, you don't.
Apple uses "sync passkeys", not device-bound passkeys, and uses iCloud to distribute them to your other iThingies (but of course not other platforms).
I won't use them either, for the same reason. I refuse to sync authentication creds - I will not store them on something I don't control. And even i
Re: (Score:2)
That's mostly because Apple fucking sucks. I outlined it a few posts up, but basically they go out of their way to make FIDO useless on their platforms in general, and then they make passkeys effectively pointless by requiring them to be transferable to icloud. Which, the fact that they can be stolen aside, doesn't even permit you to have hardware attestation.
What about backups? (Score:2)
After having a 2FA authenticator corrupt its database, then sync the corrupted stuff, rendering it all useless. (Thank $DEITY, I had an offline device that I used to go account by account and change to a new one, which is a lot easier than finding the recovery key info), I like being able to dump to plain text backups, and store them offline somewhere like burned to DVD or CD. This way, recovering all my passwords and 2FA is just putting a CD in, copying from that.
Hopefully the ability to export PassKeys
Re: (Score:2)
Re: (Score:2)
That's a solution looking for a problem, or more for creating a problem. It's a very common use case for people who want to stay sane enough while trying to unnecessarily shoehorn Yubikeys in their workflows, but these really aren't made to just keep a regular secret symmetrical encryption key to your backups or password manager. You CAN use some feature to achieve that but it's pointless as the host machine sees the secret data and is doi
Re: (Score:2)
YOU can't multiply passkeys, Apple can (potentially even without having access to it themselves). YOU can't backup passkeys. Apple can (though if you want last ditch account recovery without a trusted device, not with ADP turned on).
Re: (Score:2)
You can't multiply THESE (Apple) passkeys, but otherwise nothing stops you, they're just some certificates, or if you want some large numbers. There are plenty password managers that handle (completely, as in presenting them to web sites, etc.) passkeys on your machine, under your control. I presume the GP has such control as he says specifically the passkeys are backed up already in a flat text file.
Re: (Score:1)
Why?
You signup with a username and a password, then create a passkey between the site and your device.
Put the password in your password manager.
If you lose the passkey on one device, you do the exact same thing to recover as you do to add a second device with passkey.
That is to say, use the password. That's what it is there for.
Passkeys are so you don't have to remember or type a password, so you are free to make it long and random and most important unique, then shove it into a password manager for safe k
Just passwords (Score:2)
Its like they are basically passwords again. Oh but no you dont type these passwords in, you have the password generate a new password and its super secure.
Does this mean that they can be stolen now? (Score:2)
Or am I mssing something Applish?
Re: (Score:2)
From the moment Apple heard of them, they made the possibility of them being stolen a hard requirement. If they can't be stored on icloud, then your iTurd can't use them. Period.
Re: (Score:2)
They go from one attested secure domain to another attested secure domain, there is never a secret outside the secure domain. So no, not really.
"own" (Score:2)
You're allowed to pass them from one third party controlled escrow to another third party controlled escrow ... that's not ownership.
Apps maybe, Systems no (Score:2)
The whole point of passkeys is they are system dependent, identifying not just the user but also the device for login, and should not be moved from system to system.
That said it would be nice to have passkeys work with multiple apps, but they should be limited to a group of common apps, e.g. Amazon's passkey should also work with the Prime Video app, but should be unique and distinct from the passkey used for Netflix.
These aren't passwords. I think Apple completely missed the point and are bringing the bigg
Re: (Score:2)
Secure domains could already implement U2F, the whole reason to be of passkeys is syncing.
Re: (Score:2)
I think each app creates a separate passkey, so they identify the device and the account. That's a problem when the device disappears: There's no way to recover the account, or connect the account to a new device. It is why CXP and CXF were created to transfer passkeys. This turns passkeys into passwords that the user never sees. This might remove one problem: Users stupidly giving their password to a unknown person. Although, since there is (now) a method for copying the passkey, scammers may be abl