17 ms·

Passkeys now support external providers

271 points by jsmith99 3y ago

jsmith99 3y ago
Originally seen via https://reddit.com/r/Bitwarden/comments/141uxz1/iosipados_17_and_macos_14_will_support_3rd_party/ https://reddit.com/r/Bitwarden/comments/141uxz1/iosipados_17... This is big news as vendor lock in and inability to use our own sync was one of the biggest issues bought up whenever Passkeys are discussed. Apple are now allowing external sync fabrics such as password managers.
- devsda 3y ago
  > Apple are *now* allowing external sync There is no guarantee that this will be permanent. It can be revoked citing x number of reasons. Also, lets wait until the implementation details are available. If it requires providers having a native app on the device where Apple has control on who and what to allow, there's only an illusion of choice.
  - cassianoleal 3y ago
    Pretty sure "now" in this context means "starting now". Once people start relying on this, it will take a lot more than just citing reasons to revoke it without causing massive blowback.
    - devsda 3y ago
      I don't mean revoking 3rd party support entirely. We don't know the implementation details yet but if this requires Apple vetting and whitelisting the providers then it can always be revoked for technical, business, political or any other reasons.
      - cassianoleal 3y ago
        I would expect this to be modelled after the API for password managers, in which case there's no vetting or whitelisting. Or if there is, it's pretty open as a lot of software uses it, both closed and open source.
