5 ms·
> Passkeys work in Apple’s Safari web browser as well as on its devices. I sure wish apple would be a little bit better of a citizen when it comes to interoper
by hayst4ck 4y ago
> Passkeys work in Apple’s Safari web browser as well as on its devices.
I sure wish apple would be a little bit better of a citizen when it comes to interoperability. Safari only features (which is what I'm assuming this will be based on apples history and the quote) are upsetting. uBlock is the single most important piece of software on my computer and my devotion to it exceeds any and all possible other features.
I would very much like to stop moving from password manager to password manager after they take VC money to corrupt their trust model so they can make money.
From the article:
> Because Apple developed its passkeys based on the FIDO Alliance standards, the passkeys can work across devices and on the web. If you try to log in to one of your accounts on a Windows machine, you’ll have to use a slightly different method since your passkeys won’t be stored on that machine. (If they are saved in an external password manager, you would need to log in to that first).
> Instead, when you log in to a website in Google Chrome, for example, you will have to use a QR code and your iPhone to help you sign in. The QR code contains a URL that includes single-use encryption keys. Once scanned, your phone and the computer are able to communicate using an end-to-end encrypted network via Bluetooth and share information.
I suppose that's not the worst workaround, and the local exchange is pretty clever, but it sure would be nice if this would work with Firefox out of the box.
- asplake 4y agoWhat is Apple doing wrong here? Surely it’s a case of Apple being first to implement a standard where other vendors – Firefox included – are expected to follow? I don’t know what it means for the password managers, but I don't see that it stops you using those either.
- hayst4ck 4y agoI want to use my iCloud keychain as a password manager since the level of trust I've already given apple allows them to acquire most of my passwords (and 2 factor codes) anyway. Safari integrates with it, but there is no Firefox or chrome plugin to do domain based validation or to keep my clipboard sane. Apple has either failed to allow uBlock to function in safari (after which I would consider migrating to safari), failed to write the Firefox integration plugin, or failed to create an API that would allow a third party to build a plugin. While apple can certainly choose to do/not do those things, it is not a happy customer experience.
- 4ad 4y ago> there is no Firefox or chrome plugin to do domain based validation or to keep my clipboard sane. That's Chrome's and Firefox' fault for not using the password autofill APIs: https://developer.apple.com/documentation/security/password_autofill/ https://developer.apple.com/documentation/security/password_... Chrome issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1170065 https://bugs.chromium.org/p/chromium/issues/detail?id=117006... Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1650212 https://bugzilla.mozilla.org/show_bug.cgi?id=1650212 Btw, Chrome used to be able to read from Apple Keychain, but they removed that functionality years ago.
- deleted 4y ago[deleted]
- Grimburger 4y ago> I would very much like to stop moving from password manager to password manager after they take VC money to corrupt their trust model so they can make money. Use the free and open source one?
- herbst 4y agoGoogle recently asked me to connect via Bluetooth to authorize my laptop with my phone. Just that Bluetooth was completely disabled from my laptop and it did not offer any other option. For some reason the login on Gmail still offered the 'press ok on your phone' method. No idea what I should have done otherwise.
- cm2187 4y agoThat would make it impossible to login to anything personal through a locked down device, like a corporate computer. I like the SQRL approach better where the QR code you scan is a url that the phone will connect to directly to do challenge response. That works with any existing browser and computer, whatever the OS or level of locking. [edit] reading other comments, I realised it is necessary to prevent a mitm attack, the iphone needs to have a way somehow to verify the domain from which the QR code has been served.
- cm2187 4y agoBut can the private key be exported or can I login only with the help from my Apple™ iPhone? What they describe isn't interoperability, it is 2FA using a phone. Interoperability means they implement a standard and I could migrate my key to an android phone. Is it the case?
- WorldMaker 4y agoIt's based on Webauthn and other FIDO standards. Private keys can't be exported (because it would defeat some of the features of a "secure enclave"), but other keys can be added to keychains. You should be able to migrate between devices/device-types across the Webauthn and FIDO standards. It's still early days that some of that isn't easy or "complete" yet, but the standards are being built and Apple and Google and Microsoft have all agreed to cooperate on them.
- cm2187 4y agoI am not sure I understand the nuance between exporting a key and migrating the key between devices. Surely if you can do one you can do the other (at least technically/in term of security).
- WorldMaker 4y agoI don't currently know the specifics of the standards, but often key migration means signing and publicly announcing a new device's hardware public key and optionally revoking an older device's hardware public key. The private keys themselves might never leave the hardware secure enclaves (and/or other key escrow services) to do the dance of updating a keychain of public key signatures. The big "advances" in the standards over the last few years have been about moving away from the "classic" PGP/CA style PKI assumption that a user is represented by a single strong key and a hierarchy of owned subkeys and more that a user is represented by a keychain of N keys many more roughly "peers" than hierarchical and in something of a web of trust with each other where N is at least the number of devices the user owns and regularly uses, and often much more than that with various key escrow strategies. I believe the "PassKey" approach uses an escrowed sub-key per-website in many cases so the keychain gets conceptually huge. (Escrowed here is that it is a derived key using data available to some quorum of physical device keys. You can rederive escrowed keys, but you can't export physical device keys that made the escrow data in the first place. You should be able to add new device keys that can share in a quorum to get at that data, but it's a migration dance.) To my knowledge Keybase's breakdowns of how their keychain worked, including subkey escrow and key exchanges are still some of the easiest to read on the subject of how the math works, though I don't think Keybase's "standards" entirely resemble some of the details of the final standards from FIDO, but again I also don't know enough of the specifics of FIDO's standards as I'd like.
- deleted 4y ago[deleted]