Introducing passkeys in Chrome
blog.chromium.org
blog.chromium.org
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.
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.
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.
https://developers.google.com/identity/passkeys/supported-en...
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.
The FIDO alliance also consists of far more companies than just "Google, Apple, and Microsoft", although they're certainly members. https://fidoalliance.org/members/
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...
- 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?
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?
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?
WebAuthn supports attestation of a key storage device. How are you going to persuade site owners to trust your self-signed attestation certificate?
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.
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.
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.
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.
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?
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.
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.
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 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....
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.
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.
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.
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.
“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
Phone insurance should become real very soon.
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.
(It also allows unlimited TOTP accounts, unlike things like Yubikey which only support up to, like, 30?)
Google and apple. That’s it.
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.
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.
https://developers.google.com/identity/passkeys/supported-en...
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/
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)
(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.")
No plans to support it either [1] https://developers.google.com/identity/passkeys/supported-en...
If only Google and Apple's implementations work, then it's not an open standard.
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.
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.
It's precisely why my original comment says "I don't want any locked-down hardware to prevent me from accessing my own keys".
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.
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.
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.
Also if you get banned from Google then you might lose access to your keys.
> 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...
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.
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.
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.
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.
But that isn’t shared across websites so I’m not sure that’s any violation of privacy.
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.
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.
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.
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.
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.
- 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.
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 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 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?
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.
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.
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.
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.
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.
"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.
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.
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....
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.
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...
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.
Passkey never sends your private key to the website you are signing in to.
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 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."
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.
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.
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?
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 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.
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.)
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.
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
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.
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.
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.
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.
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.
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.
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.
Notable absence of GNU/Linux. If I used chromium, I'd feel like even more of a second-class citizen.
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.
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.
As I said above, there already are free implementations of FIDO keys that give you control over the keys.
https://github.com/w3c/webauthn/issues/1640
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?
If chrome holds them and never lets you export...then those accounts are not yours. They are Google's. No thanks.
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 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.
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.
Not a madness of lock screens, passkeys, and all this nonsense. Google shouldn't add this in Google Chrome.
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.
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.
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...
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.
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?)
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?