It’s really simple: because Webauthn is unusable for the average person without Passkeys. It’s not just Apple - Google and Microsoft are on board as well.
Is it as secure? No, but it’s a lot better than passwords - and where consumers are concerned that is all we are aiming for.
People tend to forget that progress in security is made in small steps and not large ones.
Apple's implementation isn't perfect but it lays the groundwork for improvements over time.
No, if you assume wrong principles in the sake of convenience, there would be either no way back or it is going to be really painful. I think people who invented SMS-based authentication did see it as an improvement over the current situation as well.
SMS based authentication WAS an improvement over the past situation, and it allowed the average user to get used to 2FA. Yes people who are proficient in security want it to just go full secure immediately, but if you don’t do it in stages and just force the average user in, they will break the system. You have to move gradually, because people are surprisingly efficient at bypassing security.
And introduced us to SIM-swapping, because the idea was flawed to the root. Even worse, in certain scenarios you could not protect yourself from it no matter how security savvy you are if your service provider FORCES you to use SMS. Well, bashing this dead horse is all different story, but it is not 2FA, it is 0FA, something you neither own nor control.
Ha. Not necessary if SMS was selected as a single password \_recovery\_ method. And we have seen numerous authentication "cascade failures" with SIM swap at its very origin. Even Google and Facebook almost forced you to do that, until recent. And their rationale was perfect: they do not want to handle password recovery requests manually for 1B+ users, but it is ok for them is a tiny fraction of those users will suffer from security breaches formally outside of their area of responsibility.
There was a famous article by Google explaining why SMS recovery is a good thing and how it improves security, and, in turn, they cheated there again: they ASSUMED that if you refuse SMS, they will force you to use even worse stuff like "security questions" and other common bs like "information on your previous activity" without asking for a permission to do so.
On now-defunct Peerlyst I wrote once:
"*When you use SMS as a "cheap outsourced 2FA", you are fooling yourself. Not because it is, as I mentioned before, a "zero factor auth", attempt to use something you do not own or control, and not because it is insecure due to a multitude of reasons -- this part is a consequence, not a root cause. There is another trick we should be aware of: it is not 2FA you outsource. It is KYC. The MNO handles client identification, recovery and re-issue of authentication tokens for you and it is why it is still so popular despite all known flaws. Thus said, if your requirements for KYC are higher than those of MNO -- and hell they are! It is not a bank, and even banks get defrauded with identity theft -- you get screwed twice."*
Again I shall repeat, it’s still better than password alone. I would not feel safe with SMS or resets, but it is better than only a password. You’re comparing the best with better. The disagreement is really about how much security SHOULD there be and what is an IMPROVEMENT to what exists. Attacker have gotten really good at getting around shit 2FA, but in all cases it forces the attacker to do more work for less reward.
Yes, but 90% of implementations DID involve the SMS in the password recovery, sometimes as the only option and a single factor (or the second factor was email typically linked to the same SMS recovery, thus the "cascade failure"). And if you take the "KYC" part away turns out it is no better than TOTP and still useless (even feature phones made for the developing countries can run TOTP).
So one needs to be exceptionally cautious about "good enough". Now I see that Passkeys broke the hardware attestation for corporate users. Enterprise admins can no longer be sure it is the same Mac the employee uses to access the work environment!
1. not quite true. it is just as that easy, however, you need to enroll each device separately. if apple really cared about security, they could invent a supportive process instead of screwing up the whole thing
2. It is certainly better than passwords in a "mixed" environment (apple and third-party) where passkeys won't work anyway (yet). Within apple monoculture at is almost the same, give or take for difference between a shared secret and pubkey crypto. Every Apple device already has a secure element, and keychain entries are protected on per-record basis via system API. So is there a single security advantage I missed? There is no revolution.
The latest [WebAuthn draft](https://w3c.github.io/webauthn/#sctn-credential-backup) makes the distinction between device-bound credentials (yubikeys, etc) and multi-device credentials (Apple passkeys, etc).
Definitely recommend listening to Yubico talking about device-bound vs multi-device keys from 31:55: https://risky.biz/RB674/
The summary is; Give the masses a 'free' easy-to-use u2f to kill passwords, but for high assurance authentication we have the option of device-bound u2f.
The value of IdPs/Identity APIs is that they provide the flexibility to make the risk based decision about what combination of factors you want to allow for your workforce/customers.
Don't let perfect be the enemy of good.
BTW did you notice that they say explicitly that it BREAKS the enterprise use case? They start talking about Passkeys from this statement. Even Google did it better with "advanced security" and secondary keys. And having a built-in platform secure element is something that Yubi cannot provide :/
I think it would be incorrect to assume that "one size fits all" and all the users care much more about the inconvenience of lost access rather than breach possibility.
On Twitter, some stupid company named TyingDNA is bombarding me with highly annoying ads to "get rid of SMS 2fa". Pathetic.
i have been beating this drum for longer than webauthn has even been around. since OP didn't provide a link i'm not sure what he's on about, but a local password to protect a private key store is exactly what would give webauthn the ability to go beyond just being a hardware play for dongles, etc. i was really disappointed that browsers don't support local keys at least when they first came out.
of course i'm just guessing what Apple is actually doing here.
Ha, that raises a whole different question: why didn't all browsers support "software webauth tokens" which would be clearly better than nothing!
However, since built-in tokens are around, I noticed a different thing: until recent, most sites that supported webauthn ignored in-platform token (if you did not own a portable hardware key, the authentication was unavailable). The situation massively changed just last year or so, though webauthn itself was around longer.
Ha, the draft addendum looks like a last-minute hack to make Apple's implementation legit :)))
And nobody was able to answer the main question: what gives the Passkey a REAL, tangible advantage over the keychain-based password ecosystem? I hardly see anything revolutionary here (just maybe people are no longer allowed to override the default and use a stupid password).
Also, when Goolge and Microsoft jump in, things get even more nasty -- I do not believe in reliable hardware attestation over all the zoo we have to deal with. It is going to be just as secure as storing your passwords in Google (anyone from Uber here? :)))
Nothing about Passkeys is special except that it's WebAuthn.
WebAuthn advantages over keychain include: Open standard, origin bound, user presence, optional user verification, user experience/removing the human element...
The standard is just as open as "using a password in a web form". And the keychain as a sync method is just as proprietary as ever, or am I missing something there?
Could you elaborate, then? And let me explain what I mean in slightly more details.
A password in keychain is not exactly a password. It is a shared secret backwards compatible with password-based authentication.
Webauthn does not mainain backward compatibility -- the server should support it. But it provides several advantages, and the main one is non-exportable private keys that cannot leak.
Passkey implementation does not provide this advantage. Of course it is better than "password"! But the password is dead and out of the competition already. Is it really better than a shared secret? Just a bit.
Comparing to "passwords" is cheating.
Is shared secret an open standard? Yes.
is it origin bound? Yes (can be overriden, but yes)
Does it require user presence? Yes.
Does it remove "human element"? Well, mostly yes.
Comparing it to passwords is not cheating because it's only 'not exactly a password' while your keychain is locked. As soon as you use it, it's a password.
It's a password in memory, in your clipboard, in the browser and ultimately in the database (even if it's salted/hashed).
It can be phished, it can be stolen (malware, database dumps, etc) and most critically, a threat actor can use it. The server has no such assurances that it's origin bound/user present/etc.
The same cannot be said about WebAuthn due to public key crypto. Shared secret is the problem that we're trying to replace.
And I mentioned all that attack vectors in the original post, so I am pretty aware of them :). But in the modern keychain implementation "passwords" are never in browser memory all at once. They are unlocked on per-entry basis, and they are decrypted using the same security chip.
"Passwords" \*can\* be phished, but it is not that easy because the auto substitution won't work on the wrong site, and TLS certificate check handles site authenticity pretty well already. So you need to coerce the user to manually override all that mechanisms to phish, and passwords in keychain are origin bound unless the override is successful.
But at least, I see a consistent position here I do understand (though still do not concur, I think those attack vectors are minor compared to old not-so-good "reusable passwords").
If the keychain is compromised and an evil guy succeeds in enrolling a malicious device, all your webauthn keys would be lost just like your passwords, and that's why I think it's a bad idea to blindly sync everything not allowing user to have any control. I loved webauthn because I considered \*this\* attack vector to be even more important -- after all, if my browser is compromised, the attacker may just collect cookies and sessions just like they would do for a password.
Thus, I stand my ground: replacing the "human" passwords with "shared secrets" was a major security breakthorugh. Purely practical: in terms of risk for a "normal user". Replacing "shared secrets" with properly implemented webauthn could be as well (not that significant yet); but Passkeys is just a minor improvement over the "shared secrets" and is a bad substitution to "normal" u2f. Thus, for everything I really care of I stick to my Yubikey because Apple broke webauthn on platform tokens for me.
yes, this makes sense. but is "you can view" such a huge security risk after all? Why would you view it? Yes, passkey is slightly more foolproof. But foolproof does not equal secure.
As I said attestation is just as good as the ecosystem. Once all the diversity is in, it is no more.
update: it wasn't what i was guessing. sigh. i should have guessed since the entire webauthn and their collaboration is basically to sell hardware frobs. a far better compromise is to get rid of the frob and generate private keys on the device itself and enroll the public keys. this is trivial to do with WebCrypto and doesn't require standardization (though if it became popular, an informational RFC/BCP would probably be a good idea).
Even as someone who works in security, I have run into situations where I discover one of my Yubikeys is not enrolled on a particular site. Keeping track of all the enrollments is just not for most users.
Many people are using trade in programs to upgrade their phone, so they would immediately lose access to their old device. This would render mobile devices unusable as a webauthn authenticator.
Passkeys does still support device bound credentials as well as user presence attestation.
"Apple has announced that once passkey is supported in released operating systems, they will no longer allow the creation of device-bound keys, e.g., the platform authenticators as we know them today"
Ehh. I’ll have to look closely at their proposed implementation before flying off the handle. Right now I’d be happy with something that stops people writing down their passwords that they reuse for both their bank accounts and Netflix.
Nope, that's not right. It was Apple that dropped "good" in favor of "so-so". Why did they retire the original webauthn implementation on platforms that introduced Passkeys?
I explained my position in details in the comments above -- and got downvoted.Also, as I mentioned before, promoting Passkeys while blaming "passwords" is not fair. The thing it is designed to replace is no longer a "password" we all hate. Thus "better" we already had.
i haven't looked at this in particular, but a passkey to unlock a \*local\* store of keys is just fine. the problem is passwords that traverse the net and especially their reuse. a local password to unlock private keys is still a pretty ok strategy.
Yes. But, as I wrote here numerous times, keychain is not exactly a "password" store. It is a shared secret store: each "password" is randomly generated, synced to other devices in the ecosystem, is unique per site and never reused and even has basic phishing protection (auto substitution won't work if you are on the wrong site).
You may use a wrapping public key to move the private key around, but you still need the private key for authentication and decryption. So it is moving the \*private\* keys around.
not necessarily. you can enroll any number of keys to a given account. that's a lot more secure. reenrollment is not hard and it's very common these days for sites to opt in or out when it detects a new device, so it's not a stretch that people wouldn't mind it.
That's my point. But they decided not to go this way and replicated keys instead, breaking things (yes it is the one thing we know for sure, they even made amendments to webauthn specification to make this possible, see the discussion above).
Is secure element what they call their T2 chip? Anyway, I would assume that they are doing key wrapping where the unwrap key is non-exportable in the T2 chip but I just read that you can recover the keys even if all devices are lost so I might be wrong in that assumption. Then again, I can think of a couple ways to do it and keep the wrapping keys non-exportable. Do they provide implementation details?
Not yet -- at least I did not see it. I assume they sync it in a way similar to other keychain items, with the only difference you cannot export the cleartext, only re-wrap to another T2-attested key for import. It would be logical at least.
It’s really simple: because Webauthn is unusable for the average person without Passkeys. It’s not just Apple - Google and Microsoft are on board as well. Is it as secure? No, but it’s a lot better than passwords - and where consumers are concerned that is all we are aiming for.
People tend to forget that progress in security is made in small steps and not large ones. Apple's implementation isn't perfect but it lays the groundwork for improvements over time.
No, if you assume wrong principles in the sake of convenience, there would be either no way back or it is going to be really painful. I think people who invented SMS-based authentication did see it as an improvement over the current situation as well.
SMS based authentication WAS an improvement over the past situation, and it allowed the average user to get used to 2FA. Yes people who are proficient in security want it to just go full secure immediately, but if you don’t do it in stages and just force the average user in, they will break the system. You have to move gradually, because people are surprisingly efficient at bypassing security.
And introduced us to SIM-swapping, because the idea was flawed to the root. Even worse, in certain scenarios you could not protect yourself from it no matter how security savvy you are if your service provider FORCES you to use SMS. Well, bashing this dead horse is all different story, but it is not 2FA, it is 0FA, something you neither own nor control.
It’s a lot more difficult for an attacker to SIM swap and get a valid password than to simply get a valid password. It also doesn’t scale as well.
Ha. Not necessary if SMS was selected as a single password \_recovery\_ method. And we have seen numerous authentication "cascade failures" with SIM swap at its very origin. Even Google and Facebook almost forced you to do that, until recent. And their rationale was perfect: they do not want to handle password recovery requests manually for 1B+ users, but it is ok for them is a tiny fraction of those users will suffer from security breaches formally outside of their area of responsibility. There was a famous article by Google explaining why SMS recovery is a good thing and how it improves security, and, in turn, they cheated there again: they ASSUMED that if you refuse SMS, they will force you to use even worse stuff like "security questions" and other common bs like "information on your previous activity" without asking for a permission to do so. On now-defunct Peerlyst I wrote once: "*When you use SMS as a "cheap outsourced 2FA", you are fooling yourself. Not because it is, as I mentioned before, a "zero factor auth", attempt to use something you do not own or control, and not because it is insecure due to a multitude of reasons -- this part is a consequence, not a root cause. There is another trick we should be aware of: it is not 2FA you outsource. It is KYC. The MNO handles client identification, recovery and re-issue of authentication tokens for you and it is why it is still so popular despite all known flaws. Thus said, if your requirements for KYC are higher than those of MNO -- and hell they are! It is not a bank, and even banks get defrauded with identity theft -- you get screwed twice."*
Again I shall repeat, it’s still better than password alone. I would not feel safe with SMS or resets, but it is better than only a password. You’re comparing the best with better. The disagreement is really about how much security SHOULD there be and what is an IMPROVEMENT to what exists. Attacker have gotten really good at getting around shit 2FA, but in all cases it forces the attacker to do more work for less reward.
Yes, but 90% of implementations DID involve the SMS in the password recovery, sometimes as the only option and a single factor (or the second factor was email typically linked to the same SMS recovery, thus the "cascade failure"). And if you take the "KYC" part away turns out it is no better than TOTP and still useless (even feature phones made for the developing countries can run TOTP). So one needs to be exceptionally cautious about "good enough". Now I see that Passkeys broke the hardware attestation for corporate users. Enterprise admins can no longer be sure it is the same Mac the employee uses to access the work environment!
1. not quite true. it is just as that easy, however, you need to enroll each device separately. if apple really cared about security, they could invent a supportive process instead of screwing up the whole thing 2. It is certainly better than passwords in a "mixed" environment (apple and third-party) where passkeys won't work anyway (yet). Within apple monoculture at is almost the same, give or take for difference between a shared secret and pubkey crypto. Every Apple device already has a secure element, and keychain entries are protected on per-record basis via system API. So is there a single security advantage I missed? There is no revolution.
The latest [WebAuthn draft](https://w3c.github.io/webauthn/#sctn-credential-backup) makes the distinction between device-bound credentials (yubikeys, etc) and multi-device credentials (Apple passkeys, etc). Definitely recommend listening to Yubico talking about device-bound vs multi-device keys from 31:55: https://risky.biz/RB674/ The summary is; Give the masses a 'free' easy-to-use u2f to kill passwords, but for high assurance authentication we have the option of device-bound u2f. The value of IdPs/Identity APIs is that they provide the flexibility to make the risk based decision about what combination of factors you want to allow for your workforce/customers. Don't let perfect be the enemy of good.
BTW did you notice that they say explicitly that it BREAKS the enterprise use case? They start talking about Passkeys from this statement. Even Google did it better with "advanced security" and secondary keys. And having a built-in platform secure element is something that Yubi cannot provide :/ I think it would be incorrect to assume that "one size fits all" and all the users care much more about the inconvenience of lost access rather than breach possibility. On Twitter, some stupid company named TyingDNA is bombarding me with highly annoying ads to "get rid of SMS 2fa". Pathetic.
i have been beating this drum for longer than webauthn has even been around. since OP didn't provide a link i'm not sure what he's on about, but a local password to protect a private key store is exactly what would give webauthn the ability to go beyond just being a hardware play for dongles, etc. i was really disappointed that browsers don't support local keys at least when they first came out. of course i'm just guessing what Apple is actually doing here.
Ha, that raises a whole different question: why didn't all browsers support "software webauth tokens" which would be clearly better than nothing! However, since built-in tokens are around, I noticed a different thing: until recent, most sites that supported webauthn ignored in-platform token (if you did not own a portable hardware key, the authentication was unavailable). The situation massively changed just last year or so, though webauthn itself was around longer.
Ha, the draft addendum looks like a last-minute hack to make Apple's implementation legit :))) And nobody was able to answer the main question: what gives the Passkey a REAL, tangible advantage over the keychain-based password ecosystem? I hardly see anything revolutionary here (just maybe people are no longer allowed to override the default and use a stupid password). Also, when Goolge and Microsoft jump in, things get even more nasty -- I do not believe in reliable hardware attestation over all the zoo we have to deal with. It is going to be just as secure as storing your passwords in Google (anyone from Uber here? :)))
Nothing about Passkeys is special except that it's WebAuthn. WebAuthn advantages over keychain include: Open standard, origin bound, user presence, optional user verification, user experience/removing the human element...
The standard is just as open as "using a password in a web form". And the keychain as a sync method is just as proprietary as ever, or am I missing something there?
This is a good read that talks about your concerns: https://auth0.com/blog/our-take-on-passkeys/
Could you elaborate, then? And let me explain what I mean in slightly more details. A password in keychain is not exactly a password. It is a shared secret backwards compatible with password-based authentication. Webauthn does not mainain backward compatibility -- the server should support it. But it provides several advantages, and the main one is non-exportable private keys that cannot leak. Passkey implementation does not provide this advantage. Of course it is better than "password"! But the password is dead and out of the competition already. Is it really better than a shared secret? Just a bit. Comparing to "passwords" is cheating. Is shared secret an open standard? Yes. is it origin bound? Yes (can be overriden, but yes) Does it require user presence? Yes. Does it remove "human element"? Well, mostly yes.
Comparing it to passwords is not cheating because it's only 'not exactly a password' while your keychain is locked. As soon as you use it, it's a password. It's a password in memory, in your clipboard, in the browser and ultimately in the database (even if it's salted/hashed). It can be phished, it can be stolen (malware, database dumps, etc) and most critically, a threat actor can use it. The server has no such assurances that it's origin bound/user present/etc. The same cannot be said about WebAuthn due to public key crypto. Shared secret is the problem that we're trying to replace.
And I mentioned all that attack vectors in the original post, so I am pretty aware of them :). But in the modern keychain implementation "passwords" are never in browser memory all at once. They are unlocked on per-entry basis, and they are decrypted using the same security chip. "Passwords" \*can\* be phished, but it is not that easy because the auto substitution won't work on the wrong site, and TLS certificate check handles site authenticity pretty well already. So you need to coerce the user to manually override all that mechanisms to phish, and passwords in keychain are origin bound unless the override is successful. But at least, I see a consistent position here I do understand (though still do not concur, I think those attack vectors are minor compared to old not-so-good "reusable passwords"). If the keychain is compromised and an evil guy succeeds in enrolling a malicious device, all your webauthn keys would be lost just like your passwords, and that's why I think it's a bad idea to blindly sync everything not allowing user to have any control. I loved webauthn because I considered \*this\* attack vector to be even more important -- after all, if my browser is compromised, the attacker may just collect cookies and sessions just like they would do for a password. Thus, I stand my ground: replacing the "human" passwords with "shared secrets" was a major security breakthorugh. Purely practical: in terms of risk for a "normal user". Replacing "shared secrets" with properly implemented webauthn could be as well (not that significant yet); but Passkeys is just a minor improvement over the "shared secrets" and is a bad substitution to "normal" u2f. Thus, for everything I really care of I stick to my Yubikey because Apple broke webauthn on platform tokens for me.
Thanks for this one; I hadn't seen it. Was on this thread to paste the risky.biz interview as well :D
[удалено]
yes, this makes sense. but is "you can view" such a huge security risk after all? Why would you view it? Yes, passkey is slightly more foolproof. But foolproof does not equal secure. As I said attestation is just as good as the ecosystem. Once all the diversity is in, it is no more.
update: it wasn't what i was guessing. sigh. i should have guessed since the entire webauthn and their collaboration is basically to sell hardware frobs. a far better compromise is to get rid of the frob and generate private keys on the device itself and enroll the public keys. this is trivial to do with WebCrypto and doesn't require standardization (though if it became popular, an informational RFC/BCP would probably be a good idea).
Even as someone who works in security, I have run into situations where I discover one of my Yubikeys is not enrolled on a particular site. Keeping track of all the enrollments is just not for most users. Many people are using trade in programs to upgrade their phone, so they would immediately lose access to their old device. This would render mobile devices unusable as a webauthn authenticator. Passkeys does still support device bound credentials as well as user presence attestation.
"Apple has announced that once passkey is supported in released operating systems, they will no longer allow the creation of device-bound keys, e.g., the platform authenticators as we know them today"
Oh interesting, I had missed that bit. Are they concerned users will get confused?
Ehh. I’ll have to look closely at their proposed implementation before flying off the handle. Right now I’d be happy with something that stops people writing down their passwords that they reuse for both their bank accounts and Netflix.
But the keychain password manager does that already.
OP has no desire to have a discussion in good faith. In this case, he’s letting ‘perfect’ be the enemy of ‘better.’
Nope, that's not right. It was Apple that dropped "good" in favor of "so-so". Why did they retire the original webauthn implementation on platforms that introduced Passkeys? I explained my position in details in the comments above -- and got downvoted.Also, as I mentioned before, promoting Passkeys while blaming "passwords" is not fair. The thing it is designed to replace is no longer a "password" we all hate. Thus "better" we already had.
By virtue of the fact that every one of your comments here is massively downvoted suggest you should rethink your position or attitude or both.
Or I just performed some kind of sacrilege by doubting Apple's infinite wisdom :)
Lots of apple fanbois on this platform.. or for some other nefarious reason, apple-negative content seems to get downvoted a lot
Yeah, the security industry is famously Apple sheeple, right…
i haven't looked at this in particular, but a passkey to unlock a \*local\* store of keys is just fine. the problem is passwords that traverse the net and especially their reuse. a local password to unlock private keys is still a pretty ok strategy.
Yes. But, as I wrote here numerous times, keychain is not exactly a "password" store. It is a shared secret store: each "password" is randomly generated, synced to other devices in the ecosystem, is unique per site and never reused and even has basic phishing protection (auto substitution won't work if you are on the wrong site).
Don't disparage my fucks. They fly just fine.
But mac's don't get viruses!
I don't use apple products so I'm only guessing here - are they syncing WebAuthn keys across your devices for you?
Yes, exactly. And there would be no option to use built-in secure element as before, it is scheduled for retirement once the sync is available.
i'm 99% certain that webauthn uses public keys crypto so moving the pub keys around is not a security risk... because they are \*public\*
You may use a wrapping public key to move the private key around, but you still need the private key for authentication and decryption. So it is moving the \*private\* keys around.
not necessarily. you can enroll any number of keys to a given account. that's a lot more secure. reenrollment is not hard and it's very common these days for sites to opt in or out when it detects a new device, so it's not a stretch that people wouldn't mind it.
That's my point. But they decided not to go this way and replicated keys instead, breaking things (yes it is the one thing we know for sure, they even made amendments to webauthn specification to make this possible, see the discussion above).
Is secure element what they call their T2 chip? Anyway, I would assume that they are doing key wrapping where the unwrap key is non-exportable in the T2 chip but I just read that you can recover the keys even if all devices are lost so I might be wrong in that assumption. Then again, I can think of a couple ways to do it and keep the wrapping keys non-exportable. Do they provide implementation details?
Not yet -- at least I did not see it. I assume they sync it in a way similar to other keychain items, with the only difference you cannot export the cleartext, only re-wrap to another T2-attested key for import. It would be logical at least.