Introducing passkeys in Chrome(blog.chromium.org)
blog.chromium.org
Introducing passkeys in Chrome
https://blog.chromium.org/2022/12/introducing-passkeys-in-chrome.html
211 comments
I'm in the process of migrating to a new phone. My old phone had an eSIM that was tied to some 2FA (not by choice, and it couldn't be changed, because security), and my temp phone doesn't support an eSIM, so until the new one arrives I can't access some services. You don't even need to lose anything to be locked out.
Did you not keep any of the backup code? I am not sure why 2FA is related to the eSIM unless you mean certain services force using SMS as the method to receive 2FA. I have experienced that same restriction with financial services in the US. I agree, it's frustrating and feels counterproductive to security because it could motivate someone to borrow a friend's device temporarily to access the services. eSIMs are even more annoying as there is a limited amount of times you can switch devices.
It is the very rare site or service that actually refuses to let you back in with an email confirmation or something. Sites with SMS 2FA / mobile app 2FA will nearly 100% of the time let you fall back to email.
And why not? It's a huge support burden to do otherwise. You can say "we told you that you'd be locked out" and not even confirm to the user that an account exists with that user ID, but then half of the users who get locked out will complain about it on social media.
You can only really enforce 2FA if your site has to do with money or similar.
And why not? It's a huge support burden to do otherwise. You can say "we told you that you'd be locked out" and not even confirm to the user that an account exists with that user ID, but then half of the users who get locked out will complain about it on social media.
You can only really enforce 2FA if your site has to do with money or similar.
For major sites, FAMG having access to email is not enough in my experience. I was recently locked out of my Instagram account and lost my 2FA. Instagram required me to contact support from a known previously associated email, but on top of that I had to upload a picture of myself holding a piece of paper with a handwritten nonce and they checked against my previously uploaded pictures. I also had to wait a period of time before they would telling me what nonce to use and starting the verification process.
I have heard stories of people not being let in and having to contact friends who work at Facebook and have access to the internal support queue. I know my friend had to do something similar at Google and have a friend make a internal support ticket when they were locked out of a gmail account. That experience with Instagram is the reason I moved away from using DUO for everything to Aegis where I can copy a password encrypted backup of my 2FA secret keys like I would any file. I am grateful I learned that lesson by losing 2FA to a single account.
I have heard stories of people not being let in and having to contact friends who work at Facebook and have access to the internal support queue. I know my friend had to do something similar at Google and have a friend make a internal support ticket when they were locked out of a gmail account. That experience with Instagram is the reason I moved away from using DUO for everything to Aegis where I can copy a password encrypted backup of my 2FA secret keys like I would any file. I am grateful I learned that lesson by losing 2FA to a single account.
> What's my basic authentication method to a site or system I can write down, backup, export or memorize?
There isn't one. This is by design. Logging into your bank or email provider will in the future require mobile device shenanigans that are either proprietary or so complex and opaque that you have no chance of "controlling" anything, or even really understanding what's actually going on.
The main lobby driving this forward consists of Google, Apple, and Microsoft. This should tell you all you need to know.
There isn't one. This is by design. Logging into your bank or email provider will in the future require mobile device shenanigans that are either proprietary or so complex and opaque that you have no chance of "controlling" anything, or even really understanding what's actually going on.
The main lobby driving this forward consists of Google, Apple, and Microsoft. This should tell you all you need to know.
What part of WebAuthn, a W3C standard, is "proprietary or [...] complex and opaque"?
The FIDO alliance also consists of far more companies than just "Google, Apple, and Microsoft", although they're certainly members. https://fidoalliance.org/members/
The FIDO alliance also consists of far more companies than just "Google, Apple, and Microsoft", although they're certainly members. https://fidoalliance.org/members/
> What part of WebAuthn, a W3C standard, is "proprietary or [...] complex and opaque"?
Ask Mozilla. FIDO U2F is so complicated that Firefox support was hidden behind a config flag for a long time, then "a hard-coded permission for Google Accounts"[1] was implemented in order to not fall too far behind Chrome.
The linked email thread is an eye-opener on how many intricacies and unresolved questions there are, with multiple mentions of non-standard behavior implemented in the Google ecosystem, undermining WebAuthn. This is how such "standards" work in practice, and passkeys will be no exception.
[1] https://groups.google.com/g/mozilla.dev.platform/c/q5cj38hGT...
Ask Mozilla. FIDO U2F is so complicated that Firefox support was hidden behind a config flag for a long time, then "a hard-coded permission for Google Accounts"[1] was implemented in order to not fall too far behind Chrome.
The linked email thread is an eye-opener on how many intricacies and unresolved questions there are, with multiple mentions of non-standard behavior implemented in the Google ecosystem, undermining WebAuthn. This is how such "standards" work in practice, and passkeys will be no exception.
[1] https://groups.google.com/g/mozilla.dev.platform/c/q5cj38hGT...
FIDO U2F is not WebAuthn, and if you had even bothered to skim the link you provided, you probably would have realized that considering:
- they go out of their way to explicitly differentiate them, and
- the entire discussion is about U2F and bringing in support for it in a limited sense so that people adopt WebAuthn instead of U2F.
Like, did you even read the link you provided?
So, again, what about WebAuthn is proprietary or complicated?
- they go out of their way to explicitly differentiate them, and
- the entire discussion is about U2F and bringing in support for it in a limited sense so that people adopt WebAuthn instead of U2F.
Like, did you even read the link you provided?
So, again, what about WebAuthn is proprietary or complicated?
I'm not claiming they're the same. What matters is that U2F is what many websites implemented, which is why those problems arose in the first place.
This time, websites will implement "Chrome passkeys", which will be almost-but-not-quite WebAuthn, just like Internet Explorer's box model was almost-but-not-quite CSS.
If there are only two or three major players and the standard is sufficiently complex, "standard" becomes synonymous with "what iOS and Android do".
But to answer your question:
> So, again, what about WebAuthn is proprietary or complicated?
The WebAuthn standard is 184 pages of A4 size. That's a technical document, the length of a typical novel. Are you seriously asking what's "complicated" about that?
This time, websites will implement "Chrome passkeys", which will be almost-but-not-quite WebAuthn, just like Internet Explorer's box model was almost-but-not-quite CSS.
If there are only two or three major players and the standard is sufficiently complex, "standard" becomes synonymous with "what iOS and Android do".
But to answer your question:
> So, again, what about WebAuthn is proprietary or complicated?
The WebAuthn standard is 184 pages of A4 size. That's a technical document, the length of a typical novel. Are you seriously asking what's "complicated" about that?
U2F has nothing to do with WebAuthn. You bringing it up is literal whataboutism. We aren’t talking about it, we are talking about a completely different technology.
What about WebAuthn, explicitly, is complicated for you to understand? What about it is not a web standard that can be implemented in many different ways?
Furthermore, HTTP 1.1 is 174 pages, yet Firefox was able to implement it. Standards are, generally speaking, technical documents. Because that is what guarantees interoperability, that thing you are so vehemently defending.
Chrome passkeys are WebAuthn. Period. Fin. End of story. There is no separate implementation, they are the same thing. It is a standard that anyone can implement on either side that is inter compatible with whatever implementation is used. What part of this do you not understand?
What about WebAuthn, explicitly, is complicated for you to understand? What about it is not a web standard that can be implemented in many different ways?
Furthermore, HTTP 1.1 is 174 pages, yet Firefox was able to implement it. Standards are, generally speaking, technical documents. Because that is what guarantees interoperability, that thing you are so vehemently defending.
Chrome passkeys are WebAuthn. Period. Fin. End of story. There is no separate implementation, they are the same thing. It is a standard that anyone can implement on either side that is inter compatible with whatever implementation is used. What part of this do you not understand?
> It is a standard that anyone can implement
WebAuthn supports attestation of a key storage device. How are you going to persuade site owners to trust your self-signed attestation certificate?
WebAuthn supports attestation of a key storage device. How are you going to persuade site owners to trust your self-signed attestation certificate?
Ask the folks over at SoloKeys, who are both open source and FIDO certified.
It also supports it. Whether it’s enforced is a site owner’s decision, as are the trusted roots they use.
If a site owner wants to limit to only a single type of authenticator, they can already do that by only trusting its key, so I don’t see how that’s relevant to the topic of implementing the standard.
It also supports it. Whether it’s enforced is a site owner’s decision, as are the trusted roots they use.
If a site owner wants to limit to only a single type of authenticator, they can already do that by only trusting its key, so I don’t see how that’s relevant to the topic of implementing the standard.
I think they think that Google/Apple/Microsoft are deliberately creating dense standards so that nobody else has the technical means to implement them. The evidence presented was that one of these (U2F?) took a long time for Firefox to implement. Just a little note to dispel all this BS in one swoop: Firefox was the first browser to implement WebAuthn. https://blog.mozilla.org/blog/2018/05/09/firefox-gets-down-t...
it's certainly complex!
https://webauthn.guide/ challenge, attestation, rp, alg -7!? usb, ble, nfc!? it seems very easy to "hold it wrong" :)
and if you add u2f-fido to the mix, which is how most people so far saw webauthn in practice, it's even more complex.
it took me a lot of time to figure out what actually happens when I tap the security key. do I have one keypair? no, actually I have a lot, one for each site, but the site stores it in a clever encrypted encoded scheme.
https://webauthn.guide/ challenge, attestation, rp, alg -7!? usb, ble, nfc!? it seems very easy to "hold it wrong" :)
and if you add u2f-fido to the mix, which is how most people so far saw webauthn in practice, it's even more complex.
it took me a lot of time to figure out what actually happens when I tap the security key. do I have one keypair? no, actually I have a lot, one for each site, but the site stores it in a clever encrypted encoded scheme.
Which part of passkeys / Webauthn / FIDO requires a mobile device?
In principle, none. In practice, many websites will check the user agent and flat out refuse service unless it's one of a pre-approved list of implementations, regardless of whether it would work or not.
This has been happening for a long, long time already, for many browser features, and such "standards" pushed forward by the major mobile vendors will only make the problem worse.
This has been happening for a long, long time already, for many browser features, and such "standards" pushed forward by the major mobile vendors will only make the problem worse.
Well if we're making up things that websites haven't done yet then yeah I'm angry too.
Unless you're using one of the proprietary desktop OSes then you have to use one of the proprietary mobile OSes.
https://developers.google.com/identity/passkeys/supported-en...
https://developers.google.com/identity/passkeys/supported-en...
No you do not need to use anything proprietary to use WebAuthn. There are open source software[0] and hardware keys[1].
[0]: https://github.com/psanford/tpm-fido
[1]: https://solokeys.com/
[0]: https://github.com/psanford/tpm-fido
[1]: https://solokeys.com/
WebAuthn supports attestation of key storage and site owners might choose not to trust keys coming from an unknown DIY device.
Fortunately that feature isn't used outside of enterprise environments. Apple's passkeys don't support it so there will not be any mainstream adoption for requiring an attestation cert.
Assuming desktop Chrome doesn’t support third party password managers like 1Password and Lastpass that are similarly part of the FIDO alliance.
Passkeys aren’t a Chrome feature they’re a Webauthn feature. So if Chrome doesn’t provide the features you want on your platform you should be able to use another browser / password manager combo that does.
Passkeys aren’t a Chrome feature they’re a Webauthn feature. So if Chrome doesn’t provide the features you want on your platform you should be able to use another browser / password manager combo that does.
Do you use SSH keys?
This is SSH keys for signing into websites.
Which, yes, means you need at least one device in your possession containing your private keys.
1Password has already announced support for storing and syncing passkeys. Apple and Google also allow you to sync them via your account.
Nothing ties it specifically to your phone compared to any of your other devices or an online account/vault that you store your keys in.
This is SSH keys for signing into websites.
Which, yes, means you need at least one device in your possession containing your private keys.
1Password has already announced support for storing and syncing passkeys. Apple and Google also allow you to sync them via your account.
Nothing ties it specifically to your phone compared to any of your other devices or an online account/vault that you store your keys in.
> This is SSH keys for signing into websites.
No it's not. It's a shackle that will tie users to two or three platform providers (Google, Apple, and Microsoft) because websites will refuse to interoperate with implementations that aren't from those.
"Your browser is currently unsupported. To log in to your Amazing Bank account, open this website on your Android or iOS phone and place your finger on the home button."
Just because the underlying cryptographic primitives are similar to SSH, doesn't mean this will work anything like SSH in practice.
No it's not. It's a shackle that will tie users to two or three platform providers (Google, Apple, and Microsoft) because websites will refuse to interoperate with implementations that aren't from those.
"Your browser is currently unsupported. To log in to your Amazing Bank account, open this website on your Android or iOS phone and place your finger on the home button."
Just because the underlying cryptographic primitives are similar to SSH, doesn't mean this will work anything like SSH in practice.
Rubbish. This is literally WebAuthn, a completely open standard. There is no hidden secret sauce here, proprietary vendor lock-in, nothing.
We’ve had the functionality forever with Yubikey and so on, the difference is the tight integration with these common platforms making for ease of use.
The website you are accessing knows nothing about your device, it’s just doing a protocol dance. You can do it too! I’m sure someone will create a crap, insecure, WebAuthn client so that you can keep using your passwords.
We’ve had the functionality forever with Yubikey and so on, the difference is the tight integration with these common platforms making for ease of use.
The website you are accessing knows nothing about your device, it’s just doing a protocol dance. You can do it too! I’m sure someone will create a crap, insecure, WebAuthn client so that you can keep using your passwords.
I look forward to using that crap insecure WebAuthn client. A private key I don't control is a much bigger security issue than a compromised password will ever be. Google currently has no plans of supporting linux for "Local user verification" or "Passkey sync". If it was a truly open standard, I don't see why that would be the case. Needing to use a Google account is the definition of propriety vendor lock-in. Relying on specific hardware is the reason why I haven't embraced Yubikeys.
I understand the assumption that the general population doesn't care to and shouldn't need to worry about managing their private keys. But there's nothing secure about not giving me the option to, if I want to.
https://developers.google.com/identity/passkeys/supported-en....
I understand the assumption that the general population doesn't care to and shouldn't need to worry about managing their private keys. But there's nothing secure about not giving me the option to, if I want to.
https://developers.google.com/identity/passkeys/supported-en....
> The website you are accessing knows nothing about your device,
That is not correct. WebAuthn supports attestation of a hardware key storage, which means site operators can refuse to accept your keys unless you use a device from a white list.
That is not correct. WebAuthn supports attestation of a hardware key storage, which means site operators can refuse to accept your keys unless you use a device from a white list.
So websites will have whitelisted platform support instead of using the Webauthn / FIDO standard that Google, Apple, Microsoft, 1Password, and others are supporting?
They'll be using the standard AND whitelisting browsers. Just like some WebRTC-based services used to tell you "your browser is unsupported" when opened in Firefox, but spoofing the user agent to look like Chrome made everything magically work (Hangouts was a famous example IIRC, though they've since added official Firefox support).
I can print out my SSH key and store it in a safe, or freely copy it between systems. All of these services are intended to prevent that by using on device secure enclave functionality and the like - it puts control the keys out of my reach.
But you should be able to use your own password manager that can export them if you choose. I could be wrong but I don't think the standard requires that the keys are stored out of user reach.
> I could be wrong but I don't think the standard requires that the keys are stored out of user reach.
It really doesn't matter what the standard requires when the most popular implementations belong to companies like Google or Apple, they will get to decide how it works.
It really doesn't matter what the standard requires when the most popular implementations belong to companies like Google or Apple, they will get to decide how it works.
So you think Google and Apple will block third party password managers from providing passkeys to the browser?
Not quite, but close. They'll convince website owners that for "security reasons", they should refuse passkeys that came from third-party password managers or anything else open source, and instead only accept ones that came from something remotely attestable to be theirs.
Let me get this straight. . . You think Google will provide hooks for password managers in Chrome and Android, and then “convince” website owners, presumably via super bowl ads or something, to detect and filter out passkeys coming from the password managers they did the work to enable?
The way I interpret it, the worry is that something happens that allows Google, Apple, Microsoft, or some other password aggregator to take advantage of a perfect storm event (whether real or manufactured surreptitiously).
An example situation that comes to mind most easily would be some password aggregator having passwords stolen without realizing it. Let's assume that there's some backdoor or vulnerability in at least one system that allows bulk downloading of unencrypted username/password pairs and contact information. Then let's say a kid gets hold of that and thinks it might be funny to bulk send everyone's passwords to all of their contacts.
The password aggregator that has a truck driven through its security hole hopefully looses business. But then Google, Apple, Microsoft, etc., say something to the effect of...
"See? You really can't trust *anyone* but us. We are truly perfect and without any more truck holes of course. If people really wanted independent 2-factor authentication, they would have used it! Lots of people didn't, and look what happened. We need to save people from themselves!"
...Then the hooks come out.
An example situation that comes to mind most easily would be some password aggregator having passwords stolen without realizing it. Let's assume that there's some backdoor or vulnerability in at least one system that allows bulk downloading of unencrypted username/password pairs and contact information. Then let's say a kid gets hold of that and thinks it might be funny to bulk send everyone's passwords to all of their contacts.
The password aggregator that has a truck driven through its security hole hopefully looses business. But then Google, Apple, Microsoft, etc., say something to the effect of...
"See? You really can't trust *anyone* but us. We are truly perfect and without any more truck holes of course. If people really wanted independent 2-factor authentication, they would have used it! Lots of people didn't, and look what happened. We need to save people from themselves!"
...Then the hooks come out.
Standards like WebAuthn support attestation of a key storage, so the site can see who has manufactured it and can choose not to trust weird DIY or open source solutions without an attestation certificate.
Google convinces website owners of things all the time. Remember how AMP became popular because otherwise Google lowered your website's ranking?
Yes, I do.
That would be strange, given that Passkeys are just Webauthn tokens synchronized across devices. I don't know of a single application that only supports one vendor of Webauthn token, and I don't see that changing soon.
That's strange and would be a pretty big about-face.
Apple, the most locked-down and proprietary OS vendor, has great support for third party password managers in their OSes and has been improving that support in recent years.
If they kick 1Password etc. out of the Mac/iOS ecosystem that would be a pretty big deal. It could happen, but why would they do so?
Apple, the most locked-down and proprietary OS vendor, has great support for third party password managers in their OSes and has been improving that support in recent years.
If they kick 1Password etc. out of the Mac/iOS ecosystem that would be a pretty big deal. It could happen, but why would they do so?
It is bad when the dependency is phone only. Example: 2FA codes based on HOTP/TOTP are printable & exportable already, and you could use them on an external devices that are not a phone.
Passkeys are based on FIDO standards, so I believe a phoneless approach should work as well, given the proper device is available.
The bad part is that plenty of bad implementations exist for such external devices. For 2FA many, too many places allow just one device "for security" - which is total bs, of course. This was true for AWS until a couple of years ago, I didn't check this recently.
Google and Github get this right; but a lot of other parties just don't.
Passkeys are based on FIDO standards, so I believe a phoneless approach should work as well, given the proper device is available.
The bad part is that plenty of bad implementations exist for such external devices. For 2FA many, too many places allow just one device "for security" - which is total bs, of course. This was true for AWS until a couple of years ago, I didn't check this recently.
Google and Github get this right; but a lot of other parties just don't.
Imagine when google bans you like people get banned off Twitter…
“sorry your keys were revoked on chrome for an attempted search on an unauthorized topic” (so you can no longer access your bank website)
I imagine it’ll even get more dystopian as mistakes / bugs will happen and Google has no tech support
“sorry your keys were revoked on chrome for an attempted search on an unauthorized topic” (so you can no longer access your bank website)
I imagine it’ll even get more dystopian as mistakes / bugs will happen and Google has no tech support
Then don’t store/sync your passkeys with Google.
That makes this an even worse idea. Imagine losing everything because your phone gets stolen.
Phone insurance should become real very soon.
Phone insurance should become real very soon.
Or use something like 1Password, LastPass, or any other password manager that ends up supporting Passkeys.
I use KeePassXC specifically so that I can publish my encrypted database to the open Internet and access it anywhere, from any platform.
Someone else in this thread linked to Webauthn supporting coming for KeePassXC.
Hopefully we end up with a variety of password manager options that support these standards and devices/browsers that allow you to use your own password manager for the passkey flow.
Hopefully we end up with a variety of password manager options that support these standards and devices/browsers that allow you to use your own password manager for the passkey flow.
Until my bank starts offering an alternative to - screams of terror - SMS verification, KeePassXC currently serves all my needs.
(It also allows unlimited TOTP accounts, unlike things like Yubikey which only support up to, like, 30?)
(It also allows unlimited TOTP accounts, unlike things like Yubikey which only support up to, like, 30?)
Who’s going to write the software to read those keys and validate them?
Google and apple. That’s it.
Google and apple. That’s it.
> Basically am I the only one who doesn't think phone is my life and I don't want my life to be over if I lose my phone?
A huge percentage of internet users today don't own any devices other than their phone and most big corporations like Google want that percentage to become 100% in the near future because it's within their best interests if users have no control whatsoever over the device they rely on to live their life.
A huge percentage of internet users today don't own any devices other than their phone and most big corporations like Google want that percentage to become 100% in the near future because it's within their best interests if users have no control whatsoever over the device they rely on to live their life.
I don't know where you get the idea that a mobile device is needed
"A passkey doesn't leave your mobile device when signing in like this. Only a securely generated code is exchanged with the site so, unlike a password, there's nothing that could be leaked."
How to circumvent this in order to store the "passkey" in a regular password manager on the same desktop machine, not an external mobile device, so you can do proper backups of it and need no secondary device?
NOTICE: I am aware of the security implications. I don't care about them. I don't want any locked-down hardware to prevent me from accessing my own keys. I want control of my own keys.
How to circumvent this in order to store the "passkey" in a regular password manager on the same desktop machine, not an external mobile device, so you can do proper backups of it and need no secondary device?
NOTICE: I am aware of the security implications. I don't care about them. I don't want any locked-down hardware to prevent me from accessing my own keys. I want control of my own keys.
Linux users be damned: "Chrome on Linux doesn't support passkeys with a built-in platform authenticator. Linux users can use passkeys from another device such as an Android phone or an iPhone by scanning a QR code."
No plans to support it either [1] https://developers.google.com/identity/passkeys/supported-en...
No plans to support it either [1] https://developers.google.com/identity/passkeys/supported-en...
It's remarkably tragic how modern computer security regimes favor authoritarian centralized control so absolutely over allowing any flexibility or user choice or say.
> or any other password manager that supports passkeys
Hopefully they will allow third party password managers to provide these to the desktop browser, even on Linux. This seems to be how 1Password etc. are planning to support passkeys.
Hopefully they will allow third party password managers to provide these to the desktop browser, even on Linux. This seems to be how 1Password etc. are planning to support passkeys.
Fido keys work just fine on linux. There's already a fido authenticator that protects your keys using the system's TPM[0].
[0]: https://github.com/psanford/tpm-fido
[0]: https://github.com/psanford/tpm-fido
Thanks but a Fido device and/or TPM is NOT a solution:
It's precisely why my original comment says "I don't want any locked-down hardware to prevent me from accessing my own keys".
It's precisely why my original comment says "I don't want any locked-down hardware to prevent me from accessing my own keys".
There are software only Fido implementations.
Considering the Linux weirdos have equated a secure enclave with an overreach of kafkaesque proportion into their computer, I wouldn't hold my breath.
That's an unfair, hasty generalization of people who use Linux.
You just use your phone. Because otherwise you need a ton of OS integration to make this work, which I guess Linux doesn’t really care about (at least for now).
I think black box OS integration defeats the point of security. If I can't access and manage the private keys myself, it's effectively a black box implementation.
Which is precisely the point of all this. You won't be able to log in to your bank without a smartphone, and since the bank's website will only be tested with Google's and Apple's implementations (which of course will slightly deviate from the actual standard), everyone who doesn't use those two platforms will be locked out.
I can't realistically see banks forcing passkey based authentication. If this is actually an open standard, why would it matter if only Google's or Apple's implantation are tested.
If only Google and Apple's implementations work, then it's not an open standard.
If only Google and Apple's implementations work, then it's not an open standard.
That's quite cynical. Neither Google nor Apple profits from their password management solutions. It's in their best interest that people use passkeys to keep their accounts secure. Less support staff for $MEGACORP, simpler logins for the masses. It's a win for everyone that doesn't have malicious intent.
> Neither Google nor Apple profits from their password management solutions.
Not directly, no. But they absolutely do profit from the fact that it's becoming increasingly difficult to lead a normal life without owning an Android or iOS device. And every development like this, where another layer of complexity is introduced with the mobile vendors leading the way, ultimately serves that goal.
It's pretty much universally understood that building a browser engine from scratch is already no longer possible. Once Mozilla gives up, it's over. The systems that govern our lives will then be completely controlled by two or three corporate entities. Every new "web standard" makes Gecko more expensive to maintain. At some point, it will become too expensive.
Many people don't seem to understand this, including in this very thread. It doesn't matter that it's an open standard. The "standard creep" alone will eventually wipe out anyone who doesn't have a development budget that's measured in the billions of dollars.
Not directly, no. But they absolutely do profit from the fact that it's becoming increasingly difficult to lead a normal life without owning an Android or iOS device. And every development like this, where another layer of complexity is introduced with the mobile vendors leading the way, ultimately serves that goal.
It's pretty much universally understood that building a browser engine from scratch is already no longer possible. Once Mozilla gives up, it's over. The systems that govern our lives will then be completely controlled by two or three corporate entities. Every new "web standard" makes Gecko more expensive to maintain. At some point, it will become too expensive.
Many people don't seem to understand this, including in this very thread. It doesn't matter that it's an open standard. The "standard creep" alone will eventually wipe out anyone who doesn't have a development budget that's measured in the billions of dollars.
Google Password Manager, and the Apple equivalent, backup the passkeys for you. How they do this is fairly complicated. https://security.googleblog.com/2022/10/SecurityofPasskeysin...
You don’t have control of your keys exactly, but Google can’t see your keys either and you can survive device theft/failure and transfer to a new device. So it’s pretty good in my opinion.
You don’t have control of your keys exactly, but Google can’t see your keys either and you can survive device theft/failure and transfer to a new device. So it’s pretty good in my opinion.
If I don't control my keys, they are not my keys. It seems more limiting and worse in practice than what it's supposed to be improving on. Google already encrypts my password in password manager, it already can't see my password and can't generate my 2 factor. Being fairly complicated is not a good excuse to let Google manage the keys for me.
WebAuthn is a huge improvement from a security perspective. The private key is an anchor to a combination of factors. Proof of ownership (I have the device), proof of person (biometric) and/or proof of knowledge (pin code). Your password is not protected, it’s transmitted when you use it. If you’re infected with malware, that’s it, password exposed. With WebAuthn, nothing can be exposed.
> With WebAuthn, nothing can be exposed.
With solution proposed by Google, the keys are stored on the phone. If an attacker gains access to the phone using one of numerous vulnerabilities in Linux kernel, they can bypass any biometric locks. And PINs are short, so they can be easily bruteforced.
The better solution is a physical hardware key that doesn't have tens of megabytes of ponentially vulnerable code and is not controlled by Google.
With solution proposed by Google, the keys are stored on the phone. If an attacker gains access to the phone using one of numerous vulnerabilities in Linux kernel, they can bypass any biometric locks. And PINs are short, so they can be easily bruteforced.
The better solution is a physical hardware key that doesn't have tens of megabytes of ponentially vulnerable code and is not controlled by Google.
It is a physical hardware key (inside the device). It leverages the “Secure Enclave” or “TPM”. There’s no Google code involved.
I cannot agree with this. First, as I understand, many Android phones do not have a TPM, they use "Trusted Execution Environment" instead. Second, Google can transfer private keys from device to Google cloud which means that if you can get root access to the phone, you can extract the keys using the same method.
I think you are more correct than I am on this. There is some mechanism that attempts to prevent the private key from being exposable when going from device to device, but how exactly does it work? You could imagine the trust chain working by taking device 2 and encrypting the private key with its public key. But I can’t see any truely secure mechanism for cloud backup that doesn’t involve “please trust me”. I suppose the trusted compute environment may refuse to expose the key without a verified public key chained back to an embedded list of authorities (to encrypt the key). Still, that would be relying on trusting Google/Apple. (Stops the hacker who has your device, but doesn’t stop the gov who can legislate stuff for Google to do). I should dig some more to figure out exactly what they are doing.
That is the purpose of 2 factor. 2 factor + password matches those same goals. I am not worried about transmitting my password on a device I own to a website I trust. If I am infected with malware, my 2 factor and separate login recovery email will keep me safe. I understand the theory of using SSH like public private keys to move one step away from passwords, but the reality is if I don't have control over the private keys, they are not my keys. Not having control over my private keys outweighs any benefits I would get from using WebAuthn.
Then use your own password manager that supports passkeys?
You’re doing the free beer versus free speech semantics thing.
I am not sure I understand what you mean. An open standard requires interoperability with all other implementations. No one is discussing the cost of anything.
Sorry, that wasn’t clear. I meant, you are pivoting the definition of “my keys” to a different principle even though it’s the same words.
Same way people can argue endlessly about whether copyrighted software given away for $0 is “free” by defining “free” differently, there can be endless debate about “my keys” among those who define the term differently.
To me, “my keys” are the materials I need to access something. If I rent an apartment, they are still my keys even though I eventually need to return them. Your framing is about ultimate control over the materials rather than their use, so presumably you’d say those apartment keys are not really yours. Both can be right but it becomes a semantic disagreement rather than a substantive one.
Same way people can argue endlessly about whether copyrighted software given away for $0 is “free” by defining “free” differently, there can be endless debate about “my keys” among those who define the term differently.
To me, “my keys” are the materials I need to access something. If I rent an apartment, they are still my keys even though I eventually need to return them. Your framing is about ultimate control over the materials rather than their use, so presumably you’d say those apartment keys are not really yours. Both can be right but it becomes a semantic disagreement rather than a substantive one.
The article doesn't specify how the backup is encrypted, but it says that in can be decrypted with a PIN or unlock pattern. These are weak keys and can be easily bruteforced by Google.
Also if you get banned from Google then you might lose access to your keys.
Also if you get banned from Google then you might lose access to your keys.
They can only be decrypted on the device with the TPM. Google would need to have your device.
I think that you are wrong. The blog post [1] says:
> In some cases, for example, when the older device was lost or damaged, users may need to recover the end-to-end encryption keys from a secure online backup.
> To recover the end-to-end encryption key, the user must provide the lock screen PIN, password, or pattern of another existing device that had access to those keys.
This clearly states that you don't need original device to decrypt the keys: you only need a backup and a PIN code or unlock pattern which are easy to bruteforce.
[1] https://security.googleblog.com/2022/10/SecurityofPasskeysin...
> In some cases, for example, when the older device was lost or damaged, users may need to recover the end-to-end encryption keys from a secure online backup.
> To recover the end-to-end encryption key, the user must provide the lock screen PIN, password, or pattern of another existing device that had access to those keys.
This clearly states that you don't need original device to decrypt the keys: you only need a backup and a PIN code or unlock pattern which are easy to bruteforce.
[1] https://security.googleblog.com/2022/10/SecurityofPasskeysin...
> of another existing device that had access to those keys
Doesn’t that mean you have to be able to log in to a device that has the keys stored locally? I did not take that to mean you can just give google the pin and they can provide the keys.
Doesn’t that mean you have to be able to log in to a device that has the keys stored locally? I did not take that to mean you can just give google the pin and they can provide the keys.
Also, on Android instead of real TPM they often use a Trusted Execution Environment, which is basically a CPU mode.
How are you supposed to make use of those backups if Google decides to unperson you?
KeePassXC already has a development branch where WebAuthn is supported in both extension and KeePassXC, so the keys will be stored to your database and can be exported/imported normally. The support needs to be extended and tested for Passkeys also. So yes, controlling your own keys is possible. Browsers just wanted users to use their own walled gardens.
It sounds like you just want to continue randomly generated passwords, instead of passkeys? They seem to already solve exactly your problem?
Yes. But Google wants people to make a "transition", so I assume they will not allow passwords at some point in the future.
If that is ever the case, which I honestly think is doubtful (though I could be wrong), given that it's an open standard, I don't think there's anything preventing people from writing a passkey implementation that saves the secret key material in a plain file or anything similar. It likely already exists.
Sure, but that works for passwords because you can copy-paste them from an external program. The WebAuthn API in question is built around using JS in the website's context to manipulate the passkey. [1] You have to hope that the browser gives a way for an external program to be involved in that JS API's implementation.
Looking at KeepassXC's WebAuthn WIP implementation, it works by injecting JS into the website context that overrides the default JS API to its own implementation instead. [2] I don't see any API in the chrome extensions docs [3] that could be used to customize passkeys, so I assume 1Password's passkey implementation (mentioned in other comments in this thread) does the same thing. I sure hope the browsers don't decide to crack down on it by making the API uninterceptable in the name of security.
[1]: https://web.dev/passkey-registration/#call-webauthn-api-to-c...
[2]: https://github.com/keepassxreboot/keepassxc-browser/commit/4...
[3]: https://developer.chrome.com/docs/extensions/reference/
Looking at KeepassXC's WebAuthn WIP implementation, it works by injecting JS into the website context that overrides the default JS API to its own implementation instead. [2] I don't see any API in the chrome extensions docs [3] that could be used to customize passkeys, so I assume 1Password's passkey implementation (mentioned in other comments in this thread) does the same thing. I sure hope the browsers don't decide to crack down on it by making the API uninterceptable in the name of security.
[1]: https://web.dev/passkey-registration/#call-webauthn-api-to-c...
[2]: https://github.com/keepassxreboot/keepassxc-browser/commit/4...
[3]: https://developer.chrome.com/docs/extensions/reference/
Browsers should definitely give developers an open API for WebAuthn/Passkeys instead of relying on dirty inject hacks. For now, injecting is the only way to get it to work. Unless you modify the password manager itself to disguise itself as an USB authenticator device.
use a browser that honors user freedom
the whole problem boils down to this
this thread is full of people already anxious of this new thing because they rightfully see this as one more step toward total loss of user control/freedom (which wouldn't be if people trusted their browser vendor, etc)
the whole problem boils down to this
this thread is full of people already anxious of this new thing because they rightfully see this as one more step toward total loss of user control/freedom (which wouldn't be if people trusted their browser vendor, etc)
Which browser lets arbitrary processes plug into the passkey JS API?
(I do use a browser that respects my freedom - firefox. Well, firefox with lots of user.js overrides. But the choice of passkey usage is up to websites, not the browser, so the answer can't be "Don't use websites that require passkeys.")
(I do use a browser that respects my freedom - firefox. Well, firefox with lots of user.js overrides. But the choice of passkey usage is up to websites, not the browser, so the answer can't be "Don't use websites that require passkeys.")
How can you prevent a website from having a form field that you put data into?
They probably mean not allowing passwords for Google services.
That doesn't prevent leaking, which can matter even if it's unique password.
What does, under these constraints?
1Password has announced support for PassKeys:
https://www.future.1password.com/passkeys/
It would make sense that other password managers could also manage PassKeys as long as they have an extension to integrate with the browser.
https://www.future.1password.com/passkeys/
It would make sense that other password managers could also manage PassKeys as long as they have an extension to integrate with the browser.
You don't have to use a mobile device; you can just generate a passkey on a desktop machine.
Unless you're using Linux.
https://developers.google.com/identity/passkeys/supported-en...
https://developers.google.com/identity/passkeys/supported-en...
You can use an opensource fido key implementation on linux though.
you could also buy a hardware key like a Yubikey
"I don't want any locked-down hardware to prevent me from accessing my own keys."
Annoying points with passkey is that one way or another, your creds (ie the passkey) has to stay on your device/app or you are fucked.
Good thing with password is that you can have it not stored on any device and just used when you need. Gives you plausible deniability.
Also, now your chrome passkey/password manager has all your creds. Protected only with a single thing (password/biometry). Imagine your are at the Chinese or US border, and tsa is overreaching: with just your finger they can access to all your accounts: Facebook, twitter, Google, Dropbox, ...
You can't temporary delete from a device and readd without redoing the whole setup with the website. To create a passkey on Chrome for Android, you need the Google Play services beta. Otherwise the call to navigator.credentials.create() below will fail.
You see it the moment where apps and websites will not work without the Google play ecosystem just before they added a new lock in?
Also, I can see in advance that most website will only accept a single passkey public key per account. So you can't have one on each of your devices or even easily randomly connect from different web browser to the same site.
Also, now your chrome passkey/password manager has all your creds. Protected only with a single thing (password/biometry). Imagine your are at the Chinese or US border, and tsa is overreaching: with just your finger they can access to all your accounts: Facebook, twitter, Google, Dropbox, ...
You can't temporary delete from a device and readd without redoing the whole setup with the website. To create a passkey on Chrome for Android, you need the Google Play services beta. Otherwise the call to navigator.credentials.create() below will fail.
You see it the moment where apps and websites will not work without the Google play ecosystem just before they added a new lock in?
Also, I can see in advance that most website will only accept a single passkey public key per account. So you can't have one on each of your devices or even easily randomly connect from different web browser to the same site.
It's just jaw-dropping how naive passkey has been in trying to pretend browser implementers can do the right thing for users, when the vast epic & total security threats you describe are so readily & obviously apparent. The unwillingness to support real security keys as is the case with linux is just further fuel on the pyre of what a shit not-actually-pro-user attempt this new regime really is. It's all so mediated, so centralized, in big cloud shit.
There's this anti-user mania that users will fuck everything up so we absolutely cannot let them do things like export keys. But this chicken-little sky-is-falling pretense just keeps being an excuse for bad tradeoffs that in no way favor real actual people at all.
There's this anti-user mania that users will fuck everything up so we absolutely cannot let them do things like export keys. But this chicken-little sky-is-falling pretense just keeps being an excuse for bad tradeoffs that in no way favor real actual people at all.
Maybe we're having different experiences on the web, but I've found that there is _significantly_ better support for security keys on the web than there is for Passkeys. Many sites will give the option to use either but only registering security keys actually works.
Or use a third party password manager where you can export the keys to some other storage if you wish, or apply other security measures to access those keys?
Last but not least, now, even in private browsing the public key used could easily tell which device you are using.
How so?
You will probably have one public/private key set per device or browser to be able to connect to the website.
At the opposite, if you share your private keys on all your devices with probably automatic sync. It might defeat it's purpose in term of security. Imagine if you were to copy your ssh private key on all your machines instead of having one per device.
Now, if I'm trying to connect with public key 1234 to Facebook, it will be that I'm connecting from my home computer Firefox. If I try to connect with public key 6754, then I'm definitely on my work computer chrome.
At the opposite, if you share your private keys on all your devices with probably automatic sync. It might defeat it's purpose in term of security. Imagine if you were to copy your ssh private key on all your machines instead of having one per device.
Now, if I'm trying to connect with public key 1234 to Facebook, it will be that I'm connecting from my home computer Firefox. If I try to connect with public key 6754, then I'm definitely on my work computer chrome.
Well yes, the site you are signing into would know which key pair you are using.
But that isn’t shared across websites so I’m not sure that’s any violation of privacy.
But that isn’t shared across websites so I’m not sure that’s any violation of privacy.
Facebook will know that you for sure that you connected from a new computer/ phone. Facebook will know that you are on your iphone A. Facebook will know for sure that you are on the computer (work) were you look at funky business pages...
Even if less dangerous, your employer will know for sure that you connected from your personal computer to download X from Google workspace or specific work site even if nothing was explicitly setup for you like a VPN.
Even if less dangerous, your employer will know for sure that you connected from your personal computer to download X from Google workspace or specific work site even if nothing was explicitly setup for you like a VPN.
Facebook will know that you are on Device 1 or Device 2. They can already probably determine that via a combo of user agent, IP, and other fingerprinting. And if you want to use different accounts on the same device, Facebook wouldn’t know that it’s the same device.
Google already tracks which devices you are signed in on, and alerts you if you sign in from one that isn’t already trusted.
I’m not sure what the issue is here. It’s not like there is a device identifier that can correlate your device logins across different sites or services.
Google already tracks which devices you are signed in on, and alerts you if you sign in from one that isn’t already trusted.
I’m not sure what the issue is here. It’s not like there is a device identifier that can correlate your device logins across different sites or services.
They are other ways that you can fight, and officially browsers are adding feature to protect against them. But this add another level of fingerprinting. This is my point.
Fair enough, but unlike most fingerprinting techniques used for ad targeting this doesn’t correlate across different apps or websites.
And if it reduces the usage of systems like “Sign in with Facebook” or “Sign in with Google” across sites then that is also a privacy win.
And if it reduces the usage of systems like “Sign in with Facebook” or “Sign in with Google” across sites then that is also a privacy win.
Another terrible thing coming to my mind, by definition you will probably not have 2fa when you connect with passkey.
So, now think about Google chrome feature of "backup user passwords" that they always try to have user enable automatically without noticing. And that is not e2e encrypted so they can access any of them along with your wifi passwords.
Will they not save the passkey there for sync with other chromes? Because otherwise it will be directly game over for the normal user. Any google employee or gov or hacker will be able to connect to your accounts even without 2fa. A lot better for them that the current situation with passwords and 2fa.
So, now think about Google chrome feature of "backup user passwords" that they always try to have user enable automatically without noticing. And that is not e2e encrypted so they can access any of them along with your wifi passwords.
Will they not save the passkey there for sync with other chromes? Because otherwise it will be directly game over for the normal user. Any google employee or gov or hacker will be able to connect to your accounts even without 2fa. A lot better for them that the current situation with passwords and 2fa.
You still have 2 factors:
- Something you own, your device with a passkey on it
AND
- Something you are, your biometrics
OR
- Something you know, your PIN
Either of which you need, at least in every single implementation of passkeys I've used.
- Something you own, your device with a passkey on it
AND
- Something you are, your biometrics
OR
- Something you know, your PIN
Either of which you need, at least in every single implementation of passkeys I've used.
The pin or biometrics is just in the client side, let's say to decipher the private key before usage. No?
Probably even not an encrypted key but just to protect your local passkey holder.
I don't think that any of this is sent to the website.
Probably even not an encrypted key but just to protect your local passkey holder.
I don't think that any of this is sent to the website.
It’s still required to complete authentication. If you don’t present one of them, your authenticator will not function. It’s used to unlock the private key.
It’s not the website confirming your second factor, but the Authenticator. And that’s on purpose; I don’t think I’d want a website being able to store a copy of my biometrics.
It’s not the website confirming your second factor, but the Authenticator. And that’s on purpose; I don’t think I’d want a website being able to store a copy of my biometrics.
> It’s still required to complete authentication.
As I understand, if an attacker gains root access to your phone (or if an attacker is Google) then they can bypass any biometric locks, export private keys protected with a PIN and bruteforce the PIN. Phones allow exporting keys to sync them between devices via Google cloud. So Google or their friends from government can bruteforce PINs for backups stored in their cloud.
Please correct me if I am wrong, but this looks like a single factor.
As I understand, if an attacker gains root access to your phone (or if an attacker is Google) then they can bypass any biometric locks, export private keys protected with a PIN and bruteforce the PIN. Phones allow exporting keys to sync them between devices via Google cloud. So Google or their friends from government can bruteforce PINs for backups stored in their cloud.
Please correct me if I am wrong, but this looks like a single factor.
So they have something you own, they broke into your phone, and they have something you know, they brute forced your PIN.
How is that not still 2FA?
If someone breaks into your computer and you happen to have written down all your 2FA setup codes in a text file, you’re still using 2FA even though they now have access to your codes.
I don’t fully know the mechanics of the Secure Enclave or Android equivalent but I would be surprised if it allowed exporting private keys without some form of authentication, separate from unlocking your phone. You have to reauthenticate each time you use your passkey, likely on purpose.
How is that not still 2FA?
If someone breaks into your computer and you happen to have written down all your 2FA setup codes in a text file, you’re still using 2FA even though they now have access to your codes.
I don’t fully know the mechanics of the Secure Enclave or Android equivalent but I would be surprised if it allowed exporting private keys without some form of authentication, separate from unlocking your phone. You have to reauthenticate each time you use your passkey, likely on purpose.
Yes, but so it goes back to my point. If Google cloud is storing your private key, probably not cyphered with your biometric because they would have also to backup your biometric data to backport on the other device. So they have everything they need to use it pretending to be you with your device.
What? No.
It stores your private key, which is per site. You use your biometrics to unlock it and sign in.
If you upload your password protected SSH private key to Dropbox for safe keeping, a person will still need your password to use it even if they gain access to it. How is this any different?
It stores your private key, which is per site. You use your biometrics to unlock it and sign in.
If you upload your password protected SSH private key to Dropbox for safe keeping, a person will still need your password to use it even if they gain access to it. How is this any different?
Let's be clear, I think that you are mixing up what I mean by Google.
There is the android device on one side (that can have pin and biometric to uncypher the key).
And on the other side there is Google the cloud, where device passwords are currently possibly stored if you allowed it (accidentally or not). The goal is to have your passwords and I guess passkey being synchronized between your devices and easily setup with new devices. Very obviously they will not upload your biometric info. So we can assume that on the cloud side they can access your private keys. If either they are still protected with your pin, that would be easily crackable.
There is the android device on one side (that can have pin and biometric to uncypher the key).
And on the other side there is Google the cloud, where device passwords are currently possibly stored if you allowed it (accidentally or not). The goal is to have your passwords and I guess passkey being synchronized between your devices and easily setup with new devices. Very obviously they will not upload your biometric info. So we can assume that on the cloud side they can access your private keys. If either they are still protected with your pin, that would be easily crackable.
Whether it’s easily crackable or not doesn’t take away from the fact that it is 2FA.
If someone broke into your computer and found a file called 2fa_setup_codes.txt and uploaded it to the internet, you’re still using 2FA. Just because the setup code is available for yourself or someone else to use doesn’t impact the technology. It’s still 2FA/MFA.
This is exactly equivalent.
And, sure, Google could do that. They certainly have the computing power to likely do that across their users. But what, exactly, is their incentive to do so? What makes this in any way shape or form realistic as opposed to paranoid delusions?
And, I mean, just don’t sync your passkeys if you are concerned about this. It seems like entirely a manufactured problem.
If someone broke into your computer and found a file called 2fa_setup_codes.txt and uploaded it to the internet, you’re still using 2FA. Just because the setup code is available for yourself or someone else to use doesn’t impact the technology. It’s still 2FA/MFA.
This is exactly equivalent.
And, sure, Google could do that. They certainly have the computing power to likely do that across their users. But what, exactly, is their incentive to do so? What makes this in any way shape or form realistic as opposed to paranoid delusions?
And, I mean, just don’t sync your passkeys if you are concerned about this. It seems like entirely a manufactured problem.
> Annoying points with passkey is that one way or another, your creds (ie the passkey) has to stay on your device/app or you are fucked. Good thing with password is that you can have it not stored on any device and just used when you need.
The key is just a bunch of random data used as a cryptographic private key. You could make an authenticator that argon2id's a passphrase to generate the private key, to go back to the world of passwords.
Meanwhile, the average person using passkeys will become immune to phishing.
The key is just a bunch of random data used as a cryptographic private key. You could make an authenticator that argon2id's a passphrase to generate the private key, to go back to the world of passwords.
Meanwhile, the average person using passkeys will become immune to phishing.
I realized I got prompted to start an enroll for this yesterday after reading this webpage. I reacted exactly like this first bullet point:
"Some users may be surprised if a biometric authentication suddenly appears on a website or an app and think this is sending sensitive information to the server. With passkeys, the user's biometric information is never revealed to the website or the app. Biometric material never leaves the user's personal device."
Having a notification asking me to enable Bluetooth immediately concerned me even though it was clearly the genuine prompt you get get when Google asks you to sign-in by accepting a prompt on a phone.
I don't see myself using this authentication over pass+2factor even though it should be safer because of 2 main reasons. I avoid turning or keeping Bluetooth on and I don't see a clear way to manually control and export the passkey private key. I understand that it's synced via the OS and Google's password manager, but I don't trust it unless I can back it up and restore it to a device myself.
Is there an open, Google independent implementation like Aegis is for 2 factor?
If I can't control and manage my private keys, it's not my private keys. The more I read about this, the less this feels like an improvement to pass+2 factor. Phishing attempts are easier because Banks don't allow non-sms tied 2 factor authentication.
Thinking of this like SSH key based authentication for website made the value of this clear for me. But I don't want my passkey dependent on my Google login.
https://developers.google.com/identity/passkeys
"Some users may be surprised if a biometric authentication suddenly appears on a website or an app and think this is sending sensitive information to the server. With passkeys, the user's biometric information is never revealed to the website or the app. Biometric material never leaves the user's personal device."
Having a notification asking me to enable Bluetooth immediately concerned me even though it was clearly the genuine prompt you get get when Google asks you to sign-in by accepting a prompt on a phone.
I don't see myself using this authentication over pass+2factor even though it should be safer because of 2 main reasons. I avoid turning or keeping Bluetooth on and I don't see a clear way to manually control and export the passkey private key. I understand that it's synced via the OS and Google's password manager, but I don't trust it unless I can back it up and restore it to a device myself.
Is there an open, Google independent implementation like Aegis is for 2 factor?
If I can't control and manage my private keys, it's not my private keys. The more I read about this, the less this feels like an improvement to pass+2 factor. Phishing attempts are easier because Banks don't allow non-sms tied 2 factor authentication.
Thinking of this like SSH key based authentication for website made the value of this clear for me. But I don't want my passkey dependent on my Google login.
https://developers.google.com/identity/passkeys
Nothing about passkeys needs to be tied to Google. You can use other password managers, and it seems like the major players are all supporting the same standard.
For example you can use 1Password: https://www.future.1password.com/passkeys/
If they can do it, other password managers both cloud and local should be able to do this as well.
For example you can use 1Password: https://www.future.1password.com/passkeys/
If they can do it, other password managers both cloud and local should be able to do this as well.
I look forward to that, but as it stands currently, only Google and Apple's password managers are supported. All of the support documents mention its tied to the OS and linux support isn't planned. The table on this page shows there are no plans of "Local user verification" or "Passkey sync" when using Linux.
Additionally it also states that to access the passkey, you need to log in to the given Google account.
"Passkeys generated in Chrome on Android are stored in the Google Password Manager. These passkeys are available on all other Android devices as long as Google Password Manager is available and the same user's Google account is signed in."
https://developers.google.com/identity/passkeys/supported-en....
Additionally it also states that to access the passkey, you need to log in to the given Google account.
"Passkeys generated in Chrome on Android are stored in the Google Password Manager. These passkeys are available on all other Android devices as long as Google Password Manager is available and the same user's Google account is signed in."
https://developers.google.com/identity/passkeys/supported-en....
Sure, if you want to use Chrome + Google password manager.
The linked article does say that they will support other password managers on Android at least. And Webauthn/FIDO can be implemented by other browsers and password managers as well.
If Google doesn't let third party password manager extensions on Chrome desktop provide passkey support, then that's pretty bad and we'll probably hear from 1Password and LastPass about it since they are also part of the FIDO alliance.
The linked article does say that they will support other password managers on Android at least. And Webauthn/FIDO can be implemented by other browsers and password managers as well.
If Google doesn't let third party password manager extensions on Chrome desktop provide passkey support, then that's pretty bad and we'll probably hear from 1Password and LastPass about it since they are also part of the FIDO alliance.
There are a number of opensource fido key implementations already. There will be opensource passkey implementations.
While WebAuthn is an open standard, but the fact that it explicitly provides attestation API [1][2] and related database that can be used to verify devices [3] is already worrying.
Site owners really have the option to lock you into one or a dozen of ecosystems should they decide to. It is entirely possible that your home-made hardware key or software password manager will be disallowed from logging into Google or Apple.
For example, Cloudflare actively uses the attestation feature [4] to replace captchas, and they probably only allow a few manufacturers.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...
[2] https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Gu...
[3] https://fidoalliance.org/metadata/
[4] https://blog.cloudflare.com/introducing-cryptographic-attest...
Site owners really have the option to lock you into one or a dozen of ecosystems should they decide to. It is entirely possible that your home-made hardware key or software password manager will be disallowed from logging into Google or Apple.
For example, Cloudflare actively uses the attestation feature [4] to replace captchas, and they probably only allow a few manufacturers.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...
[2] https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Gu...
[3] https://fidoalliance.org/metadata/
[4] https://blog.cloudflare.com/introducing-cryptographic-attest...
The problem with passkeys is that you need your phone to use them. The more it is adopted, the more likely technology will only work with them in the future. Thus, we will be more tied to our mobile devices. No thanks.
Why does it need a phone? It's like SSH keys, you just need access to your keys from where you are logging in.
They give the example of using your phone because that's a convenient portable key vault you may have with you. But if you want to keep your keys just on a desktop or in some other password manager that integrates with the browser I don't see any barrier to that. 1Password for example has already announced passkey support.
They give the example of using your phone because that's a convenient portable key vault you may have with you. But if you want to keep your keys just on a desktop or in some other password manager that integrates with the browser I don't see any barrier to that. 1Password for example has already announced passkey support.
Hmm, I didn't know that. Thanks! When I watched Apple's video on passkeys, it seemed to imply a phone was needed.
I don't believe you do. You just need an app that supports passkeys, but I could be wrong. The notice says that it integrates with other password managers.
[deleted]
Good to see this. Apple's WWDC video on Passkeys [1] has a good explanation of how passkeys work, including the nifty feature where you can use your phone to log in on a laptop without the laptop getting your credentials.
[1] https://developer.apple.com/videos/play/wwdc2022/10092/
[1] https://developer.apple.com/videos/play/wwdc2022/10092/
I don't see why I should be worried about storing and using credentials on my own devices. What would be the point, what threat does it protect against, and in what way is it more useful than using OAuth 2.0 "sign in with" feature?
The threat model: a device is stolen, the credentials there are poorly encrypted, credentials retrieved, used to access your bank account and siphon off all the funds.
That threat affects passkeys as well. If your device is stolen and in control of a third party, they would be able to use it to log-in and steal your money too.
The idea is to store the secret in some sort of a secure tamperproof system.
Yubikeys need a PIN to unlock.
Android, iOS, macOS, ChromeOS etc demand user to authenticate to unlock, with hardware TPM. The hardware limits number of guesses on PIN.
(Of course, you can throw all that security out the window by using a FIDO implementation that doesn't do that.)
Yubikeys need a PIN to unlock.
Android, iOS, macOS, ChromeOS etc demand user to authenticate to unlock, with hardware TPM. The hardware limits number of guesses on PIN.
(Of course, you can throw all that security out the window by using a FIDO implementation that doesn't do that.)
Logging into devices you don't own, for example.
I log in to devices I don't own using a password+2factor. I have a long but memorable password that I just type in. I don't have some obtuse password where I require a password manager to log-in, I refuse to use the suggested password that chrome generates. What is the point of a password I don't remember? I am going to link this helpful xkcd comic https://xkcd.com/936/ that was published August 10, 2011 that is still relevant.
If you type your password into a device you don’t own, what value is left in the password?
Shouldn’t you basically consider it compromised at that point?
If you rely on remembering your passwords, do you also keep them unique for every website?
Shouldn’t you basically consider it compromised at that point?
If you rely on remembering your passwords, do you also keep them unique for every website?
It’s easy to have memorable and unique passwords for every website. You just create a personal hash algorithm to derive a password from the site name.
For instance: number of letters in site name + second letter of site name in caps + last letter of site name + number of repeat letters in site name + (! if even number of letters, * if odd) + capitalized first letter
google.com = 6Oe1!G
bestbuy.com = 7Ey0*B
Longer rules than that, but once you remember than you can derive the password for any site. If an adversary gets a few of your passwords and the sites they’re for, it would be easy to crack the rules. But that’s not an attack vector that typical hackers are exploring.
For instance: number of letters in site name + second letter of site name in caps + last letter of site name + number of repeat letters in site name + (! if even number of letters, * if odd) + capitalized first letter
google.com = 6Oe1!G
bestbuy.com = 7Ey0*B
Longer rules than that, but once you remember than you can derive the password for any site. If an adversary gets a few of your passwords and the sites they’re for, it would be easy to crack the rules. But that’s not an attack vector that typical hackers are exploring.
I’ll give my grandma your number so you can walk her through this easy system the next time she needs to sign in.
Probably easier to just have me generate them and hold on to all of her passwords. She can call me when she needs a password.
I charge $20/month if it’s just social media and stuff. Free if it includes online banking.
Besides, I didn’t say this approach is right for everyone. For the HN crowd it should be easy.
I charge $20/month if it’s just social media and stuff. Free if it includes online banking.
Besides, I didn’t say this approach is right for everyone. For the HN crowd it should be easy.
And what's more nifty is that the phone can be Android or iOS, the laptop can be Windows or macOS and it will all work.
How is that different from password+2 factor? Logging-in is already platform independent.
Password+2 factor sends your password across the wire to the website, and trusts that website and the path between to handle it securely and not store or log it anywhere.
Passkey never sends your private key to the website you are signing in to.
Passkey never sends your private key to the website you are signing in to.
That's the purpose of the 2 factor. The "private key" used to generate the 5/6 digit pin stays on my device and isn't transmitted.
Well what if we got rid of the password and just used the private key part?
That's how SSH commits work on github. It's an option, but for complete multi-factor security passwords take care of the "something you know" factor. The factors "something you know" like a password, "something you are" like biometrics, along with "something you have" like a hardware authenticator that implements TOTP/HOTP.
But modern password best practices require long, unique passwords for each website.
Most users either don’t follow this, or use a password manager.
If you use a password manager, the “something you know” has become just another “something you have” like an SSH or 2 factor key.
Basically for good security practices, passwords are converging on becoming SSH keys except less secure since you trust the website (or any device that isn’t yours that you type them into) to not leak them.
At that point, what value is the password providing when you are always pairing it with an actual private key challenge?
Most users either don’t follow this, or use a password manager.
If you use a password manager, the “something you know” has become just another “something you have” like an SSH or 2 factor key.
Basically for good security practices, passwords are converging on becoming SSH keys except less secure since you trust the website (or any device that isn’t yours that you type them into) to not leak them.
At that point, what value is the password providing when you are always pairing it with an actual private key challenge?
The best practices about the length and uniqueness of passwords was based on the assumption that leaked passwords and rainbow tables could be used to compromise multiple accounts from a single compromise.
The current standard of storing salted passwords makes the uniqueness requirement of passwords meaningless. If companies don't properly salt passwords, then uniqueness and length became an issue again. Salted passwords are effectively the same as appending an SSH key to a chosen password and letting websites manage them. With properly salted passwords, even if everyone chose the exact same password, a compromised password database would be meaningless.
This is the reason why NIST changed its guidelines about how often a password should be reset. It also changed the guidelines for complexity rules of passwords.
"Q-B05: Is password expiration no longer recommended? A-B05: SP 800-63B Section 5.1.1.2 paragraph 9 states:
“Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”
Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations. But if there is evidence that the memorized secret has been compromised, such as by a breach of the verifier’s hashed password database or observed fraudulent activity, subscribers should be required to change their memorized secrets. However, this event-based change should occur rarely, so that they are less motivated to choose a weak secret with the knowledge that it will only be used for a limited period of time.
Q-B06: Are password composition rules no longer recommended? A-B06: SP 800-63B Section 5.1.1.2 paragraph 9 recommends against the use of composition rules (e.g., requiring lower-case, upper-case, digits, and/or special characters) for memorized secrets. These rules provide less benefit than might be expected because users tend to use predictable methods for satisfying these requirements when imposed (e.g., appending a ! to a memorized secret when required to use a special character). The frustration they often face may also cause them to focus on minimally satisfying the requirements rather than devising a memorable but complex secret. Instead, a blacklist of common passwords prevents subscribers from choosing very common values that would be particularly vulnerable, especially to an online attack.
Composition rules also inadvertently encourage people to use the same password across multiple systems since they often result in passwords that are difficult for people to memorize."
https://pages.nist.gov/800-63-FAQ/#q-b05
The current standard of storing salted passwords makes the uniqueness requirement of passwords meaningless. If companies don't properly salt passwords, then uniqueness and length became an issue again. Salted passwords are effectively the same as appending an SSH key to a chosen password and letting websites manage them. With properly salted passwords, even if everyone chose the exact same password, a compromised password database would be meaningless.
This is the reason why NIST changed its guidelines about how often a password should be reset. It also changed the guidelines for complexity rules of passwords.
"Q-B05: Is password expiration no longer recommended? A-B05: SP 800-63B Section 5.1.1.2 paragraph 9 states:
“Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”
Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations. But if there is evidence that the memorized secret has been compromised, such as by a breach of the verifier’s hashed password database or observed fraudulent activity, subscribers should be required to change their memorized secrets. However, this event-based change should occur rarely, so that they are less motivated to choose a weak secret with the knowledge that it will only be used for a limited period of time.
Q-B06: Are password composition rules no longer recommended? A-B06: SP 800-63B Section 5.1.1.2 paragraph 9 recommends against the use of composition rules (e.g., requiring lower-case, upper-case, digits, and/or special characters) for memorized secrets. These rules provide less benefit than might be expected because users tend to use predictable methods for satisfying these requirements when imposed (e.g., appending a ! to a memorized secret when required to use a special character). The frustration they often face may also cause them to focus on minimally satisfying the requirements rather than devising a memorable but complex secret. Instead, a blacklist of common passwords prevents subscribers from choosing very common values that would be particularly vulnerable, especially to an online attack.
Composition rules also inadvertently encourage people to use the same password across multiple systems since they often result in passwords that are difficult for people to memorize."
https://pages.nist.gov/800-63-FAQ/#q-b05
> If companies don't properly salt passwords, then uniqueness and length became an issue again.
Yes, that is my point. You are relying on the website to properly transmit, store, and (not) log your password.
If you do not use unique passwords, then a lapse in those practices at any site sharing the same password could compromise that password across every site you use it on.
If you type that password into an untrusted device, it could also be compromised for every site you use that password on.
With private key authentication the website never gets your private key so they can’t compromise it even if they have bad practices.
Yes, that is my point. You are relying on the website to properly transmit, store, and (not) log your password.
If you do not use unique passwords, then a lapse in those practices at any site sharing the same password could compromise that password across every site you use it on.
If you type that password into an untrusted device, it could also be compromised for every site you use that password on.
With private key authentication the website never gets your private key so they can’t compromise it even if they have bad practices.
2FA was created to guard against every single problem you mentioned. There is no concern that Aegis, which allows personal backups, management, and encrypted cloud backups of the secret keys. PKA where I don't control the private keys doesn't seem more safe. Especially since passkeys are being marketed as a replacement to TOTP.
Right, so if the actual security is coming from the 2FA key and the password part is untrusted, then again why bother with the password?
Also, does passkey necessarily mean you don’t control the private keys?
A specific implementation like Google Password Manager may not give you access to those keys, but others like 1Password or KeePass should.
Also, does passkey necessarily mean you don’t control the private keys?
A specific implementation like Google Password Manager may not give you access to those keys, but others like 1Password or KeePass should.
Webauthn is immune to phishing. The message sent to the server cryptographically depends on the target domain. With Webauthn, you can't be fooled into typing your password+2factor into gmai1.com.
This all seems really cool, but right now I'm just dreading when some site inevitably start forcing you to use it out of some misplaced desire to protect the user from themselves.
It's my account, it should be my choice whether to make the security/convenience tradeoff. Sometimes I just want to use a plain password, stick it in my web browser, and forget about it.
It's my account, it should be my choice whether to make the security/convenience tradeoff. Sometimes I just want to use a plain password, stick it in my web browser, and forget about it.
this entire comment section is so full of BS! People ranting about stuff they don't understand and coming up with random conspiracy theories that have no basis in reality
PassKeys are NOT proprietary. They're a standard. You can implement it yourself if you want or use several other implementations not run by FAMG.
Here's a video on how it works
https://www.youtube.com/watch?v=SWocv4BhCNg
* Can I share the keys between chrome, firefox, and safari?
You don't need to. That's not how it works. Chrome, Firefox, and Safari and every device will have a different key for the same service (see video)
* How do I share keys between different types of devices? (mac, ios, android, windows)
You don't. You authenticate and a new key is created on each device, possibly on each piece of software (Firefox, Chrome, Safari, App). To be more clear, when and if you decide to use a service from a new device or new browser you'll be asked if you want to login via passkey. If you have a passkey on another device you can (see video) use that to login from the other device (similar to how google asks viat the gmail app of you were trying to log into some other device or Apple asks across your device). After you authenticate you can then create a new passkey for this device/software you're using. This new passkey is separate from the previous passkey. You effectively have 2 passkeys now, one to login with one device/software, one to with a different device/software. (See video)
* What happens if my devices are gone?
You follow whatever recovery procedures the service has, just like if you forgot your password.
* What happens if I want to change my login (email to a new email for example)?
Unrelated. Your email is not shared with passkey. So login and set a new email
* What's the difference between a password and passkey?
A password can be use by any one from anywhere. A passkey can only be used with the piece of software/device it was associated with when created. A passkey is useless if stolen/leaked
PassKeys are NOT proprietary. They're a standard. You can implement it yourself if you want or use several other implementations not run by FAMG.
Here's a video on how it works
https://www.youtube.com/watch?v=SWocv4BhCNg
* Can I share the keys between chrome, firefox, and safari?
You don't need to. That's not how it works. Chrome, Firefox, and Safari and every device will have a different key for the same service (see video)
* How do I share keys between different types of devices? (mac, ios, android, windows)
You don't. You authenticate and a new key is created on each device, possibly on each piece of software (Firefox, Chrome, Safari, App). To be more clear, when and if you decide to use a service from a new device or new browser you'll be asked if you want to login via passkey. If you have a passkey on another device you can (see video) use that to login from the other device (similar to how google asks viat the gmail app of you were trying to log into some other device or Apple asks across your device). After you authenticate you can then create a new passkey for this device/software you're using. This new passkey is separate from the previous passkey. You effectively have 2 passkeys now, one to login with one device/software, one to with a different device/software. (See video)
* What happens if my devices are gone?
You follow whatever recovery procedures the service has, just like if you forgot your password.
* What happens if I want to change my login (email to a new email for example)?
Unrelated. Your email is not shared with passkey. So login and set a new email
* What's the difference between a password and passkey?
A password can be use by any one from anywhere. A passkey can only be used with the piece of software/device it was associated with when created. A passkey is useless if stolen/leaked
> What happens if my devices are gone? You follow whatever recovery procedures the service has, just like if you forgot your password
Are you sure? If so, why? Passkeys are advertised as a replacement for username + password + 2FA. Current practices generally allow for a password to be reset via email, but not MFA, as half the point of MFA is to protect against password resets. So the reset process for a passkey can’t be the same as a password otherwise you don’t have “real” MFA.
I feel that account recovery is either going to get a lot harder (eg KYC for what would have been previously been an email), or services will enforce additional data collection (eg phone number) to aid recovery. Neither of these are good.
Are you sure? If so, why? Passkeys are advertised as a replacement for username + password + 2FA. Current practices generally allow for a password to be reset via email, but not MFA, as half the point of MFA is to protect against password resets. So the reset process for a passkey can’t be the same as a password otherwise you don’t have “real” MFA.
I feel that account recovery is either going to get a lot harder (eg KYC for what would have been previously been an email), or services will enforce additional data collection (eg phone number) to aid recovery. Neither of these are good.
I don't see what benefits a passkey has over using a password+TOPT/HOTP 2 factor. It seems like this is trying to solve a problem that has been becoming less significant over the years as more and more people use 2 factor properly and websites properly salt passwords. The current marketing doesn't properly show the need for this. I am not worried about a single password compromise because I don't reuse passwords and there is no risk my non-sms 2FA being compromised.
It seem more like how I have to enroll my device to Duo if I want to use it for 2 factor to log in and Duo using a proprietary implementation locking me into their software. As it stands, despite this being an open standard, Google has made it clear it has no plans to add support to linux for "Local user verification" or "Passkey sync".
The idea that Google will one day push users to only use passkeys and phase out passwords isn't unfounded. It's clear that Google would be motivated to make such a push. The reason people are concerned is because using Google ties the passkey to your Google login. From what I recall, Google also used a proprietary method to generator TOTP/HOTP making it impossible to use third party authenticators to log in to Google. Google Authenticator is open sourced but hasn't been updated in over 2 years. I believe Aegis supports Google Accounts so it can be used instead of Authenticator.
I understand this from the more basic SSH authentication using a generated public/private key. I am also aware of Yubikeys, which are also open, but I have chosen to continue using passwords because I want complete control over my private keys.
This is informed and healthy concern for a new implementation of security protocols.
It seem more like how I have to enroll my device to Duo if I want to use it for 2 factor to log in and Duo using a proprietary implementation locking me into their software. As it stands, despite this being an open standard, Google has made it clear it has no plans to add support to linux for "Local user verification" or "Passkey sync".
The idea that Google will one day push users to only use passkeys and phase out passwords isn't unfounded. It's clear that Google would be motivated to make such a push. The reason people are concerned is because using Google ties the passkey to your Google login. From what I recall, Google also used a proprietary method to generator TOTP/HOTP making it impossible to use third party authenticators to log in to Google. Google Authenticator is open sourced but hasn't been updated in over 2 years. I believe Aegis supports Google Accounts so it can be used instead of Authenticator.
I understand this from the more basic SSH authentication using a generated public/private key. I am also aware of Yubikeys, which are also open, but I have chosen to continue using passwords because I want complete control over my private keys.
This is informed and healthy concern for a new implementation of security protocols.
I can see a benefit for users who don’t use password managers / 2FA, but I can’t see a benefit over a strong random password + TOTP. Only difference is that with a password + TOTP you’re in full control of both the password + recovery codes. So you can get your accounts back even if you lose access to your password manager. With passkeys you have no control over anything, so if you lose access to your password manager you’re finished. Seems worse.
> what benefits a passkey has over using a password+TOPT/HOTP 2 factor
The benefit is that you don't need to remember different password for each site. However, it seems that passkeys are not secure, can be stolen by an attacker with root access or silently decrypted by Google. The better solution is hardware keys independent from Google.
The benefit is that you don't need to remember different password for each site. However, it seems that passkeys are not secure, can be stolen by an attacker with root access or silently decrypted by Google. The better solution is hardware keys independent from Google.
I think passkeys can not be stolen for the same reason jailbreak a phone doesn't allow a user to access to extract touch-id data. For the same reason Google also can't access that information. But I don't see how the current concerns regarding pass+TOTP are mitigated without completely removing the ability to use a password+totp as a fallback. And if it is kept as a fallback, what do passkeys accomplish other than making your phone a bigger point of failure?
> I think passkeys can not be stolen for the same reason jailbreak a phone doesn't allow a user to access to extract touch-id data. For the same reason Google also can't access that information.
Google allows exporting keys to Google cloud and importing them onto another device. This means that keys can be exported from secure storage, and if Google can do that then an attacker also can. Google claims, that PIN code or unlock pattern might be required to recover keys from cloud backup, but those are easy to bruteforce.
This is not real hardware key that doesn't allow exporting private keys.
Google allows exporting keys to Google cloud and importing them onto another device. This means that keys can be exported from secure storage, and if Google can do that then an attacker also can. Google claims, that PIN code or unlock pattern might be required to recover keys from cloud backup, but those are easy to bruteforce.
This is not real hardware key that doesn't allow exporting private keys.
> They're a standard. You can implement it yourself
You can make your DIY authenticator, but websites might choose not to trust your self-signed attestation as it is not "secure".
Also, as I understand, passkeys stored on an Android phone can be stolen by an attacker with root access or by Google if you use biometric lock or PIN or lock pattern.
You can make your DIY authenticator, but websites might choose not to trust your self-signed attestation as it is not "secure".
Also, as I understand, passkeys stored on an Android phone can be stolen by an attacker with root access or by Google if you use biometric lock or PIN or lock pattern.
If you have to create a new passkey for each new login, sooner or later that will not be possible.
Password authentication is an example of bad UI design (they are hard to remember and easy to forget), but passkeys are not great either. They have at least three weak points:
First, they are stored in a phone internal storage. This is not secure because phones have complicated software with large attack surface, and if an attacker finds a vulnerability, then they can gain access to all private keys on that device. If the phone is lost or stolen, then the keys can be recovered by reading phone's internal storage. Even if the keys are protected by a PIN, the PINs are usually short and can be easily bruteforced. If they are protected by a fingerprint or biometric lock then I assume that they are not encrypted at all.
Second, to synchronize keys between devices, private keys are uploaded to Google's cloud [1]. The post metions that they are end-to-end encrypted, by doesn't specify any details. However, it says that the keys can be decrypted on a new device if the user provides a PIN or unlock pattern:
> To recover the end-to-end encryption key, the user must provide the lock screen PIN, password, or pattern of another existing device that had access to those keys.
This means that keys stored in Google cloud are either not encrypted or use weak encryption keys that can be easily bruteforced by Google.
Third, synchronizing keys relies on Google's infrastructure. If you ever get banned from Google, you will lose the ability to synchronize keys, and maybe access to them as well.
So instead of promoting secure, easy to use, vendor-independent, cheap hardware keys, Google suggests that everyone stores their private keys either in a Google cloud or on devices where Google has root access. I don't think that it's a great idea.
[1] https://security.googleblog.com/2022/10/SecurityofPasskeysin...
Also, I don't like FIDO standard because it requires attestation of hardware keys and doesn't allow to use DIY keys for example.
First, they are stored in a phone internal storage. This is not secure because phones have complicated software with large attack surface, and if an attacker finds a vulnerability, then they can gain access to all private keys on that device. If the phone is lost or stolen, then the keys can be recovered by reading phone's internal storage. Even if the keys are protected by a PIN, the PINs are usually short and can be easily bruteforced. If they are protected by a fingerprint or biometric lock then I assume that they are not encrypted at all.
Second, to synchronize keys between devices, private keys are uploaded to Google's cloud [1]. The post metions that they are end-to-end encrypted, by doesn't specify any details. However, it says that the keys can be decrypted on a new device if the user provides a PIN or unlock pattern:
> To recover the end-to-end encryption key, the user must provide the lock screen PIN, password, or pattern of another existing device that had access to those keys.
This means that keys stored in Google cloud are either not encrypted or use weak encryption keys that can be easily bruteforced by Google.
Third, synchronizing keys relies on Google's infrastructure. If you ever get banned from Google, you will lose the ability to synchronize keys, and maybe access to them as well.
So instead of promoting secure, easy to use, vendor-independent, cheap hardware keys, Google suggests that everyone stores their private keys either in a Google cloud or on devices where Google has root access. I don't think that it's a great idea.
[1] https://security.googleblog.com/2022/10/SecurityofPasskeysin...
Also, I don't like FIDO standard because it requires attestation of hardware keys and doesn't allow to use DIY keys for example.
> PINs are usually short and can be easily bruteforced
The tamperproof hardware compartment storing that data is supposed to rate limit the guesses (and maybe lock up after too many tries).
Ask FBI how easy it has been guessing iPhone PINs.
The tamperproof hardware compartment storing that data is supposed to rate limit the guesses (and maybe lock up after too many tries).
Ask FBI how easy it has been guessing iPhone PINs.
Any updates on passkey support in Firefox? Firefox seems to (still) only support hardware keys. (FF 107 / MacOS)
https://webauthn.io/
https://webauthn.io/
> With the latest version of Chrome, we're enabling passkeys on Windows 11, macOS, and Android.
Notable absence of GNU/Linux. If I used chromium, I'd feel like even more of a second-class citizen.
Notable absence of GNU/Linux. If I used chromium, I'd feel like even more of a second-class citizen.
Passwords have had a good run but on the modern internet they are a failure. 99% of the population uses the same bad passwords everywhere. We've tried to get people to behave securely with passwords but it just doesn't work. Its not their fault! Humans did not evolve to remember long distinct random strings. It is unfair to expect humans to never be tricked into typing their password into the wrong website.
Its time for something new. I think WebAuthn and passkeys have a real shot to let us finally move onto a better form of authentication than passwords. They have real security benefits and hopefully usability benefits.
I know that there's a lot of distrust of Apple and Google here when it comes to passkeys. But seriously this is not a giant ploy to trick you into buying an iPhone/Android. You can use a yubikey on sites that support passkeys. You can use an opensource solokey. You can use a software based fido key. You can use a an opensource tpm-fido authenticator. There will be opensource passkey implementations that support roaming. The standards are all open and there's nothing blocking interoperability. This is not a locked-in ecosystem.
We've given passwords a good long try. They served their purpose but now are showing a lot of downsides. We need to be serious about looking for better alternatives that serve our end users. Passkeys is a good attempt at that. Lets give it a shot.
Its time for something new. I think WebAuthn and passkeys have a real shot to let us finally move onto a better form of authentication than passwords. They have real security benefits and hopefully usability benefits.
I know that there's a lot of distrust of Apple and Google here when it comes to passkeys. But seriously this is not a giant ploy to trick you into buying an iPhone/Android. You can use a yubikey on sites that support passkeys. You can use an opensource solokey. You can use a software based fido key. You can use a an opensource tpm-fido authenticator. There will be opensource passkey implementations that support roaming. The standards are all open and there's nothing blocking interoperability. This is not a locked-in ecosystem.
We've given passwords a good long try. They served their purpose but now are showing a lot of downsides. We need to be serious about looking for better alternatives that serve our end users. Passkeys is a good attempt at that. Lets give it a shot.
The current implementation shows that there is already an issue of openness. Requiring Apple or Google's password manager to manage and sync the passkeys is an issue. Google explicitly stating there is no planned support for "Local user verification" or "Passkey sync" shows they don't plan on support interoperability. A company following proper password hashing protocol means that repeat passwords isn't an issue. Pushing for 2FA using TOPT/HOTP protects people who reuse passwords and accidentally has one compromised.
Until open source, free roaming, implementations of passkeys exist that expose the private key to the end user, it's effectively a locked-in ecosystem. I still haven't seen a good reason to replace tried and tested pass+2fa with passkeys. A simple push to force non-sms 2FA is an existing solution to the problem passkeys is attempting to solve. A compromised password is much less valuable now than it was even a few years ago. Even if you miss when a password was compromised, companies that care about security have started sending those "a new login was detected" emails that would alert you of any concerning activity.
Until open source, free roaming, implementations of passkeys exist that expose the private key to the end user, it's effectively a locked-in ecosystem. I still haven't seen a good reason to replace tried and tested pass+2fa with passkeys. A simple push to force non-sms 2FA is an existing solution to the problem passkeys is attempting to solve. A compromised password is much less valuable now than it was even a few years ago. Even if you miss when a password was compromised, companies that care about security have started sending those "a new login was detected" emails that would alert you of any concerning activity.
TOTP/HOTP is phishable. Webauthn is not.
> Until open source, free roaming, implementations of passkeys exist that expose the private key to the end user, it's effectively a locked-in ecosystem.
As I said above, there already are free implementations of FIDO keys that give you control over the keys.
> Until open source, free roaming, implementations of passkeys exist that expose the private key to the end user, it's effectively a locked-in ecosystem.
As I said above, there already are free implementations of FIDO keys that give you control over the keys.
For Webauthn, Recoverability is still an open issue of ongoing research. From these issues [2], Webauthn having inbuilt recovery is out of scope. In fact a mobile phone becomes a single point of failure and unlike with 2FA, and with the likely requirement of attestation I don't know if free implementations of FIDO keys would be allowed. [3] This limitation was known and was considered out of scope since 2018. Webauthn can only be considered impossible to phish if companies completely remove the ability to log in with a password and TOTP.
https://github.com/w3c/webauthn/issues/1640
[2] https://github.com/w3c/webauthn/issues/931
[3] https://github.com/w3c/webauthn/issues/865
https://github.com/w3c/webauthn/issues/1640
[2] https://github.com/w3c/webauthn/issues/931
[3] https://github.com/w3c/webauthn/issues/865
Attestation is not a likely requirement. Apple doesn't support it for their implementation of passkeys so it won't see any mainstream adoption. This matches with how WebAuthn has been rolled out by early adopters. Virtually no public services that support WebAuthn require attestation.
I’m very glad to see passkeys coming especially for the contribution they make to improving user experience.
Concerned for the “Big tech” vendor lock-in this will likely facilitate.
Anyone played with this in Chrome yet?
How hard will it be to migrate away from Chrome with this in place?
Concerned for the “Big tech” vendor lock-in this will likely facilitate.
Anyone played with this in Chrome yet?
How hard will it be to migrate away from Chrome with this in place?
I also think passkeys are great and the future...but the issue of who controls the keys is really important to resolve.
If chrome holds them and never lets you export...then those accounts are not yours. They are Google's. No thanks.
If chrome holds them and never lets you export...then those accounts are not yours. They are Google's. No thanks.
I think I got a prompt for this yesterday on a Google account, I was logging into an incognito window while connected to a VPN. I am staying away from enabling because it's not clear how to manage the private and public keys myself.
I see a lot of negativity and skepticism in the comments, and I think it's worth saying quite strongly: if you're reading comments on Hacker News, you're a power user, and you already probably have a good password management system. Either you're superhuman and memorize thousands of different passwords per site, or you have a generator or other system for generating unique passwords and storing them. You may also have security keys, TOTP generation, and an innate ability not to be phished.
The reality is the vast majority of the globe does not have any of these traits. People create bad passwords that are reused all the time. People willingly disable 2FA for convenience, or get phished. In attacks over the summer, we've seen people take bribes to just give over passwords and 2FA codes. Passkeys are predicated on a 2FA-by-default philosophy that solves a lot of real-world problems the vast majority of people have. This is a huge win for normal people who use an Android phone or an iPhone in the default configuration and just need to login to places. It may feel like it's too heavy of an instrument for you because your solution is more convenient and well-understood, but most people struggle with this on a day-to-day basis. In my book, passkeys are still not perfect, but they definitely are better than passwords for 99% of the world.
The reality is the vast majority of the globe does not have any of these traits. People create bad passwords that are reused all the time. People willingly disable 2FA for convenience, or get phished. In attacks over the summer, we've seen people take bribes to just give over passwords and 2FA codes. Passkeys are predicated on a 2FA-by-default philosophy that solves a lot of real-world problems the vast majority of people have. This is a huge win for normal people who use an Android phone or an iPhone in the default configuration and just need to login to places. It may feel like it's too heavy of an instrument for you because your solution is more convenient and well-understood, but most people struggle with this on a day-to-day basis. In my book, passkeys are still not perfect, but they definitely are better than passwords for 99% of the world.
We already have regular WebAuthn to fix that problem properly. Passkeys feel like a way to abuse WebAuthn to lock people into your ecosystem forever, on pain of losing all their online accounts.
A better solution would be cheap (less than $1) hardware keys, not locking people into Google/Apple ecosystem and allowing them to decrypt the keys when asked nicely.
Also, on Android Google's passkeys can be stolen if an attacker gains root privileges. Hardware keys without an OS are much more difficult to hack into.
Also, on Android Google's passkeys can be stolen if an attacker gains root privileges. Hardware keys without an OS are much more difficult to hack into.
If people are going to be using default settings, why not just push a lot harder to force non sms based 2FA? Salted password+2FA should practically match any security benefit being attributed to passkeys. My University forced the entire student and staff population to enroll in Duo 2FA a few years ago and staff/faculty can get a hardware key if they request one. 2FA is required at every single point a University login exists. Everyone just got used to it. I even have to use 2FA when logging in to the VPN using Cisco Anyconnect, there's a third field that says "Duo Action" and it used to say "Second Password" and the options are using a backup code or the word "push" to get a mobile notification.
The fact that passkeys are supposed to replace password and TOTP feels like a security risk. I understand that the phone uses a security enclave or TPM along with a pin/pattern/biometrics to attest a valid 2FA unlock, having it be tied to a mobile phone feels incorrect. I understand that's how it's set up for the vast amount of people already, but shifting from potentially separate devices for TOTP and Pass to a single device for everything seems weaker.
I understand that power users are not the target, but the issue of vendor/device lock based on attestation and not allowing DIY keys. Moving from a piece of information I know like a password, or even an SSH key/cert I print out, to a "password" of a private key even I am not allowed to read feels less secure. It's not a matter of convenience, it's a question of giving up control of key generation and syncing to a third party. From a standpoint of opsec, not having control of your private keys is a much bigger weakness relative to a compromised password. Changing passwords is trivial, but changing a device secured private key is impossible.
Passkeys don't fix the bribes or 5$ wrench loophole [1]. Unless you force users to only use biometrics and pin/patterns are disabled, passkeys will have the same issues that passwords do. In a world where getting people to understand 2FA is hard, it feels short sighted to depend on Bluetooth protocol dependent authentication. Trying to get people to shift from the convenience of a password to the inconvenience of needing to mess with Bluetooth is going to be its own headache. When the topic of needing a superhuman memory to remember passwords comes up, I think of https://xkcd.com/936/ . The conspiracy theorist in me can imagine companies like Netflix forcing passkey reauth every 15 days in order to combat things like password sharing. I respectfully disagree and believe passkeys will serve mostly as an inconvenience for the world. I am struggling to see the use cases where passkeys are meaningfully better than passwords and 2FA unless the use passwords is completely discontinued. And phones would become an even bigger single point of failure. A broken phone would be the same as losing all of your 2FA keys, there would be no password to help demonstrate account ownership to support.
[1] https://xkcd.com/538/
The fact that passkeys are supposed to replace password and TOTP feels like a security risk. I understand that the phone uses a security enclave or TPM along with a pin/pattern/biometrics to attest a valid 2FA unlock, having it be tied to a mobile phone feels incorrect. I understand that's how it's set up for the vast amount of people already, but shifting from potentially separate devices for TOTP and Pass to a single device for everything seems weaker.
I understand that power users are not the target, but the issue of vendor/device lock based on attestation and not allowing DIY keys. Moving from a piece of information I know like a password, or even an SSH key/cert I print out, to a "password" of a private key even I am not allowed to read feels less secure. It's not a matter of convenience, it's a question of giving up control of key generation and syncing to a third party. From a standpoint of opsec, not having control of your private keys is a much bigger weakness relative to a compromised password. Changing passwords is trivial, but changing a device secured private key is impossible.
Passkeys don't fix the bribes or 5$ wrench loophole [1]. Unless you force users to only use biometrics and pin/patterns are disabled, passkeys will have the same issues that passwords do. In a world where getting people to understand 2FA is hard, it feels short sighted to depend on Bluetooth protocol dependent authentication. Trying to get people to shift from the convenience of a password to the inconvenience of needing to mess with Bluetooth is going to be its own headache. When the topic of needing a superhuman memory to remember passwords comes up, I think of https://xkcd.com/936/ . The conspiracy theorist in me can imagine companies like Netflix forcing passkey reauth every 15 days in order to combat things like password sharing. I respectfully disagree and believe passkeys will serve mostly as an inconvenience for the world. I am struggling to see the use cases where passkeys are meaningfully better than passwords and 2FA unless the use passwords is completely discontinued. And phones would become an even bigger single point of failure. A broken phone would be the same as losing all of your 2FA keys, there would be no password to help demonstrate account ownership to support.
[1] https://xkcd.com/538/
I don't understand this, to be honest the more complicated it gets for the user, the more the user gets locked out by themselves. We need a simple username + password thing with an option for 2-factor authentication.
Not a madness of lock screens, passkeys, and all this nonsense. Google shouldn't add this in Google Chrome.
Not a madness of lock screens, passkeys, and all this nonsense. Google shouldn't add this in Google Chrome.
A lot of people here aren't differentiating between WebAuthn, a good thing that basically solves phishing, and these new implementations of it, bad things that lock you into one vendor's ecosystem forever because you can't log into your accounts from other operating systems anymore.
You are not locked in. You can create a passkey in ios, on an android phone and on your desktop for the same website.
This is going to accelerate the adoption of WebAuthn across sites on the internet. I consider that to be very good. You can benefit from the better security that your accounts will get from WebAuthn without ever using a synchronizing passkey.
This is going to accelerate the adoption of WebAuthn across sites on the internet. I consider that to be very good. You can benefit from the better security that your accounts will get from WebAuthn without ever using a synchronizing passkey.
The private keys are encrypted when synced from one device to another. The key for this encryption seems to be a short PIN or biometrics.
Is that true?
If yes, the platform provider can easily decrypt the encrypted keys on their servers.
If not, what’s the other secret known only by the user that encrypts the passkeys in transit? I hope the option of a password is provided.
Further, a closed source unverified password manager such as the iCloud Keychain doesn’t sound a great idea. I could use passkeys in Android (and if there is no external hardware key support), but not on Apple’s platform.
Is that true?
If yes, the platform provider can easily decrypt the encrypted keys on their servers.
If not, what’s the other secret known only by the user that encrypts the passkeys in transit? I hope the option of a password is provided.
Further, a closed source unverified password manager such as the iCloud Keychain doesn’t sound a great idea. I could use passkeys in Android (and if there is no external hardware key support), but not on Apple’s platform.
> Is that true?
It seems so. The article [1] mentions that you can copy the keys to a new device and you need only a backup stored in a Google cloud and PIN/unlock pattern which are easy to bruteforce:
> In some cases, for example, when the older device was lost or damaged, users may need to recover the end-to-end encryption keys from a secure online backup.
> To recover the end-to-end encryption key, the user must provide the lock screen PIN, password, or pattern of another existing device that had access to those keys.
So it means that Google and their friends from government organizations will be able to decrypt cloud backups easily.
[1] https://security.googleblog.com/2022/10/SecurityofPasskeysin...
It seems so. The article [1] mentions that you can copy the keys to a new device and you need only a backup stored in a Google cloud and PIN/unlock pattern which are easy to bruteforce:
> In some cases, for example, when the older device was lost or damaged, users may need to recover the end-to-end encryption keys from a secure online backup.
> To recover the end-to-end encryption key, the user must provide the lock screen PIN, password, or pattern of another existing device that had access to those keys.
So it means that Google and their friends from government organizations will be able to decrypt cloud backups easily.
[1] https://security.googleblog.com/2022/10/SecurityofPasskeysin...
Apple supports third party password managers at the system level on iOS and as browser extensions in Safari.
I have research to do, but I've been struggling a bit with the introduction of iCloud sync for WebAuthN. I was excited to offer WebAuthN as a method for 2FA/MFA to replace the use of phone apps, OTP, etc.
However, now it seems that both the WebAuthN secret and the password could both be synced to iCloud. Now I we to worry about employees syncing both factors to iCloud and properly securing their iCloud accounts? That's not good and will almost certainly require new intrusive controls.
However, now it seems that both the WebAuthN secret and the password could both be synced to iCloud. Now I we to worry about employees syncing both factors to iCloud and properly securing their iCloud accounts? That's not good and will almost certainly require new intrusive controls.
[deleted]
I hope Firefox gets this soon.
What is interoperability like and does Chrome employ open standards? If I generate a key in Chromium, can I use it in some other browser that supports passkeys?
You can noodle around with it on https://webauthn.io/ . Keys will sync within ecosystems - so, if you login with safari on iOS, the same credentials show up on desktop Safari on a mac. That doesn't seem to work between Chrome and Safari, but you can scan a QR code to sign in on chrome using a passkey on your phone.
Right now I'm not sure if this stuff good enough to use instead of passwords. I'd want Firefox support, and preferably built in support in 1Password too. But it might be good enough to use alongside passwords. We need to collectively figure out how to do that. (Do you get a password and a passkey? Or just a passkey & reset via email? How should the user flows work? Any good examples?)
Right now I'm not sure if this stuff good enough to use instead of passwords. I'd want Firefox support, and preferably built in support in 1Password too. But it might be good enough to use alongside passwords. We need to collectively figure out how to do that. (Do you get a password and a passkey? Or just a passkey & reset via email? How should the user flows work? Any good examples?)
It's mostly WebAuthn isn'it it?
I have a novice question:
If I create a new passkey using Chrome on a Mac, is that passkey stored in chrome (via google account) or on MacOS iCloud Keychain?
Would I get to pick one or the other?
If I create a new passkey using Chrome on a Mac, is that passkey stored in chrome (via google account) or on MacOS iCloud Keychain?
Would I get to pick one or the other?
Look on the bright side: implementing, supporting, and fixing this over the next decade means job security for everyone here.
What's my basic authentication method to a site or system I can write down, backup, export or memorize? What happens if I go naked to a friend and want to use their devices to access my systems? What happens if I lose one or more of my existing devices? What happens if I get locked out of one or more of my devices? Basically am I the only one who doesn't think phone is my life and I don't want my life to be over if I lose my phone?
I feel like I'm in a twilight zone of phone dependencies. Already so many systems refuse to let me in if I don't have my phone with me due to sms 2fa I didn't ask for, even though I have dozen other devices and valid credentials. Now we just want to stop pretending and just lock me in to phone forever? My phone goes with me everywhere I go and is super likely to get lose broken or stolen. I don't want it to be a dependency to my online access.