- Ajedi32 3y ago
  Yeah, this is awesome. The devil's in the details though, do we know anything about exactly how they plan to support external providers? I'm cautiously optimistic; at least on the surface this sounds like exactly what I was hoping for.
  - awinter-py 3y ago
    I mean apple has a tried and true playbook for supporting external providers, I'm not worried charge them random % of revenue, force them to funnel all transactions through apple, let random junior employees disable the 3rd party's bugfixes for reasons(tm), and eventually refuse to license new entrants because there are too many flashlight apps I'm not worried
  - ezfe 3y ago
    > Password manager apps can save and offer passkeys on iOS, iPadOS, and macOS. No reason to believe this would work differently than the existing affordances for 3rd party apps to offer passwords, which works well today
    - eep_social 3y ago
      So I will be able to copy-paste some string from my password manager to my browser in order to complete the passkey handshake? Or does this mean that my password manager must support my browser of choice on my platform of choice with some opaque plugin that cannot be disabled (eg, 1pw on macos today)?
      - ezfe 3y ago
        On iOS for passwords, this is a systemwide system that allows any app to register as a password provider and any password field to receive those passwords via the system keyboard. I would assume that the system passkey interface will handle the receiving app, and the sharing app will register with the system (NOT with the browser or app, although this doesn't preclude doing that as well) to vend passkeys.
- danShumway 3y ago
  I'm very eager to see what Bitwarden does here, they're the first big[0] name that's actually Open Source that's on board. It's hard to take passkeys seriously when the vast majority of implementations are completely proprietary. Seeing what Bitwarden comes up with and seeing whether or not the process for self-hosted Bitwarden accounts is actually seamless and works on platforms like desktop Linux -- to me, that's going to be a really big test of whether passkeys can credibly be claimed to be actually cross-platform. [0]: I do think there have been some smaller proof-of-concepts, but... there's a difference of scale here.
ttul 3y ago
This is a smart move by Apple. Authentication infrastructure is necessarily cross platform. It doesn’t generate revenue for Apple, but the lack of cross platform auth would limit enterprise adoption of Apple products.
- supriyo-biswas 3y ago
  Passkeys (otherwise known as WebAuthn) isn’t an Apple specific standard though.
  - ttul 3y ago
    Absolutely. 1Password is betting heavily on being the passkey clearing house for enterprise. I think what Apple is doing here is saying that companies like 1Password can do this for their flavor of WebAuthn too.
- riffraff 3y ago
  > It doesn’t generate revenue for Apple, but it creates lock-in, if all your credentials are in a iCloud keychain, you're encouraged to get a phone that can sync with your ipad, laptop, and desktop. Manually find and re-sync your stuff from firefox-on-desktop to chrome-on-mobile to safari-on-ipad is a major PITA.
  - rickdeckard 3y ago
    And it creates nicely labeled and synchronized information of when and how often a user logged into a eCommerce service/Streaming portal/..., while still being able to state that your browser history is never processed for profiling...
miles 3y ago
There is only this blurb to go on at the moment: "Passkeys can now be synced using external providers..." so it's hard to say exactly what it will mean for user control and choice. Which external providers? Will users be able to access and store their own private keys in compatible apps of their choosing? If so, aren't we largely back to passwords?
- tehbeard 3y ago
  > aren't we largely back to passwords? A password is a shared secret. Even if it's hashed on the server side, one could brute force it if a weak algorithm is used, or MiTM the service to get the plaintext when the user logs in. Passkeys / webauthn utilizes public key cryptography. I'm only ever giving them a (by the spec, unique to the combo of me and the site in question) public key to which I hold the private key pair. Authentication doesn't involve transmission of these, it's challenge based where you prove you have access to the corresponding private key.
- danShumway 3y ago
  > aren't we largely back to passwords? Key based authentication is a huge security improvement over passwords (especially for reducing phishing risks) even without the device-bound restrictions. I'm strongly opposed to hardware-bound keys as a mass standard for most users, but key based authentication is great. One big advantage is that during the login process, sites "prove" their identity to you. This is a security improvement that you could previously only really get with browser extensions and password managers, and even there it wasn't great because those extensions didn't work consistently across all sites and often failed at autofill, so a website failing to pull up your password manager might not actually be interpreted as a red flag. And there are other advantages too around account security for service providers, etc... none of which require attestation or hardware-bound keys.
- patmorgan23 3y ago
  Passkeys still involve storing a secret, which I think is fundamentally what all security/authentication is built around. Passkey eliminates a lot of the issues with passwords (transmitting the plain text to the app, password reuse, simple passwords). If you've been using a password manager with randomly generated passwords you've already addressed some of these issues so the benefits of using passkeys over passwords is reduced.
oulipo 3y ago
Interesting, but can someone tell us what this implies wrt. authorities? If someone gets your iPhone and forces you to press your finger on the TouchID, he gets all your passwords no? While with a general master password you could just pretend to have forgotten it?
- drtgh 3y ago
  Whichever way you look at it, in every sense, password managers are a really bad, bad idea. Besides that, it is not needed to force you to press your finger; the delinquent needs only to have access to the device for to fool the sensor with a brute force, 2 hours in the worse of the cases with the simplest techniques. Although its easier to take your finger prints from a glass or something you used for to avoid the wait, or directly cut your finger if its a psychopathic criminal. And in all the cases, once your fingerprint gets public it gets compromised until the end of the times, of course, you can not "change the passw". This without talking about software infection with a remote attack.
  - Lukas_Skywalker 3y ago
    I would argue that password managers are not a "in every sense a really bad, bad idea" for a lot of reasons. Let's look at password reuse for example. As soon as you have more than a few dozen logins, the possibilities are mostly either reusing one or few passwords, or writing them down. Reusing is objectively bad, and for writing them down, the password manager makes it easy to use a really long and random password, which would make it tedious to write down.
    - drtgh 3y ago
      Password managers makes the user life easier, at a big price if the master password gets compromised, as all the passwords get compromised at same time, in an unified way that by other methods would require much more specialization and effort for to gather together. If that passwords are stored in internet even worst, one can take for sure those passw-managing servers are juicy targets, it is a countdown until the server will get compromised. If the user is only storing the pass of chat forums, I think then is one thing the attacker probably will ignore, if the reverse engineering of one of those sites using user's name is not in the secondary target list. Anyway, to use a unique password for every server, account, etc is a must do from the beginning of time, even for the temporal forum one had to register for to use a few minutes. It is the first computing directive. It's just the password managers are not accomplishing the objective of such directive.
Topfi 3y ago
That's a great development. Reducing vendor lock-in removes one of the bigger reservations some mentioned in regards to WebAuthn.
- garganzol 3y ago
  The development hardly changes anything. Apple (and Google) is still a middle man and thus poses a point of failure.
francislavoie 3y ago
That's great to see! I just tried out 1Password's beta browser extension which has passkeys support, and the UX is super seamless. Played around with it on https://www.passkeys.io/ https://www.passkeys.io/ I'm really hopeful about this, a lot more than any of the previous iterations of the FIDO stuff. I worked at a company that was an early adopter/implementer of the original FIDO U2F spec, and it had major UX problems, enough that I couldn't see it ever being used by the general public (who the heck would carry a USB key with them?? and this only works with desktops/laptops, sure Bluetooth support, but ehhh), but with this, synced to your password manager of choice, that's A LOT better. The passkey is usable anywhere (signed up on my desktop, hopped over to my laptop and signed in there with the same passkey). I can't use it from my Android phone yet, but that will come soon I'm sure when 1Password adds support to the mobile apps + Google does the same as Apple here with adding proper Android integration. On Android I can still only use a USB/NFC/Bluetooth security key, or "my lock screen" (i.e. on-device security key, not passkeys) so far. If I click on "Sign in with a passkey" it says I have no passkeys via an Android system dialog, but if I sign in with my email it lets me use my "security key" (i.e. biometric lock screen prompt).
- Hamuko 3y ago
  I did a WebAuthn implementation at work and the UX for WebAuthn was fucking awful. Especially on macOS, every browser had a completely separate implementation of WebAuthn, and if you used the Touch ID as a WebAuthn device, you basically could not see it anywhere and deleting it was also a pain in the ass. On Chrome, you basically had to just delete all of your passwords for the last N days to get rid of them. On Windows, I think all browsers handled it centrally with Windows Hello, but even there the WebAuthn devices just kinda disappear into the ether once you register them, and deleting them had to be done through the command-line. There were also weird ass bugs where the UI would behave completely differently depending on whether or not you had Windows Hello login in use, so websites would need to engineer around it. Haven't played around with passkeys key, but I imagine the only direction to go is up.
  - francislavoie 3y ago
    Yeah. With 1Password it's just another item like a password, but named "passkey". And in the browser when you set it up or use it, you get a little overlay on the website in the top-right and you click on it. That's it. Super simple, no faff, full visibility.
ckastner 3y ago
Of all the recent publications with regards to passkeys, FIDO2, WebAuthn, etc., finally there's one with a simple and concise summary of the benefits: > Strong credentials. Every passkey is strong. They’re never guessable, reused, or weak. > Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers. > Safe from phishing. Passkeys are intrinsically linked with the app or website they were created for, so people can never be tricked into using their passkey to sign in to a fraudulent app or website.
- ljlolel 3y ago
  The last one is a problem for a lot of use cases. Lots of sites have different domains (also for example when HBO max renamed to max). Plaid also relies on entering bank passwords on neobank sites and is widely used.
  - gjulianm 3y ago
    AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. And for things like Plaid, I think banks are moving towards OAuth-style permissions, where you login to your bank and authorize the connection. Under the hood, Plaid or other app can connect to the bank with limited permissions using API authorization keys. It's a different problem, I think.
    - tialaramex 3y ago
      > AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. In principle the fancier systems with a user interface could add a feature where you can change the DNS names associated with a key it's storing. That sounds like a monumental pain in the backside, and of course the primary consequence would be it increases phishing because now your users can be tricked into allowing it - but sure, they could do that. For simpler devices like a Yubico Security Key, there is no such interface, they aren't storing any keys so there's no way to make such an association. The keys are bound to the DNS name and are actually stored (encrypted) by the sites you're actually authenticating to. So without a matching DNS name they're intentionally just useless nonsense.
smcleod 3y ago
Hopefully this comes to Strongbox soon!
abiro 3y ago
Any details on how passkeys sync using external providers?
xmdx 3y ago
Is the whole idea of syncing passkeys a bad idea? Or at least a less secure idea. Someone explained to me that passkeys are hardware backed, each passkey is stored on device and tied to the hardware, so even if someone managed to get access to it, they would also need the hardware to get it to work. These software based keys that can be synced are less secure as a result. Then it just becomes like a password again. I need to read up a bit more on passkeys in general tbh.
- stavros 3y ago
  It is less secure, but more convenient. You can pick either option. Or you can have both with delegation ("your husband is trying to log in as you on www.google.com, allow?").
- whatyesaid 3y ago
  I think passkeys + 2FA is enough. Just enforce 2FA for any important service and it will be fine, if you don't force it then people who aren't as tech savvy will not do it or people may forget. For anything non-important I actually use sign in with Google, so.
- WorldMaker 3y ago
  Passkeys as a brand include both hardware-backed keys that can't be exported and are device-specific. These can be used for things like 2FA/MFA-type scenarios. They also involve a lot of site-specific keys that may not be hardware-backed and syncable. The neat fun thing is that they can be synced with hardware-backed keys for strong E2E between a user's enrolled devices and only the user's enrolled devices (plus maybe a hard to use recovery key). (That's basically how iCloud's Password/Passkey store and a lot of iCloud E2E in general seems to work.) Passkeys in general, especially the focus on a lot of site-specific E2E shared ones, are very much "just like a password", but as the sibling comment points out, the switch to PKI alone is a huge security win and would stop a lot of the haveibeenpwned sorts of leaks and the overall attractiveness to crackers to break into various company's password databases, because only having a public key is a lot less useful than a salted/hashed password that might be broken or found in a rainbow table.
jiggawatts 3y ago
My method for judging the quality of software: Read the latest release notes, negate every statement, and think to yourself: "They were fine with it being like this until now." Passkeys have been advertised as a superior replacement to passwords, but really fundamental issues remain unaddressed. I have one (1) Windows PC and one (1) iDevice. Can I get these to sync? Will both be able to log me in to a Google Account? Or do I need an Android phone for that? Can I use an iDevice to authenticate with an Azure AD app? Can I recover the passkeys on a lost iDevice without having to pay Apple for a new device to restore the backup? Etc... I guarantee many more release notes that could be summarised as: "Now supports a common scenario!"
- rickdeckard 3y ago
  > I have one (1) Windows PC and one (1) iDevice. Can I get these to sync? "Why? Where's the profit for us in that case?"
- echeese 3y ago
  > I have one (1) Windows PC and one (1) iDevice. Can I get these to sync? Or do I need an Android phone for that? Yes. In Chromium-based browsers, at least. Your browser will display a QR code which you scan with your phone. Your phone will display a list of accounts you can sign in with, you select one, authenticate, and you're logged in. Firefox support isn't here yet.
  - jiggawatts 3y ago
    That's not what I mean by "sync". If I don't have the phone with me, I can't authenticate. Also, I use Firefox exclusively. This is precisely what I mean: common scenarios are not yet supported.
    - sbuk 3y ago
      You’re somewhat missing the point of what passkeys are. Instead of the something you know part, i.e. a password, the authentication is done by something you have. Your common use case is only common to single factor password authentication. It’s not a situation that is allowed for in passkey’s security model.
garganzol 3y ago
I'm totally in if passkeys come without middle men, especially like Google and Apple. Otherwise I'm totally out. No trust in these guys, they are as capricious as Roman emperors and will eventually do their usual stuff: lock in and collusion.
- yomlica8 3y ago
  I've got a big problem with the attestation feature even existing in the spec. I know Apple plans to "zero it out" but if that changed sites could lock out non approved devices. I'd vastly prefer it wasn't part of the spec at all rather than relying upon the whims of a single megacorporation. If they ever drop that cover things will gradually become defacto locked to middlemen anyway.
  - garganzol 3y ago
    Exactly. Middle men are not needed. Passkeys can and should be handled by an open specification. In this way, passkeys will be decentralized and can be supported by anyone and everywhere. Users should decide by themselves where they want to store the authenticator: be it a separate device or a password manager running on their computer. Authenticator is just an algorithm that uses key material from elsewhere (biometrics, master password, whatever user prefers) to perform the authentication. Tying the whole thing to a couple of corps is cringy and creepy at the same time. There must be an open standard where everyone can participate.
  - danShumway 3y ago
    This is a great point. I'm really happy about Apple's plans, but I have a hard time taking it at face value that there's nothing to worry about here if there's resistance to putting that plan into the spec itself. Because I start to get suspicious any time a company says, "we're not going to do X, but we absolutely refuse to commit in any meaningful way to not doing X." There's an implication there. I feel the same way about syncing, honestly: "Everyone is going to support 3rd-pary sync." "Can we put it in the spec that they have to?" "Well, that would be overreaching..." I think there are a lot of people who have genuinely good intentions, but it still makes me pretty nervous. If we could just trust every company to magically work things out and be compatible with everyone, we wouldn't need industry specifications in the first place. I think it's appropriate to try and standardize the baseline mechanisms users should have to control their keys and preserve their privacy.
dethos 3y ago
Good news. Lock-in was one of the biggest issues with passkeys. I think we will see a bunch of well known password managers adding passkey support soon. Is there any standard for this integration/interoperability? What about moving from one provider/app to another?
- ndjdhdidve 3y ago
  you fell for it. the article says nothing to that end. still full locked in. the UI will allow implementations... via app stores approved apps using their OS apis. for sure.
vouaobrasil 3y ago
So far, no one has commented on this large downside of passkeys: that it will promote the ease of sites to require login since it's much easier to generate a passkey than to remember a new password or even store it. Thus, passkeys lubricate the path towards an ever-increasing login-based society where it becomes much easier to track and monitor your online behaviour. Although it has the benefit of making our existing lives easier by removing the need to remember our banking passwords, it also will bring us further into the realm of technology by making more and more services log-in based. A greater ease of making a log-in based service means more revenue, more profit for Apple, and a greater integration of technology into our lives. Few people realize this because we have been conditioned to believe that new technology is solely for our benefit. In reality, Apple is not concerned with our benefit. They are concerned with profit and making technology more efficient to accomplish that end. So although passkeys might seem nice, there is a serious downside to this technology.
- rickdeckard 3y ago
  It's also a convenient workaround to synchronize information about your online-behavior, while still being able to state publicly that your browser-history is never processed to profile you. Upvoting this because it's a view worth sharing (and I'm sure you'll be downvoted just because of your baseless claim that Apple is concerned about something as dirty as profit /s)
  - theshrike79 3y ago
    Apple is making filthy amounts of money just from hardware and app sales. All of their attempts at targeted advertising have been rounding errors at best. And they know that complete unbreakable privacy is the place where Google (an ad company) can never ever fully follow no matter what kind of lip service they do in their keynotes about privacy.
    - clairity 3y ago
      all of apple's recent growth is coming from its content ("services") business, which means it's hot to track you for advertising purposes. passkeys provide another stone in their walled garden to be able to track you but keep others from doing so as effectively, which on balance contributes to its competitive advantage. make no mistake that this is the direction apple is headed. it's been clear for the last 5 years or so, since hardware sales have leveled off. perhaps the goggles will dampen the velocity a bit, but i'm very skeptical that the AR/VR market is mature enough to have that effect in the near future.
ndjdhdidve 3y ago
1. article says nothing about external identity providers. which is what everyone here wants. still fully locked in. 2. it only hints at the UI being open to other apps, approved in the app store of course, using their new undocumented api 3. the sharing features will probably happens over their central control. not over the UI implementers. so many misconceptions in these comments. specially mixing up passkeys with in device keys
- zamadatix 3y ago
  It starts out saying "Passkeys can now be synced using external providers", how does it say nothing about external providers? I'd love to see the detail as well but, lacking that, there is nothing in the article that says these takes are correct and the others misconceptions either.
spuz 3y ago
One thing I don't understand about offering passkey login for your email is how you would go about recovering an account if you lost access to the device which holds your passkey? Google states: "When you create a passkey, you opt in to a passkey-first, password-less sign-in experience.". This seems to imply that you will not be able to use your old password if you ever lost your phone. Do Google still offer backup passwords for recovery purposes if you switch to passkeys? Their site doesn't seem to explain this. https://support.google.com/accounts/answer/13548313?hl=en#zippy=%2Clost-or-stolen-device%2Cmissing-or-unavailable-passkey https://support.google.com/accounts/answer/13548313?hl=en#zi...
- deleted 3y ago
  [deleted]
- Ajedi32 3y ago
  Think of passkeys as being the same as a password database. The provider can offer whatever recovery mechanism they want, and sites that use passkeys can continue to offer account recovery methods completely independent of their use of passkeys. As for what Google does specifically with their implementation, I'm not sure. I personally plan to use KeepassXC's implementation, whenever that comes out, with my own custom database backup strategy.
  - snagg 3y ago
    This is an area with the specs contrast with the vendors. The WebAuthn specs recommends to register multiple passkeys/credentials per device and assume that once a credential is lost it might not be recoverable. Apple and other vendors using keychains/wallets are effectively offering the option to delegate the recovery of the passkey to the recovery of the account with them (eg: the iCloud account). In case it is of interest, we wrote a long blogpost on the topic: https://www.slashid.dev/blog/passkeys-security-implementation/#how-are-credentials-shared-and-stored https://www.slashid.dev/blog/passkeys-security-implementatio...
    - deleted 3y ago
      [deleted]
danShumway 3y ago
I still want to see more details. That being said, extremely positive news. Vendor lock-in is one of the biggest issues with passkeys and one of the biggest reasons I haven't been able to get on board with them and why I usually end up advocating against them whenever they come up. Between this and Apple blocking attestation efforts for mobile passkeys, it gives me more confidence that this could turn into a standard that I want to use. I criticize the passkey standard pretty consistently, I would be very happy to eat crow on that. I will say that it would go a long way to make this stuff part of the standard, I don't like how much these really critical pieces of passkey functionality are boiling down to "wait and see what vendors do." But I'm cautiously optimistic to see where things go. It is a really big deal for Apple to support 3rd-party providers and an even bigger deal for Apple to support sync with 3rd-party providers.
anderspitman 3y ago
My main concern with passkeys is I'm not aware of a way to pre-authorize someone who doesn't yet have an account. For example, with email I can just grant X access to anyone who can prove they have access to Y email address. But passkeys don't have a single public handle like this. This isn't such a big deal with centralized services where everyone is likely to already have an account, but might pose a problem for selfhosted services. Still, I like passkeys and wish there was a way to have my cake and eat it too.
mistrial9 3y ago
next headline -- Passkeys now require external providers update this dev news announcement actually opens the setup a bit more, instead of close it down a bit more. However the whole Apple walled garden and always-on networking is not a happy thing from this desk
botanical 3y ago
Until I can export a passkey to KeePassXC I won't use it. How do you recover your account if you're locked out? Or if Google decides to ban you?

271 points by jsmith99 3y ago

Originally seen via https://reddit.com/r/Bitwarden/comments/141uxz1/iosipados_17_and_macos_14_will_support_3rd_party/ https://reddit.com/r/Bitwarden/comments/141uxz1/iosipados_17... This is big news as vendor lock in and inability to use our own sync was one of the biggest issues bought up whenever Passkeys are discussed. Apple are now allowing external sync fabrics such as password managers.

devsda 3y ago
> Apple are *now* allowing external sync There is no guarantee that this will be permanent. It can be revoked citing x number of reasons. Also, lets wait until the implementation details are available. If it requires providers having a native app on the device where Apple has control on who and what to allow, there's only an illusion of choice.
- cassianoleal 3y ago
  Pretty sure "now" in this context means "starting now". Once people start relying on this, it will take a lot more than just citing reasons to revoke it without causing massive blowback.
  - devsda 3y ago
    I don't mean revoking 3rd party support entirely. We don't know the implementation details yet but if this requires Apple vetting and whitelisting the providers then it can always be revoked for technical, business, political or any other reasons.
    - cassianoleal 3y ago
      I would expect this to be modelled after the API for password managers, in which case there's no vetting or whitelisting. Or if there is, it's pretty open as a lot of software uses it, both closed and open source.
Ajedi32 3y ago
Yeah, this is awesome. The devil's in the details though, do we know anything about exactly how they plan to support external providers? I'm cautiously optimistic; at least on the surface this sounds like exactly what I was hoping for.
- awinter-py 3y ago
  I mean apple has a tried and true playbook for supporting external providers, I'm not worried charge them random % of revenue, force them to funnel all transactions through apple, let random junior employees disable the 3rd party's bugfixes for reasons(tm), and eventually refuse to license new entrants because there are too many flashlight apps I'm not worried
- ezfe 3y ago
  > Password manager apps can save and offer passkeys on iOS, iPadOS, and macOS. No reason to believe this would work differently than the existing affordances for 3rd party apps to offer passwords, which works well today
  - eep_social 3y ago
    So I will be able to copy-paste some string from my password manager to my browser in order to complete the passkey handshake? Or does this mean that my password manager must support my browser of choice on my platform of choice with some opaque plugin that cannot be disabled (eg, 1pw on macos today)?
    - ezfe 3y ago
      On iOS for passwords, this is a systemwide system that allows any app to register as a password provider and any password field to receive those passwords via the system keyboard. I would assume that the system passkey interface will handle the receiving app, and the sharing app will register with the system (NOT with the browser or app, although this doesn't preclude doing that as well) to vend passkeys.
danShumway 3y ago
I'm very eager to see what Bitwarden does here, they're the first big[0] name that's actually Open Source that's on board. It's hard to take passkeys seriously when the vast majority of implementations are completely proprietary. Seeing what Bitwarden comes up with and seeing whether or not the process for self-hosted Bitwarden accounts is actually seamless and works on platforms like desktop Linux -- to me, that's going to be a really big test of whether passkeys can credibly be claimed to be actually cross-platform. [0]: I do think there have been some smaller proof-of-concepts, but... there's a difference of scale here.

ttul 3y ago

This is a smart move by Apple. Authentication infrastructure is necessarily cross platform. It doesn’t generate revenue for Apple, but the lack of cross platform auth would limit enterprise adoption of Apple products.

supriyo-biswas 3y ago
Passkeys (otherwise known as WebAuthn) isn’t an Apple specific standard though.
- ttul 3y ago
  Absolutely. 1Password is betting heavily on being the passkey clearing house for enterprise. I think what Apple is doing here is saying that companies like 1Password can do this for their flavor of WebAuthn too.
riffraff 3y ago
> It doesn’t generate revenue for Apple, but it creates lock-in, if all your credentials are in a iCloud keychain, you're encouraged to get a phone that can sync with your ipad, laptop, and desktop. Manually find and re-sync your stuff from firefox-on-desktop to chrome-on-mobile to safari-on-ipad is a major PITA.
- rickdeckard 3y ago
  And it creates nicely labeled and synchronized information of when and how often a user logged into a eCommerce service/Streaming portal/..., while still being able to state that your browser history is never processed for profiling...

miles 3y ago

There is only this blurb to go on at the moment: "Passkeys can now be synced using external providers..." so it's hard to say exactly what it will mean for user control and choice. Which external providers? Will users be able to access and store their own private keys in compatible apps of their choosing? If so, aren't we largely back to passwords?

tehbeard 3y ago
> aren't we largely back to passwords? A password is a shared secret. Even if it's hashed on the server side, one could brute force it if a weak algorithm is used, or MiTM the service to get the plaintext when the user logs in. Passkeys / webauthn utilizes public key cryptography. I'm only ever giving them a (by the spec, unique to the combo of me and the site in question) public key to which I hold the private key pair. Authentication doesn't involve transmission of these, it's challenge based where you prove you have access to the corresponding private key.
danShumway 3y ago
> aren't we largely back to passwords? Key based authentication is a huge security improvement over passwords (especially for reducing phishing risks) even without the device-bound restrictions. I'm strongly opposed to hardware-bound keys as a mass standard for most users, but key based authentication is great. One big advantage is that during the login process, sites "prove" their identity to you. This is a security improvement that you could previously only really get with browser extensions and password managers, and even there it wasn't great because those extensions didn't work consistently across all sites and often failed at autofill, so a website failing to pull up your password manager might not actually be interpreted as a red flag. And there are other advantages too around account security for service providers, etc... none of which require attestation or hardware-bound keys.
patmorgan23 3y ago
Passkeys still involve storing a secret, which I think is fundamentally what all security/authentication is built around. Passkey eliminates a lot of the issues with passwords (transmitting the plain text to the app, password reuse, simple passwords). If you've been using a password manager with randomly generated passwords you've already addressed some of these issues so the benefits of using passkeys over passwords is reduced.

oulipo 3y ago

Interesting, but can someone tell us what this implies wrt. authorities? If someone gets your iPhone and forces you to press your finger on the TouchID, he gets all your passwords no? While with a general master password you could just pretend to have forgotten it?

drtgh 3y ago
Whichever way you look at it, in every sense, password managers are a really bad, bad idea. Besides that, it is not needed to force you to press your finger; the delinquent needs only to have access to the device for to fool the sensor with a brute force, 2 hours in the worse of the cases with the simplest techniques. Although its easier to take your finger prints from a glass or something you used for to avoid the wait, or directly cut your finger if its a psychopathic criminal. And in all the cases, once your fingerprint gets public it gets compromised until the end of the times, of course, you can not "change the passw". This without talking about software infection with a remote attack.
- Lukas_Skywalker 3y ago
  I would argue that password managers are not a "in every sense a really bad, bad idea" for a lot of reasons. Let's look at password reuse for example. As soon as you have more than a few dozen logins, the possibilities are mostly either reusing one or few passwords, or writing them down. Reusing is objectively bad, and for writing them down, the password manager makes it easy to use a really long and random password, which would make it tedious to write down.
  - drtgh 3y ago
    Password managers makes the user life easier, at a big price if the master password gets compromised, as all the passwords get compromised at same time, in an unified way that by other methods would require much more specialization and effort for to gather together. If that passwords are stored in internet even worst, one can take for sure those passw-managing servers are juicy targets, it is a countdown until the server will get compromised. If the user is only storing the pass of chat forums, I think then is one thing the attacker probably will ignore, if the reverse engineering of one of those sites using user's name is not in the secondary target list. Anyway, to use a unique password for every server, account, etc is a must do from the beginning of time, even for the temporal forum one had to register for to use a few minutes. It is the first computing directive. It's just the password managers are not accomplishing the objective of such directive.

Topfi 3y ago

That's a great development. Reducing vendor lock-in removes one of the bigger reservations some mentioned in regards to WebAuthn.

garganzol 3y ago
The development hardly changes anything. Apple (and Google) is still a middle man and thus poses a point of failure.

francislavoie 3y ago

That's great to see! I just tried out 1Password's beta browser extension which has passkeys support, and the UX is super seamless. Played around with it on https://www.passkeys.io/ https://www.passkeys.io/ I'm really hopeful about this, a lot more than any of the previous iterations of the FIDO stuff. I worked at a company that was an early adopter/implementer of the original FIDO U2F spec, and it had major UX problems, enough that I couldn't see it ever being used by the general public (who the heck would carry a USB key with them?? and this only works with desktops/laptops, sure Bluetooth support, but ehhh), but with this, synced to your password manager of choice, that's A LOT better. The passkey is usable anywhere (signed up on my desktop, hopped over to my laptop and signed in there with the same passkey). I can't use it from my Android phone yet, but that will come soon I'm sure when 1Password adds support to the mobile apps + Google does the same as Apple here with adding proper Android integration. On Android I can still only use a USB/NFC/Bluetooth security key, or "my lock screen" (i.e. on-device security key, not passkeys) so far. If I click on "Sign in with a passkey" it says I have no passkeys via an Android system dialog, but if I sign in with my email it lets me use my "security key" (i.e. biometric lock screen prompt).

Hamuko 3y ago
I did a WebAuthn implementation at work and the UX for WebAuthn was fucking awful. Especially on macOS, every browser had a completely separate implementation of WebAuthn, and if you used the Touch ID as a WebAuthn device, you basically could not see it anywhere and deleting it was also a pain in the ass. On Chrome, you basically had to just delete all of your passwords for the last N days to get rid of them. On Windows, I think all browsers handled it centrally with Windows Hello, but even there the WebAuthn devices just kinda disappear into the ether once you register them, and deleting them had to be done through the command-line. There were also weird ass bugs where the UI would behave completely differently depending on whether or not you had Windows Hello login in use, so websites would need to engineer around it. Haven't played around with passkeys key, but I imagine the only direction to go is up.
- francislavoie 3y ago
  Yeah. With 1Password it's just another item like a password, but named "passkey". And in the browser when you set it up or use it, you get a little overlay on the website in the top-right and you click on it. That's it. Super simple, no faff, full visibility.

ckastner 3y ago

Of all the recent publications with regards to passkeys, FIDO2, WebAuthn, etc., finally there's one with a simple and concise summary of the benefits: > Strong credentials. Every passkey is strong. They’re never guessable, reused, or weak. > Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers. > Safe from phishing. Passkeys are intrinsically linked with the app or website they were created for, so people can never be tricked into using their passkey to sign in to a fraudulent app or website.

ljlolel 3y ago
The last one is a problem for a lot of use cases. Lots of sites have different domains (also for example when HBO max renamed to max). Plaid also relies on entering bank passwords on neobank sites and is widely used.
- gjulianm 3y ago
  AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. And for things like Plaid, I think banks are moving towards OAuth-style permissions, where you login to your bank and authorize the connection. Under the hood, Plaid or other app can connect to the bank with limited permissions using API authorization keys. It's a different problem, I think.
  - tialaramex 3y ago
    > AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. In principle the fancier systems with a user interface could add a feature where you can change the DNS names associated with a key it's storing. That sounds like a monumental pain in the backside, and of course the primary consequence would be it increases phishing because now your users can be tricked into allowing it - but sure, they could do that. For simpler devices like a Yubico Security Key, there is no such interface, they aren't storing any keys so there's no way to make such an association. The keys are bound to the DNS name and are actually stored (encrypted) by the sites you're actually authenticating to. So without a matching DNS name they're intentionally just useless nonsense.

smcleod 3y ago

Hopefully this comes to Strongbox soon!

abiro 3y ago

Any details on how passkeys sync using external providers?

xmdx 3y ago

Is the whole idea of syncing passkeys a bad idea? Or at least a less secure idea. Someone explained to me that passkeys are hardware backed, each passkey is stored on device and tied to the hardware, so even if someone managed to get access to it, they would also need the hardware to get it to work. These software based keys that can be synced are less secure as a result. Then it just becomes like a password again. I need to read up a bit more on passkeys in general tbh.

stavros 3y ago
It is less secure, but more convenient. You can pick either option. Or you can have both with delegation ("your husband is trying to log in as you on www.google.com, allow?").
whatyesaid 3y ago
I think passkeys + 2FA is enough. Just enforce 2FA for any important service and it will be fine, if you don't force it then people who aren't as tech savvy will not do it or people may forget. For anything non-important I actually use sign in with Google, so.
WorldMaker 3y ago
Passkeys as a brand include both hardware-backed keys that can't be exported and are device-specific. These can be used for things like 2FA/MFA-type scenarios. They also involve a lot of site-specific keys that may not be hardware-backed and syncable. The neat fun thing is that they can be synced with hardware-backed keys for strong E2E between a user's enrolled devices and only the user's enrolled devices (plus maybe a hard to use recovery key). (That's basically how iCloud's Password/Passkey store and a lot of iCloud E2E in general seems to work.) Passkeys in general, especially the focus on a lot of site-specific E2E shared ones, are very much "just like a password", but as the sibling comment points out, the switch to PKI alone is a huge security win and would stop a lot of the haveibeenpwned sorts of leaks and the overall attractiveness to crackers to break into various company's password databases, because only having a public key is a lot less useful than a salted/hashed password that might be broken or found in a rainbow table.

jiggawatts 3y ago

My method for judging the quality of software: Read the latest release notes, negate every statement, and think to yourself: "They were fine with it being like this until now." Passkeys have been advertised as a superior replacement to passwords, but really fundamental issues remain unaddressed. I have one (1) Windows PC and one (1) iDevice. Can I get these to sync? Will both be able to log me in to a Google Account? Or do I need an Android phone for that? Can I use an iDevice to authenticate with an Azure AD app? Can I recover the passkeys on a lost iDevice without having to pay Apple for a new device to restore the backup? Etc... I guarantee many more release notes that could be summarised as: "Now supports a common scenario!"

rickdeckard 3y ago
> I have one (1) Windows PC and one (1) iDevice. Can I get these to sync? "Why? Where's the profit for us in that case?"
echeese 3y ago
> I have one (1) Windows PC and one (1) iDevice. Can I get these to sync? Or do I need an Android phone for that? Yes. In Chromium-based browsers, at least. Your browser will display a QR code which you scan with your phone. Your phone will display a list of accounts you can sign in with, you select one, authenticate, and you're logged in. Firefox support isn't here yet.
- jiggawatts 3y ago
  That's not what I mean by "sync". If I don't have the phone with me, I can't authenticate. Also, I use Firefox exclusively. This is precisely what I mean: common scenarios are not yet supported.
  - sbuk 3y ago
    You’re somewhat missing the point of what passkeys are. Instead of the something you know part, i.e. a password, the authentication is done by something you have. Your common use case is only common to single factor password authentication. It’s not a situation that is allowed for in passkey’s security model.

garganzol 3y ago

I'm totally in if passkeys come without middle men, especially like Google and Apple. Otherwise I'm totally out. No trust in these guys, they are as capricious as Roman emperors and will eventually do their usual stuff: lock in and collusion.

yomlica8 3y ago
I've got a big problem with the attestation feature even existing in the spec. I know Apple plans to "zero it out" but if that changed sites could lock out non approved devices. I'd vastly prefer it wasn't part of the spec at all rather than relying upon the whims of a single megacorporation. If they ever drop that cover things will gradually become defacto locked to middlemen anyway.
- garganzol 3y ago
  Exactly. Middle men are not needed. Passkeys can and should be handled by an open specification. In this way, passkeys will be decentralized and can be supported by anyone and everywhere. Users should decide by themselves where they want to store the authenticator: be it a separate device or a password manager running on their computer. Authenticator is just an algorithm that uses key material from elsewhere (biometrics, master password, whatever user prefers) to perform the authentication. Tying the whole thing to a couple of corps is cringy and creepy at the same time. There must be an open standard where everyone can participate.
- danShumway 3y ago
  This is a great point. I'm really happy about Apple's plans, but I have a hard time taking it at face value that there's nothing to worry about here if there's resistance to putting that plan into the spec itself. Because I start to get suspicious any time a company says, "we're not going to do X, but we absolutely refuse to commit in any meaningful way to not doing X." There's an implication there. I feel the same way about syncing, honestly: "Everyone is going to support 3rd-pary sync." "Can we put it in the spec that they have to?" "Well, that would be overreaching..." I think there are a lot of people who have genuinely good intentions, but it still makes me pretty nervous. If we could just trust every company to magically work things out and be compatible with everyone, we wouldn't need industry specifications in the first place. I think it's appropriate to try and standardize the baseline mechanisms users should have to control their keys and preserve their privacy.

dethos 3y ago

Good news. Lock-in was one of the biggest issues with passkeys. I think we will see a bunch of well known password managers adding passkey support soon. Is there any standard for this integration/interoperability? What about moving from one provider/app to another?

ndjdhdidve 3y ago
you fell for it. the article says nothing to that end. still full locked in. the UI will allow implementations... via app stores approved apps using their OS apis. for sure.

vouaobrasil 3y ago

So far, no one has commented on this large downside of passkeys: that it will promote the ease of sites to require login since it's much easier to generate a passkey than to remember a new password or even store it. Thus, passkeys lubricate the path towards an ever-increasing login-based society where it becomes much easier to track and monitor your online behaviour. Although it has the benefit of making our existing lives easier by removing the need to remember our banking passwords, it also will bring us further into the realm of technology by making more and more services log-in based. A greater ease of making a log-in based service means more revenue, more profit for Apple, and a greater integration of technology into our lives. Few people realize this because we have been conditioned to believe that new technology is solely for our benefit. In reality, Apple is not concerned with our benefit. They are concerned with profit and making technology more efficient to accomplish that end. So although passkeys might seem nice, there is a serious downside to this technology.

rickdeckard 3y ago
It's also a convenient workaround to synchronize information about your online-behavior, while still being able to state publicly that your browser-history is never processed to profile you. Upvoting this because it's a view worth sharing (and I'm sure you'll be downvoted just because of your baseless claim that Apple is concerned about something as dirty as profit /s)
- theshrike79 3y ago
  Apple is making filthy amounts of money just from hardware and app sales. All of their attempts at targeted advertising have been rounding errors at best. And they know that complete unbreakable privacy is the place where Google (an ad company) can never ever fully follow no matter what kind of lip service they do in their keynotes about privacy.
  - clairity 3y ago
    all of apple's recent growth is coming from its content ("services") business, which means it's hot to track you for advertising purposes. passkeys provide another stone in their walled garden to be able to track you but keep others from doing so as effectively, which on balance contributes to its competitive advantage. make no mistake that this is the direction apple is headed. it's been clear for the last 5 years or so, since hardware sales have leveled off. perhaps the goggles will dampen the velocity a bit, but i'm very skeptical that the AR/VR market is mature enough to have that effect in the near future.

ndjdhdidve 3y ago

1. article says nothing about external identity providers. which is what everyone here wants. still fully locked in. 2. it only hints at the UI being open to other apps, approved in the app store of course, using their new undocumented api 3. the sharing features will probably happens over their central control. not over the UI implementers. so many misconceptions in these comments. specially mixing up passkeys with in device keys

zamadatix 3y ago
It starts out saying "Passkeys can now be synced using external providers", how does it say nothing about external providers? I'd love to see the detail as well but, lacking that, there is nothing in the article that says these takes are correct and the others misconceptions either.

spuz 3y ago

One thing I don't understand about offering passkey login for your email is how you would go about recovering an account if you lost access to the device which holds your passkey? Google states: "When you create a passkey, you opt in to a passkey-first, password-less sign-in experience.". This seems to imply that you will not be able to use your old password if you ever lost your phone. Do Google still offer backup passwords for recovery purposes if you switch to passkeys? Their site doesn't seem to explain this. https://support.google.com/accounts/answer/13548313?hl=en#zippy=%2Clost-or-stolen-device%2Cmissing-or-unavailable-passkey https://support.google.com/accounts/answer/13548313?hl=en#zi...

deleted 3y ago
[deleted]
Ajedi32 3y ago
Think of passkeys as being the same as a password database. The provider can offer whatever recovery mechanism they want, and sites that use passkeys can continue to offer account recovery methods completely independent of their use of passkeys. As for what Google does specifically with their implementation, I'm not sure. I personally plan to use KeepassXC's implementation, whenever that comes out, with my own custom database backup strategy.
- snagg 3y ago
  This is an area with the specs contrast with the vendors. The WebAuthn specs recommends to register multiple passkeys/credentials per device and assume that once a credential is lost it might not be recoverable. Apple and other vendors using keychains/wallets are effectively offering the option to delegate the recovery of the passkey to the recovery of the account with them (eg: the iCloud account). In case it is of interest, we wrote a long blogpost on the topic: https://www.slashid.dev/blog/passkeys-security-implementation/#how-are-credentials-shared-and-stored https://www.slashid.dev/blog/passkeys-security-implementatio...
  - deleted 3y ago
    [deleted]

danShumway 3y ago

I still want to see more details. That being said, extremely positive news. Vendor lock-in is one of the biggest issues with passkeys and one of the biggest reasons I haven't been able to get on board with them and why I usually end up advocating against them whenever they come up. Between this and Apple blocking attestation efforts for mobile passkeys, it gives me more confidence that this could turn into a standard that I want to use. I criticize the passkey standard pretty consistently, I would be very happy to eat crow on that. I will say that it would go a long way to make this stuff part of the standard, I don't like how much these really critical pieces of passkey functionality are boiling down to "wait and see what vendors do." But I'm cautiously optimistic to see where things go. It is a really big deal for Apple to support 3rd-party providers and an even bigger deal for Apple to support sync with 3rd-party providers.

anderspitman 3y ago

My main concern with passkeys is I'm not aware of a way to pre-authorize someone who doesn't yet have an account. For example, with email I can just grant X access to anyone who can prove they have access to Y email address. But passkeys don't have a single public handle like this. This isn't such a big deal with centralized services where everyone is likely to already have an account, but might pose a problem for selfhosted services. Still, I like passkeys and wish there was a way to have my cake and eat it too.

mistrial9 3y ago

next headline -- Passkeys now require external providers update this dev news announcement actually opens the setup a bit more, instead of close it down a bit more. However the whole Apple walled garden and always-on networking is not a happy thing from this desk

botanical 3y ago

Until I can export a passkey to KeePassXC I won't use it. How do you recover your account if you're locked out? Or if Google decides to ban you?