Google Introduces Passkey Authentication(security.googleblog.com)
security.googleblog.com
Google Introduces Passkey Authentication
https://security.googleblog.com/2023/05/so-long-passwords-thanks-for-all-phish.html
173 comments
there's two things here, passkeys as a mechansim to sign into your google account, and passkeys in general. i'll assume you're asking about passkeys in general, even though the announcement here is passkeys to sign into your google account - passkeys as a general standard were introduced earlier this year.
1. no, it's a cryptographic key stored on your device. but also yes, because if you're using a passkey on a device you sign into using your google account, google can lock you out of that account and potentially that device. if that device is your only way of logging into a service, you'd be locked out of the service in the same way that losing or destroying the device would lock you out of the service. but authorizing multiple passkeys and adding backup authentication methods is encouraged, so for practical purposes the answer is no.
2. you should understand that passkeys are issued by your device or browser. so if you don't want to trust google, you can use a passkey issued by safari or iPhone instead of Chrome or Android. if you're using an apple-issued passkey to sign into some other service that isn't your google account, google has literally no involvement anywhere in that chain.
3. not according to the spec. the passkey is a certificate that gets stored on your device. your device shares a signature (not the certificate) with the service you're signing into to prove you have access to the certificate. but they're issuing you the cert through their proprietary software. if you don't trust google to not snag a copy of the passkey when they generate it for you, you should use passkeys generated by an issuer that you do trust. (in apple's implementations, passkeys are synced through iCloud, so the answer there is yes - apple does have your passkeys and could sign in to services as you if they wanted. google is not doing that.)
4. you'd have to read the ToS for yourself to figure out what you could sue google for. but the more relevant thing than legal recourse is that this scheme doesn't really give google any power they don't already have, and in many ways distributes power out to third-parties so you have to trust google less. apple's passkey implementation is leading google's. others will follow. this is about allowing you to use an open standard to authenticate with your google account.
1. no, it's a cryptographic key stored on your device. but also yes, because if you're using a passkey on a device you sign into using your google account, google can lock you out of that account and potentially that device. if that device is your only way of logging into a service, you'd be locked out of the service in the same way that losing or destroying the device would lock you out of the service. but authorizing multiple passkeys and adding backup authentication methods is encouraged, so for practical purposes the answer is no.
2. you should understand that passkeys are issued by your device or browser. so if you don't want to trust google, you can use a passkey issued by safari or iPhone instead of Chrome or Android. if you're using an apple-issued passkey to sign into some other service that isn't your google account, google has literally no involvement anywhere in that chain.
3. not according to the spec. the passkey is a certificate that gets stored on your device. your device shares a signature (not the certificate) with the service you're signing into to prove you have access to the certificate. but they're issuing you the cert through their proprietary software. if you don't trust google to not snag a copy of the passkey when they generate it for you, you should use passkeys generated by an issuer that you do trust. (in apple's implementations, passkeys are synced through iCloud, so the answer there is yes - apple does have your passkeys and could sign in to services as you if they wanted. google is not doing that.)
4. you'd have to read the ToS for yourself to figure out what you could sue google for. but the more relevant thing than legal recourse is that this scheme doesn't really give google any power they don't already have, and in many ways distributes power out to third-parties so you have to trust google less. apple's passkey implementation is leading google's. others will follow. this is about allowing you to use an open standard to authenticate with your google account.
On point 1 if google decides to lock you out of its service, it generally doesn't stop at a single device but all other devices you own and associated accounts can also be impacted.
So, the solution here seems to be not just creating backup devices (using the same account) but diversify the platforms as well like use a mix of android, yubikey, ios and any other supported platforms.
Doubt many people would have the time and resources to do it correctly.
So, the solution here seems to be not just creating backup devices (using the same account) but diversify the platforms as well like use a mix of android, yubikey, ios and any other supported platforms.
Doubt many people would have the time and resources to do it correctly.
As long as one of the backup methods included in "the time and resources to do it correctly" includes signing in with a password like you always have, I'd guess that most people will have done that.
The fallback to a password in this case feels so wrong. I mean it’s like ssh with password prompt enabled. They let this open for the conversion phase and monitor how often a user with a passkey is still using the password. But the ultimate goal should be to get rid of username/password credentials. I’m still uncertain if this will ever happen though. Given the track record of giant corps to lock out users for various reasons.
Also, diversity means you trust all of the providers; from a security perspective it's worse.
No? Your private keys are still on your physical device which you own. The providers do not get your key material.
If your threat model includes “the manufacturer of the device I use to authenticate myself is actively working against me”, you are already completely lost.
If your threat model includes “the manufacturer of the device I use to authenticate myself is actively working against me”, you are already completely lost.
In order to be usable, many (most?) providers will implement some kind of override to allow recovery workflows.
Have a look at https://media.fidoalliance.org/wp-content/uploads/2022/03/Ho... and multi-device passkeys.
Your keys may never leave secure storage (tho again that is an implementation detail), but how sure are you about the sync implementation or the backend configuration that dictates which keys or methods are acceptable authenticators?
As a trivial example, it seems very likely that providers will implement one or more forms of backdoor to ensure that LEOs can access your cloud resources.
Have a look at https://media.fidoalliance.org/wp-content/uploads/2022/03/Ho... and multi-device passkeys.
Your keys may never leave secure storage (tho again that is an implementation detail), but how sure are you about the sync implementation or the backend configuration that dictates which keys or methods are acceptable authenticators?
As a trivial example, it seems very likely that providers will implement one or more forms of backdoor to ensure that LEOs can access your cloud resources.
> (in apple's implementations, passkeys are synced through iCloud, so the answer there is yes - apple does have your passkeys and could sign in to services as you if they wanted. google is not doing that.)
Passkeys are stored in the iCloud Keychain which is end-to-end encrypted with 256-bit AES. Passkeys cannot be read by Apple anywhere but on your own device.
Passkeys are stored in the iCloud Keychain which is end-to-end encrypted with 256-bit AES. Passkeys cannot be read by Apple anywhere but on your own device.
Apple can install any software it wants up to the bootloader (iBoot) level on your iPhone via updates. So technically they can access your keys.
I anticipated this reply which is why I added the qualifier "anywhere but on your own device." Unless you intend to manufacture your own device from scratch, at some point you have to place your trust somewhere. See "reflections on trusting trust":
https://web.stanford.edu/class/cs208e/cgi-bin/main.cgi/stati...
https://web.stanford.edu/class/cs208e/cgi-bin/main.cgi/stati...
You can reset your device using an IPSW you got off the internet if you want to make sure Apple isn't shipping targeted firmware to your device specifically.
Yes. So do any OS/TPM vendors.
Unless you control/audit the whole stack (and forbid updates), you have to trust somebody.
Unless you control/audit the whole stack (and forbid updates), you have to trust somebody.
Does icloud e2e still have a loophole where apple can re-key it for you whenever they want? That's how it used to work, and as long as that's how it works their e2e is just for show.
So how does a new device join your iCloud and sync Keychain?
> (in apple's implementations, passkeys are synced through iCloud, so the answer there is yes - apple does have your passkeys and could sign in to services as you if they wanted. google is not doing that.)
iCloud Keychain is e2ee.
iCloud Keychain is e2ee.
So, if I understand correctly:
1. Google can lock you out, but it’s ok because 1% of users have a workaround,
2. You will lose access, but it’s ok because you won’t if you didn’t use this product,
3. Google can log in as you, but it’s ok because we should trust them not to, and
4. We’ve got no recourse, but it’s ok because we were probably helpless anyway?
Companies may get away with this for other products, but the bar is way higher for security products. There are real solutions, or at least ameliorations, and it’d be unsafe to use the product without ensuring they’re there.
1. Google can lock you out, but it’s ok because 1% of users have a workaround,
2. You will lose access, but it’s ok because you won’t if you didn’t use this product,
3. Google can log in as you, but it’s ok because we should trust them not to, and
4. We’ve got no recourse, but it’s ok because we were probably helpless anyway?
Companies may get away with this for other products, but the bar is way higher for security products. There are real solutions, or at least ameliorations, and it’d be unsafe to use the product without ensuring they’re there.
Sorry, but I don't think you do understand correctly, and I mean that in an honest and non-judgemental way, I think you may have misunderstood what Passkeys are, and what this announcement is.
With this announcement, you can log into a Google account with a Passkey. That Passkey could be generated by anything implementing the spec – an iPhone, a browser, a home-grown Python script, whatever you want.
Google can still lock you out of your Google account whether you use a Passkey or not. If you use your Google account to sign in to other sites, Google can also therefore still prevent you from logging into those other sites, as they have been able to do before (I don't know if they do this as a matter of policy, but they theoretically can).
Passkeys do not change this.
The only potential place that Passkeys might change things is if you use a Passkey generated by a Google technology, like Android or Chrome. You could use those Passkeys for logging into anything, not just Google accounts. As these are tied to a device, I don't believe the Google account on that device affects them in any way. Google can't lock you out of your Android phone, and can't prevent you using Chrome, so can't prevent you using Passkeys in either of those systems.
With this announcement, you can log into a Google account with a Passkey. That Passkey could be generated by anything implementing the spec – an iPhone, a browser, a home-grown Python script, whatever you want.
Google can still lock you out of your Google account whether you use a Passkey or not. If you use your Google account to sign in to other sites, Google can also therefore still prevent you from logging into those other sites, as they have been able to do before (I don't know if they do this as a matter of policy, but they theoretically can).
Passkeys do not change this.
The only potential place that Passkeys might change things is if you use a Passkey generated by a Google technology, like Android or Chrome. You could use those Passkeys for logging into anything, not just Google accounts. As these are tied to a device, I don't believe the Google account on that device affects them in any way. Google can't lock you out of your Android phone, and can't prevent you using Chrome, so can't prevent you using Passkeys in either of those systems.
eduction(3)
I am no fan of google, but this is such a grotesque distortion that it feels like you are just pushing an agenda here.
1. They can lock you out of your google account and services you authenticate using login with google, but no more or less than they can lock you out without passkey authentication.
2. You may lose access as per #1, but no differently than if you lost access to your google account having used MFA or whatever other method to log in. It's completely orthogonal.
3. This is just wrong. The passkey is a cert which is used to sign something and send them the signature they can verify with the public part of the cert. They can't login as you. If you don't trust them not to backdoor the passkey itself during generation you can use a passkey generated by someone else.
4. You never had any recourse. This doesn't change that at all either way. It's a login methodology.
1. They can lock you out of your google account and services you authenticate using login with google, but no more or less than they can lock you out without passkey authentication.
2. You may lose access as per #1, but no differently than if you lost access to your google account having used MFA or whatever other method to log in. It's completely orthogonal.
3. This is just wrong. The passkey is a cert which is used to sign something and send them the signature they can verify with the public part of the cert. They can't login as you. If you don't trust them not to backdoor the passkey itself during generation you can use a passkey generated by someone else.
4. You never had any recourse. This doesn't change that at all either way. It's a login methodology.
This is just for authenticating to google, right?
Yes, but if you use the “Login with Google” function on many 3rd party websites, then what? If Google locks you out, can you get back into your account on the 3rd party website?
I think this is a great question, and that the answer depends on the 3rd party site.
I think this is a great question, and that the answer depends on the 3rd party site.
> Yes, but if you use the “Login with Google” function on many 3rd party websites, then what?
AFAIK this part has nothing to do with passkey's and is an issue with OAUTH, and has been an issue for years.
AFAIK this part has nothing to do with passkey's and is an issue with OAUTH, and has been an issue for years.
> […] and is an issue with OAUTH
This issue is not caused by OAuth, but by offering authentication via a third party. If you allow visitors to authenticate via a third party, you implicitly trust that third party. If that third party decides to revoke your account, then the logical consequence is that you can no longer authenticate. There’s no solution for this problem imo, other than not allowing authentication via a third party.
It is the same as airlines; They want you to identify using a passport. If your country decides to revoke your passport, you cannot check-in. That’s not an issue, but a logical consequence of choices made.
This issue is not caused by OAuth, but by offering authentication via a third party. If you allow visitors to authenticate via a third party, you implicitly trust that third party. If that third party decides to revoke your account, then the logical consequence is that you can no longer authenticate. There’s no solution for this problem imo, other than not allowing authentication via a third party.
It is the same as airlines; They want you to identify using a passport. If your country decides to revoke your passport, you cannot check-in. That’s not an issue, but a logical consequence of choices made.
The trouble is that you can, apparently, have only one trusted third party. You can't have a backup authentication service in case the trusted third party fails. That's what's needed.
I'd like to have a regulated entity such as a bank, or even the California DMV, as a backup authentication provider. They have legal obligations that Google does not.
I'd like to have a regulated entity such as a bank, or even the California DMV, as a backup authentication provider. They have legal obligations that Google does not.
You'd need a law saying that the California DMV or whoever must run an oauth service, and then you'd see people integrate it. As it stands, this isn't a thing because the California DMV and even banks aren't interested in being the populus' IDP.
Banks are into this. JP Morgan Chase uses OAuth2 for some services. It's more of an enterprise thing right now.[1]
[1] https://www.jpmorgan.com/technology/technology-blog/protecti...
[1] https://www.jpmorgan.com/technology/technology-blog/protecti...
Yep. I think Google is once again trying to place itself as a gatekeeper. The vast majority of apps out there will never implement passkeys.
Yet they still don't have a way to disable the 2FA prompt offered in the Gmail app (called "Google prompt").
It's a shame that you can add hardware security keys to your Google account and all of that can be bypassed just by pressing "approve" in the Gmail app when you're trying to login.
The attack vector that I'm thinking of here is your phone being stolen while in public while unlocked, it doesn't even prompt for further biometrics when approving a login from the app.
It's a shame that you can add hardware security keys to your Google account and all of that can be bypassed just by pressing "approve" in the Gmail app when you're trying to login.
The attack vector that I'm thinking of here is your phone being stolen while in public while unlocked, it doesn't even prompt for further biometrics when approving a login from the app.
https://landing.google.com/advancedprotection/
AFAIK this removes the ability to use a phone prompt as 2fa.
AFAIK this removes the ability to use a phone prompt as 2fa.
Advanced Protection is nice but practically a non starter or very difficult in a lot of situations, e.g if you're travelling and all of your security keys get stolen and your backup security key is half way across the globe, you'll wish you had 2FA backup codes then.
> Advanced Protection is nice but practically a non starter or very difficult in a lot of situations, e.g if you're travelling and all of your security keys get stolen and your backup security key is half way across the globe, you'll wish you had 2FA backup codes then.
All security is a trade off. For a good chunk of people that is a rare enough occurrence that it is a good trade off for them.
All security is a trade off. For a good chunk of people that is a rare enough occurrence that it is a good trade off for them.
Yeah for sure, which is why I’m not fussed about not being able to use Advanced Protection because I don’t fit in with their target audience.
But I do wish that people on standard accounts could just disable their forced “Google Prompt” authentication method and just use their own 2FA security keys with fallback to backup codes.
But I do wish that people on standard accounts could just disable their forced “Google Prompt” authentication method and just use their own 2FA security keys with fallback to backup codes.
Skip password when possible
You’ll be able to sign in securely with just a passkey or device prompt.
You’ll be able to sign in securely with just a passkey or device prompt.
My only complaint about the tradeoffs made in Google's current implementation of Advanced Protection is that I can't (even if awkwardly and with difficulty) allowlist any given third party OAuth.
So, if I want to, say, authenticate my Gmail account with Fastmail or ProtonMail, I can't also be using Advanced Protection. [0]
With Google Workspace, admins can allowlist OAuth applications registered with Google APIs for users who use Advanced Protection. Consumer accounts have no such feature.
I am not arguing the logic; I understand it. I just wish it were different. I suspect that passkeys are one stepping stone on the road to increasing account security baselines to be more like Advanced Protection, which may ultimately give me what I want one day. Wishful thinking, perhaps.
[0] These are OTOH examples, which may not be accurate as of this writing.
So, if I want to, say, authenticate my Gmail account with Fastmail or ProtonMail, I can't also be using Advanced Protection. [0]
With Google Workspace, admins can allowlist OAuth applications registered with Google APIs for users who use Advanced Protection. Consumer accounts have no such feature.
I am not arguing the logic; I understand it. I just wish it were different. I suspect that passkeys are one stepping stone on the road to increasing account security baselines to be more like Advanced Protection, which may ultimately give me what I want one day. Wishful thinking, perhaps.
[0] These are OTOH examples, which may not be accurate as of this writing.
> All security is a trade off.
Irrelevant to the problem of "I want to just disable phone prompt of 2FA without everything else included with Advanced Protection" - there's no intrinsic "security tradeoff" here, just bad and overly restricting design decisions by Google.
Irrelevant to the problem of "I want to just disable phone prompt of 2FA without everything else included with Advanced Protection" - there's no intrinsic "security tradeoff" here, just bad and overly restricting design decisions by Google.
> All security is a trade off. For a good chunk of people that is a rare enough occurrence that it is a good trade off for them.
Except most people are operating under a flawed assumption that the trade-off with Google is like a trade-off with any other institution - that is, if the worst happens, you can get a human on the phone, or visit a branch office, and get the issue sorted out. This critical fallback is, unfortunately, missing for Google and many other on-line service providers.
Except most people are operating under a flawed assumption that the trade-off with Google is like a trade-off with any other institution - that is, if the worst happens, you can get a human on the phone, or visit a branch office, and get the issue sorted out. This critical fallback is, unfortunately, missing for Google and many other on-line service providers.
Advanced protection is specifically designed to opt out of that protection. The entire point of AP is to opt-out of normal account recovery procedures because you take care seriously that an account recovery attack on Google is a legitimate threat.
I have a trusted family member who maintains a copy of all of my recovery codes. In event of disaster, I call and provide a previously shared pass phrase, and recovery codes will be provided. Something to consider depending on your daily driver threat model and tail risk considerations.
(frequent international travel while having strong opsec)
(frequent international travel while having strong opsec)
But if you enable Advanced Protection then recovery/backup codes are disabled right? (Maybe I’m wrong)
So the only option to have recovery codes available is to not used advanced protection and then have this “Google Prompt” forced on you, which I’d like to disable as it is another physical attack vector which is undesirable especially when travelling.
So the only option to have recovery codes available is to not used advanced protection and then have this “Google Prompt” forced on you, which I’d like to disable as it is another physical attack vector which is undesirable especially when travelling.
> The attack vector that I'm thinking of here is your phone being stolen
This is exactly why I'm a big fan of larger, heavier devices, such as my rack-mounted desktop PC, being their own 2FA device. It's pretty hard to steal my 4U desktop that is bolted down, there's no reason why it should depend on anything else for 2FA.
Similarly, laptops should be their own 2FA device and not depend on a phone, since people are generally more careful to not take laptops into high-crime areas.
This is exactly why I'm a big fan of larger, heavier devices, such as my rack-mounted desktop PC, being their own 2FA device. It's pretty hard to steal my 4U desktop that is bolted down, there's no reason why it should depend on anything else for 2FA.
Similarly, laptops should be their own 2FA device and not depend on a phone, since people are generally more careful to not take laptops into high-crime areas.
Yep. I complained about that on HN recently- https://news.ycombinator.com/item?id=35692884 though since then it has, at least started working again.
I didn’t mention it in that post but that is _exactly_ the attack vector I had in mind also- even if someone stole my phone, Touch ID should stop them from getting at my passwords.
I didn’t mention it in that post but that is _exactly_ the attack vector I had in mind also- even if someone stole my phone, Touch ID should stop them from getting at my passwords.
> Yet they still don't have a way to disable the 2FA prompt offered in the Gmail app (called "Google prompt").
There used to be a way to intentionally (after 2FA) add or remove devices to "Google prompt". These days, it just seems to be any device I'm logged in to, sadly.
There used to be a way to intentionally (after 2FA) add or remove devices to "Google prompt". These days, it just seems to be any device I'm logged in to, sadly.
They added a fix for that, see it in your security settings
Skip password when possible - You’ll be able to sign in securely with just a passkey or device prompt.
Skip password when possible - You’ll be able to sign in securely with just a passkey or device prompt.
That setting doesn’t affect what I’m saying. I want to disable Google Prompt as it’s insecure for my threat model. All “skip password when possible” does is give you the option to use a passkey to login without a password, it doesn’t prevent an attacker from using a password + Google Prompt to login, bypassing the need for any of the configured 2FA security keys or passkeys.
password is still available, even with passkey
"So long passwords, thanks for all the phish"
that's pretty funny actually
Click bait title, the password is not going away, unlike the dolphins who left earth...
>Creating a passkey on your Google Account makes it an option for sign-in. Existing methods, including your password, will still work in case you need them, for example when using devices that don't support passkeys yet. Passkeys are still new and it will take some time before they work everywhere. However, creating a passkey today still comes with security benefits as it allows us to pay closer attention to the sign-ins that fall back to passwords. Over time, we'll increasingly scrutinize these as passkeys gain broader support and familiarity.
>Creating a passkey on your Google Account makes it an option for sign-in. Existing methods, including your password, will still work in case you need them, for example when using devices that don't support passkeys yet. Passkeys are still new and it will take some time before they work everywhere. However, creating a passkey today still comes with security benefits as it allows us to pay closer attention to the sign-ins that fall back to passwords. Over time, we'll increasingly scrutinize these as passkeys gain broader support and familiarity.
I’m gonna give you the benefit of the doubt and assume “click bait” was also meant to be a fishing pun.
https://news.ycombinator.com/item?id=35801392 (603 comments)
How is this, practically, any better than existing 2FA? A 2FA code is stored on a device just like a passkey is.
Passwords had a security and a usability problem, I guess, and so the solution was to add 2FA, which allegedly improves security. Now, we’re dropping the security of passwords to solve the usability issue. This doesn’t seem to be a big improvement to me.
Passwords had a security and a usability problem, I guess, and so the solution was to add 2FA, which allegedly improves security. Now, we’re dropping the security of passwords to solve the usability issue. This doesn’t seem to be a big improvement to me.
It's less secure than 2FA and more secure than passwords. How is it practically better than 2FA, because it's easier.
Given that most regular 2FA is implemented with SMS and doesn't even require stealing someone's device, I think passkeys are arguably more secure.
Oh totally. I was only thinking about the TOTP 2FA, for which I also have a giant rant about being user-hostile.
It's different.
2FA just means 2 factors.
Passkeys are just a factor. Usually a more secure factor than a password.
2FA just means 2 factors.
Passkeys are just a factor. Usually a more secure factor than a password.
and the Passkeys requires to be secured by a PIN or biometric.
So Passkey = Something you have, PIN = Something you know.
So Passkey = Something you have, PIN = Something you know.
Not saying you think this, just adding to the conversation.. the pin is to unlock that factor and passkeys should not be taken to mean that MFA for accounts is not needed.
However Google is saying this:
> this means that passkeys protect you against phishing and any accidental mishandling that passwords are prone to, such as being reused or exposed in a data breach. This is stronger protection than most 2SV (2FA/MFA) methods offer today, which is why we allow you to skip not only the password but also 2SV when you use a passkey.
> this means that passkeys protect you against phishing and any accidental mishandling that passwords are prone to, such as being reused or exposed in a data breach. This is stronger protection than most 2SV (2FA/MFA) methods offer today, which is why we allow you to skip not only the password but also 2SV when you use a passkey.
A pin is not "something you know" legally. Biometrics are especially not.
> 2FA code is stored on the device
That's not how 2FA works.
That's not how 2FA works.
What? It is how it works. The TOTP secret is stored on device which can be used to arbitrarily generate codes.
TOTP is not 2FA, but can be used for 2FA. What is the "secret stored on device" when SMS is used for 2FA?
Passkeys are stored in Secure Enclave on Apple devices, or on YubiKeys. Not sure about Androids.
Passkeys are stored in Secure Enclave on Apple devices, or on YubiKeys. Not sure about Androids.
> What is the "secret stored on device" when SMS is used for 2FA?
IMEI number?
IMEI number?
When you request an SMS 2FA code, they're blindly sending an auth code to your phone number over SMS, that's all they know. That number could be registered to any SIM card which could be in any device. Someone could have socially engineered a rep at your carrier to have that number transferred to their device, which is a real thing that happens.
And the solution to that is? Disable SMS/phone number as 2FA? No, drop 2FA altogether for a more secure password...nonsense.
I understand, but your statement feels pedantic. Practically, if someone has access to your device, your 2FA codes are compromised.
Yes, Passkeys do not offer much against rubber-hose cryptanalysis. Actually, it's a bit worse than passwords as it doesn't require captured human to be concious.
I believe Passkeys are great for those whose threat profile doesn't include physical assault risks.
I believe Passkeys are great for those whose threat profile doesn't include physical assault risks.
How do I back these up in case of catastrophic data loss, such as my house and all my possessions burning down (there are approximately 350000 house fires a year in the USA, so it's worth worrying about when its your entire digital life)? I take my security safety, but I take the durability of my digital life much more seriously.
Right now, I am able to back up all my personal passwords and all my personal TOTP secrets into printed paper form that I keep in tamper-evident packaging and distribute to a safe-deposit box and the basements/attics of different trusted friends/family members. The printed packet of paper has instructions on how to use it, the passwords and TOTP secrets themselves, and the brief source code for one program, one that lets you generate TOTP codes from all my secrets (TOTP is very simple, it's like 30 lines of python[0]). I've tested it all and it is sufficient to access any account I have. Since it's all recorded on paper, each packet will function for my entire lifetime; I don't have to worry about storing a device and that device's charging/power equipment, and I don't have to worry about that device's capacitors or battery going bad in 10 years.
So in the world of "passkeys", how do I simply and durably record them so that if need be, someone who is not me, who I've never met, and who has access to none of my electronic devices, can authenticate as me given that this person is willing to put several days effort into dealing with my authentication archive (e.g. an estate lawyer)?
I know that this is "possible"; it's all based on data and secrets recorded somewhere, but I'm having a hard time understanding the FIDO description, and I don't see an Open-Source equivalent of what Google's offering here. Is there a "KeePassX" of the passkey world?
[0] - https://github.com/susam/mintotp/blob/main/mintotp.py
Right now, I am able to back up all my personal passwords and all my personal TOTP secrets into printed paper form that I keep in tamper-evident packaging and distribute to a safe-deposit box and the basements/attics of different trusted friends/family members. The printed packet of paper has instructions on how to use it, the passwords and TOTP secrets themselves, and the brief source code for one program, one that lets you generate TOTP codes from all my secrets (TOTP is very simple, it's like 30 lines of python[0]). I've tested it all and it is sufficient to access any account I have. Since it's all recorded on paper, each packet will function for my entire lifetime; I don't have to worry about storing a device and that device's charging/power equipment, and I don't have to worry about that device's capacitors or battery going bad in 10 years.
So in the world of "passkeys", how do I simply and durably record them so that if need be, someone who is not me, who I've never met, and who has access to none of my electronic devices, can authenticate as me given that this person is willing to put several days effort into dealing with my authentication archive (e.g. an estate lawyer)?
I know that this is "possible"; it's all based on data and secrets recorded somewhere, but I'm having a hard time understanding the FIDO description, and I don't see an Open-Source equivalent of what Google's offering here. Is there a "KeePassX" of the passkey world?
[0] - https://github.com/susam/mintotp/blob/main/mintotp.py
Register a Yubikey in addition to all the services supporting WebAuthN and put it in the tamper-evident envelope?
> Is there a "KeePassX" of the passkey world?
Both 1Password and Bitwarden have announced support as soon as OS support will become available, the latter being open source.
> Is there a "KeePassX" of the passkey world?
Both 1Password and Bitwarden have announced support as soon as OS support will become available, the latter being open source.
Related discussion yesterday at https://news.ycombinator.com/item?id=35801392
However, this is definitely a better article and clears up a lot of peoples' misconceptions present in that HN thread.
> Passkey sync providers like the Google Password Manager and iCloud Keychain use end-to-end encryption to keep your passkeys private.
https://security.googleblog.com/2022/10/SecurityofPasskeysin... claims it's encrypted using "an encryption key that is only accessible on the user's own devices":
> When a user sets up a new Android device by transferring data from an older device, existing end-to-end encryption keys are securely transferred to the new device. 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.
> Screen lock PINs, passwords or patterns themselves are not known to Google. The data that allows Google to verify correct input of a device's screen lock is stored on Google's servers in secure hardware enclaves and cannot be read by Google or any other entity.
How does Google know my device's local PIN in the first place? Are Android phones phoning home to Google with their local PINs, like how they already "helpfully" backup your Wi-Fi passwords to Google servers? And what's stopping the FBI from asking Google to send them every device's PIN as it's created?
https://security.googleblog.com/2022/10/SecurityofPasskeysin... claims it's encrypted using "an encryption key that is only accessible on the user's own devices":
> When a user sets up a new Android device by transferring data from an older device, existing end-to-end encryption keys are securely transferred to the new device. 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.
> Screen lock PINs, passwords or patterns themselves are not known to Google. The data that allows Google to verify correct input of a device's screen lock is stored on Google's servers in secure hardware enclaves and cannot be read by Google or any other entity.
How does Google know my device's local PIN in the first place? Are Android phones phoning home to Google with their local PINs, like how they already "helpfully" backup your Wi-Fi passwords to Google servers? And what's stopping the FBI from asking Google to send them every device's PIN as it's created?
If I had to guess, when you set up an Android device's passcode, it generates a key pair, signs a message and ships the public key to Google, and then encrypts the private key with your pin (maybe with your Google password and/or a Google-provided salt at the end) and ships that to Google. So when you restore access on a new device, it downloads that private key bundle and tries to decrypt it using the PIN you provide.
> And what's stopping the FBI from asking Google to send them every device's PIN as it's created?
device PINs are never sent to Google in this scenario - but nothing is stopping them from being asked to log your Password the next time you sign in, and it's up to you to trust that they'd never do this even when asked via national security letter since it destroys all trust people (and Google Workspace enterprise businesses) have in their login system.
> And what's stopping the FBI from asking Google to send them every device's PIN as it's created?
device PINs are never sent to Google in this scenario - but nothing is stopping them from being asked to log your Password the next time you sign in, and it's up to you to trust that they'd never do this even when asked via national security letter since it destroys all trust people (and Google Workspace enterprise businesses) have in their login system.
There’s more info on this here: https://research.nccgroup.com/wp-content/uploads/2022/04/NCC...
In short we can only verify PINs, and only a very limited number of guesses, enforced by hardware.
In short we can only verify PINs, and only a very limited number of guesses, enforced by hardware.
What's even more ridiculous is calling it end-to-end encryption when it's secured by a short numeric pin (what most people use). The search space for brute forcing it is so insanely small that it doesn't matter how much password stretching you do, it's trivial for Google/anyone with access to the keystore to brute force.
You don’t need to know a pin top verify the pin. You hash the pin with a one way function and compare it to a stored hash.
What I don't understand is why with a passkey they don't ask for the second factor anymore. I feel like I would want that.
With the passkey you provide a second factor. Instead of the second factor being hacked into the auth system it’s pushed down the stack into the standards that power passkeys (WebAuthn and FIDO2).
The theory is that the two factors are something you have (your phone) and something you are (your biometric).
I'm happy that my important stuff is behind both a password + my phone.
Having both behind your phone makes it easy to drug someone and get inside.
Having both behind your phone makes it easy to drug someone and get inside.
Even people using 2FA are probably storing the passwords on the phone via a password manager. Those without a password manager are probably reusing passwords or choosing insecure ones.
I'd maybe be worried about the drugging if I'd ever heard of it happening to someone I know.
I'd maybe be worried about the drugging if I'd ever heard of it happening to someone I know.
> Even people using 2FA are probably storing the passwords on the phone via a password manager.
Yes, but this is the reason that password managers encrypt your other passwords with a master password, rather than a master biometric. The master password is still the "something you know" factor.
Yes, but this is the reason that password managers encrypt your other passwords with a master password, rather than a master biometric. The master password is still the "something you know" factor.
Most don't ask for the master password by default. Mac Keychain for example is "unlocked" at login unless you change that. iPhone Keychain will input passwords from just FaceID, no passcode prompt. Desktop Chrome and Firefox just autofill passwords no questions asked.
Password managers are designed around the idea that after you fully authenticate with your something-you-know credential, then they'll mostly trust that you're "still there" for a certain period of time, requiring only a something-you-are factor for re-authentication while the something-you-know credential remains cached in memory. This "safety interval" usually ticks down more slowly while the device remains active (because continuous use implies "you" didn't wander off such that someone else could slip in), and more quickly while the device is idle/locked.
When the "safety interval" expires, or if you fully shut off the device, or if you manually trigger a "something unusual is happening" mode (https://www.idownloadblog.com/2017/08/21/how-to-disable-touc...), then the password manager will lose this cached "already mostly satisfied" state, and so will require you to present the "actual" something-you-know credential again.
> Mac Keychain for example is "unlocked" at login unless you change that.
That's because you just fully authenticated it by providing your master password (which for the macOS local keychain is your local account's login password, which you had to present in order to unlock the FDE disk at startup.) In fact, ignoring FDE, this is what "logging in" means on macOS: decrypting the local-account keychain.
You'll notice that this doesn't apply to your iCloud keychain, since that doesn't use the same password as your local account, and so you didn't present that keychain's unlock password when you signed in.
Interestingly, this also doesn't apply if you set your FDE unlock password to be different than your local account sign-in password. The FDE unlock password will do some magic that gets you logged into your account; but you will end up in your account with your local-account keychain still locked — which will cause a lot of annoying prompts on login. (I ran macOS like this for a while back in ~2013, because I wanted a really secure boot passphrase, but didn't want to have to type it every time I locked the screen, and TouchID didn't exist yet on Macs. Wasn't worth it.)
> iPhone Keychain will input passwords from just FaceID, no passcode prompt
Again, that's because you signed into your phone with a password recently-enough to make it satisfied with you; and this safety interval is much wider on a phone than on a PC, because people keep phones "securely" with them, rather than e.g. letting them sit turned-on and unguarded at work when they go home for the day.
You'll find that companies that have confidentiality requirements, deploy MDM policies for employees' mobile devices which make this safety interval much shorter — if they even allow it at all. (I worked for IBM Canada, and my phone would force a password unlock after being locked for just 30 seconds.)
> Desktop Chrome and Firefox just autofill passwords no questions asked.
This is true, and because of this, security people do not consider these browser "autofill" features to be "password managers." Don't use them! They don't encrypt your passwords at rest, either! Viruses can steal your passwords right out of these autofill databases, and many modern viruses do do that!
(I would note that Chrome does prompt you for your [local-account login] password in order to be able to browse your autofill passwords — which is at least something. But this is just security theatre; you can still read the passwords right off the disk without knowing your login password.)
When the "safety interval" expires, or if you fully shut off the device, or if you manually trigger a "something unusual is happening" mode (https://www.idownloadblog.com/2017/08/21/how-to-disable-touc...), then the password manager will lose this cached "already mostly satisfied" state, and so will require you to present the "actual" something-you-know credential again.
> Mac Keychain for example is "unlocked" at login unless you change that.
That's because you just fully authenticated it by providing your master password (which for the macOS local keychain is your local account's login password, which you had to present in order to unlock the FDE disk at startup.) In fact, ignoring FDE, this is what "logging in" means on macOS: decrypting the local-account keychain.
You'll notice that this doesn't apply to your iCloud keychain, since that doesn't use the same password as your local account, and so you didn't present that keychain's unlock password when you signed in.
Interestingly, this also doesn't apply if you set your FDE unlock password to be different than your local account sign-in password. The FDE unlock password will do some magic that gets you logged into your account; but you will end up in your account with your local-account keychain still locked — which will cause a lot of annoying prompts on login. (I ran macOS like this for a while back in ~2013, because I wanted a really secure boot passphrase, but didn't want to have to type it every time I locked the screen, and TouchID didn't exist yet on Macs. Wasn't worth it.)
> iPhone Keychain will input passwords from just FaceID, no passcode prompt
Again, that's because you signed into your phone with a password recently-enough to make it satisfied with you; and this safety interval is much wider on a phone than on a PC, because people keep phones "securely" with them, rather than e.g. letting them sit turned-on and unguarded at work when they go home for the day.
You'll find that companies that have confidentiality requirements, deploy MDM policies for employees' mobile devices which make this safety interval much shorter — if they even allow it at all. (I worked for IBM Canada, and my phone would force a password unlock after being locked for just 30 seconds.)
> Desktop Chrome and Firefox just autofill passwords no questions asked.
This is true, and because of this, security people do not consider these browser "autofill" features to be "password managers." Don't use them! They don't encrypt your passwords at rest, either! Viruses can steal your passwords right out of these autofill databases, and many modern viruses do do that!
(I would note that Chrome does prompt you for your [local-account login] password in order to be able to browse your autofill passwords — which is at least something. But this is just security theatre; you can still read the passwords right off the disk without knowing your login password.)
> That's because you just fully authenticated it by providing your master password (which for the macOS local keychain is your local account's login password, which you had to present in order to unlock the FDE disk at startup.)
I booted my laptop maybe several months ago and unlocked the screen with TouchID at the moment.
> Interestingly, this also doesn't apply if you set your FDE unlock password to be different than your local account sign-in password. The FDE unlock password will do some magic that gets you logged into your account; but you will end up in your account with your local-account keychain still locked — which will cause a lot of annoying prompts on login.
Haha, I've been there by accident before. Or before FDE was a thing, having a different keychain vs login password because of some migration gone wrong.
> Again, that's because you signed into your phone with a password recently-enough to make it satisfied with you
Not sure about this. Usually I use FaceID. Does that ever expire and need the passcode? I don't think it does; the only times it asks iirc is when I fail the FaceID auth repeatedly (it doesn't like my second pair of glasses).
> This is true, and because of this, security people do not consider these browser "autofill" features to be "password managers." Don't use them!
Yeah, it's jank, but people do use them. Personally I use Safari for important stuff just because I want Keychain instead, but otherwise, your only option is dealing with a third-party password manager.
I booted my laptop maybe several months ago and unlocked the screen with TouchID at the moment.
> Interestingly, this also doesn't apply if you set your FDE unlock password to be different than your local account sign-in password. The FDE unlock password will do some magic that gets you logged into your account; but you will end up in your account with your local-account keychain still locked — which will cause a lot of annoying prompts on login.
Haha, I've been there by accident before. Or before FDE was a thing, having a different keychain vs login password because of some migration gone wrong.
> Again, that's because you signed into your phone with a password recently-enough to make it satisfied with you
Not sure about this. Usually I use FaceID. Does that ever expire and need the passcode? I don't think it does; the only times it asks iirc is when I fail the FaceID auth repeatedly (it doesn't like my second pair of glasses).
> This is true, and because of this, security people do not consider these browser "autofill" features to be "password managers." Don't use them!
Yeah, it's jank, but people do use them. Personally I use Safari for important stuff just because I want Keychain instead, but otherwise, your only option is dealing with a third-party password manager.
FaceID asks for the passcode to enable itself every few days it seems. Not sure the frequency.
And clicking the side button ten times locks it to needing the pass phrase.
And clicking the side button ten times locks it to needing the pass phrase.
By default, clicking the power/side button 5 (not 10) times starts a countdown to dial emergency services. If you don’t cancel the countdown, it calls emergency services for you. Either way, biometric unlock is disabled until you re-enter your passcode/PIN. This can be disabled in settings.
Holding the power/side button and either volume button for a couple of seconds (just pressing them together and letting go creates a screenshot) presents a menu allowing you to power the phone off, display your medical ID, or call emergency services. You can also configure settings to have this action do the countdown as described above instead. Either way, biometric unlock is disabled until you re-enter your passcode/PIN.
Either option is pretty easy to do unnoticed with your phone in your pocket.
Holding the power/side button and either volume button for a couple of seconds (just pressing them together and letting go creates a screenshot) presents a menu allowing you to power the phone off, display your medical ID, or call emergency services. You can also configure settings to have this action do the countdown as described above instead. Either way, biometric unlock is disabled until you re-enter your passcode/PIN.
Either option is pretty easy to do unnoticed with your phone in your pocket.
I largely agree, though with something like 1password it definitely is convenient to not type in your master password each time.
If someone has your phone, they probably have your emails/authenticators, which means they have most of your passwords.
Passkeys simplify the email reset/OTP loop, for the most part.
Passkeys simplify the email reset/OTP loop, for the most part.
This makes no sense. Two different factors are two different factors. I might want two devices to be involved to setup a new login to critical services. One I'd always have at home so only with access both to me and my home you'd be able to login.
I think you can do exactly that by using a Fido key instead of face / touch authentication for your device.
But that's the problem. If I understood correctly, Google won't ask you for your FIDO key if you use their passkey.
I'm never using this unless I'm in control of the certs and where they're stored. This if a fragile solution to the issue of password reuse and bad security practices from vendors.
Passkeys don't send the hardware identifier or anything else to the service when you authenticate with them - all they see is a signature and a public key with no authority/signing chain or anything. So you can very well create software passkey implementations and whatnot, or use something like a Yubikey for your passkey storage.
My personal preference is for it not to be tied to a device that can be lost, stolen, broken. That way I don't need multiple backup devices to login to one service.
My password manager generates unique strong passwords, is offline and no big multinational advertising company controls it. The only thing I need to worry about is individual companies security practices. Passkeys offer me nothing of an improvement over this and only more obstacles and hoops to jump through.
Until I can use passkeys like I can my password manager I'm not using them
My password manager generates unique strong passwords, is offline and no big multinational advertising company controls it. The only thing I need to worry about is individual companies security practices. Passkeys offer me nothing of an improvement over this and only more obstacles and hoops to jump through.
Until I can use passkeys like I can my password manager I'm not using them
>Creating a passkey on your Google Account makes it an option for sign-in. Existing methods, including your password, will still work in case you need them, for example when using devices that don't support passkeys yet. Passkeys are still new and it will take some time before they work everywhere. However, creating a passkey today still comes with security benefits as it allows us to pay closer attention to the sign-ins that fall back to passwords. Over time, we'll increasingly scrutinize these as passkeys gain broader support and familiarity.
So my password that I stupidly shared among my accounts and was then leaked, can still be used to compromise my Google Account.
Wake me when I can create a Google Account without a password, email, or phone number, period.
So my password that I stupidly shared among my accounts and was then leaked, can still be used to compromise my Google Account.
Wake me when I can create a Google Account without a password, email, or phone number, period.
Probably not far off.
Sounds like with other methods (SMS 2FA, USB hardware key, etc.) you may be able to eventually turn password sign-in off on your Google account and use passkeys exclusively.
Sounds like with other methods (SMS 2FA, USB hardware key, etc.) you may be able to eventually turn password sign-in off on your Google account and use passkeys exclusively.
That's it! When I can use solely my hardware security key to signup/login then we are talking. The rest is just marketing.
A phone number is both an authentication mode and rudimentary bot/sockpuppet protection. (It’s pretty bad at both, but that’s a different story.)
Passkeys can substitute the former, but (by design) not the latter.
Passkeys can substitute the former, but (by design) not the latter.
Nothing stops you from registering multiple passkeys, change the password to a long random string and forget about it - then you effectively have passkey only account.
Excellent point, just tried to create a new Google Account and it requires a phone number that can receive a text message so account is still open to SIM swap.
This still feels like a beta product, with a foot-gun of a UX
* I activated the passkey, but since i had one saved from an old device, it did not set up my new device. So i got locked out of my account (luckily i have a backup option)
* How does this work with desktop PCs that don't have a camera?
* Now we have a web of primary, secondary, n-ary authentication methods that need managed. Password, app 2-fa, phone 2-fa, tokens etc. Any one could be a weak link in the chain. Now warnings, notifs & reporting is needed to maintain security among all the auth methods.
It reminds me of the XKCD "standard" that now means we have n+1 protocols
* I activated the passkey, but since i had one saved from an old device, it did not set up my new device. So i got locked out of my account (luckily i have a backup option)
* How does this work with desktop PCs that don't have a camera?
* Now we have a web of primary, secondary, n-ary authentication methods that need managed. Password, app 2-fa, phone 2-fa, tokens etc. Any one could be a weak link in the chain. Now warnings, notifs & reporting is needed to maintain security among all the auth methods.
It reminds me of the XKCD "standard" that now means we have n+1 protocols
Definitely agree with concerns regarding the UX. While I'm sure many of us here can understand the following paragraph from the article...
> In fact, if you sign in on a device shared with others, you should not create a passkey there. When you create a passkey on a device, anyone with access to that device and the ability to unlock it, can sign in to your Google Account.
... I wonder about the general layperson, especially older generations who (in my experience) tend not to use very secure passwords or MFA. Historically, all they would need to do is use their username and password, and now they are into their account, regardless of which device or location they are at. With passkeys, they have to not only learn a new login paradigm, but also remember that it's different if they are signing in at e.g. the library vs on a desktop at home.
> In fact, if you sign in on a device shared with others, you should not create a passkey there. When you create a passkey on a device, anyone with access to that device and the ability to unlock it, can sign in to your Google Account.
... I wonder about the general layperson, especially older generations who (in my experience) tend not to use very secure passwords or MFA. Historically, all they would need to do is use their username and password, and now they are into their account, regardless of which device or location they are at. With passkeys, they have to not only learn a new login paradigm, but also remember that it's different if they are signing in at e.g. the library vs on a desktop at home.
I believe the tech industry needs a special segment of Accessibility catering to the elderly
We are not taking responsibility for the unusable UX we are applying to cars, home appliances, phones, consumer devices, televisions, etc.
Mechanical and even electronic devices have an intuitive direct-feedback UI. Flip on an old iron and it heats up.
Modern devices are multi-modal, with soft-touch keys and modal LCD displays. Some buttons are long-press (variable input).
And don't get me started on cars. Total chaos.
We are not taking responsibility for the unusable UX we are applying to cars, home appliances, phones, consumer devices, televisions, etc.
Mechanical and even electronic devices have an intuitive direct-feedback UI. Flip on an old iron and it heats up.
Modern devices are multi-modal, with soft-touch keys and modal LCD displays. Some buttons are long-press (variable input).
And don't get me started on cars. Total chaos.
The way it works with desktop is that the browser displays a QR code, and scan it with the camera app, which allows you to register or log in.
Pretty sure you scan the QR code using your phone's camera. Trying to find a page that confirms this...
thanks i re-read apple’s docs and you’re right. I was thinking (metaphorically) QR-code=Passkey but on desktop QR-code = lock, phone=Key
Sign in on a different device with the passkey stored on your iPhone iPhone stores your passkeys in iCloud Keychain, so they’re automatically used whenever you’re signed in with your Apple ID on another device (iOS 16, iPadOS 16, macOS Ventura, or tvOS 16 required). However, if you use a device that’s not associated with your Apple ID, you can still sign in to an account by using the passkey stored on your iPhone. Signing in usually consists of the following steps: Use the other device to go to your account sign-in screen. On the sign-in screen, tap the account name field. Tap “Other options,” “Passkey from nearby device,” or similar, then follow the onscreen instructions to display a QR code on the screen. Use your iPhone camera to scan the QR code.
the docs https://support.apple.com/guide/iphone/sign-in-with-passkeys...
Sign in on a different device with the passkey stored on your iPhone iPhone stores your passkeys in iCloud Keychain, so they’re automatically used whenever you’re signed in with your Apple ID on another device (iOS 16, iPadOS 16, macOS Ventura, or tvOS 16 required). However, if you use a device that’s not associated with your Apple ID, you can still sign in to an account by using the passkey stored on your iPhone. Signing in usually consists of the following steps: Use the other device to go to your account sign-in screen. On the sign-in screen, tap the account name field. Tap “Other options,” “Passkey from nearby device,” or similar, then follow the onscreen instructions to display a QR code on the screen. Use your iPhone camera to scan the QR code.
the docs https://support.apple.com/guide/iphone/sign-in-with-passkeys...
To the second point: windows hello supports a variety of methods, one of them being without a fingerprint or camera. You can add it right now to your account.
For linux users, not entirely sure which environments support any form of "biometrics".
For linux users, not entirely sure which environments support any form of "biometrics".
can someone who understands the cryptographic basis explain how centralized this is?
it sounds like an app can consume passkey logins without registering with a provider?
do providers phone home when I log in? can providers block an app from using them?
can I self-host a provider, or is there a shortlist of approved providers?
is there any provider that allows me to backup private key without sending it to their cloud?
is it similar to openid in that it shares email etc with the app on login?
it sounds like an app can consume passkey logins without registering with a provider?
do providers phone home when I log in? can providers block an app from using them?
can I self-host a provider, or is there a shortlist of approved providers?
is there any provider that allows me to backup private key without sending it to their cloud?
is it similar to openid in that it shares email etc with the app on login?
First, just a high-level overview over how it would work as an app/consumer which is not terribly centralized outside of requiring browser support:
Passkeys are an open standard, and they basically are just public/private keys with a wrapper. When you create a credential which is just a call to `navigator.credentials.create` with options to indicate a PublicKeyCredential type and that it should be a client-side discoverable key and a user ID to associate with it (and some optional info). Its gives you back some meta-info and the public key to store.
For a login flow, similarly a call to `navigator.credentials.get` indicating you want one of those discoverable keys to be used and a challenge. The browser returns a signature to you along with the key info (that user ID from the creation) and you are responsible to verify the signature is appropriately signed.
---
So, on the actual crypto side, nothing about it requires any centralization, there is no required phoning home or to a remote source. On the creation/storage/retrieval side, the WebAuthn Authenticator Model is defined as part of the standard so anyone can implement it. I don't know enough about how you'd register as such an authenticator. Dashlane already supports passkeys, so it is possible for a third-party to do so, Bitwarden and 1Password are also working on it.
So my understanding would be that self-hosting is more just a matter of giving it time for others to implement the necessary components and not there being any restriction on who can do this.
Passkeys are an open standard, and they basically are just public/private keys with a wrapper. When you create a credential which is just a call to `navigator.credentials.create` with options to indicate a PublicKeyCredential type and that it should be a client-side discoverable key and a user ID to associate with it (and some optional info). Its gives you back some meta-info and the public key to store.
For a login flow, similarly a call to `navigator.credentials.get` indicating you want one of those discoverable keys to be used and a challenge. The browser returns a signature to you along with the key info (that user ID from the creation) and you are responsible to verify the signature is appropriately signed.
---
So, on the actual crypto side, nothing about it requires any centralization, there is no required phoning home or to a remote source. On the creation/storage/retrieval side, the WebAuthn Authenticator Model is defined as part of the standard so anyone can implement it. I don't know enough about how you'd register as such an authenticator. Dashlane already supports passkeys, so it is possible for a third-party to do so, Bitwarden and 1Password are also working on it.
So my understanding would be that self-hosting is more just a matter of giving it time for others to implement the necessary components and not there being any restriction on who can do this.
It will really be a shame if we got ssh-like public key authentication for the web, but can't self-host it.
[deleted]
I tried using a work computer as a guest without signing into a google account on windows, and web pages would not load for me. It kept asking for me to sign in. This was on windows. Just curious if this is the default behaviour on windows chrome now, that you can't browse the web without signing in. Switched to mac a few years back.
I wonder if they'll update Chrome to support Keychain on Mac.
"So long passwords, thanks for all the phish"
"The beginning of the end of the password"
This is confusing. Is there some plan on Google's part to kill passwords that I'm not aware of?
"The beginning of the end of the password"
This is confusing. Is there some plan on Google's part to kill passwords that I'm not aware of?
There is a plan to kill passwords, but the plan isn't just by Google. It's a unified plans across major players. In terms of marketing, anecdotally I see far more mentions of passkeys by Apple and related discussions.
Apple: https://developer.apple.com/videos/play/wwdc2021/10106/ https://developer.apple.com/passkeys/
Apple: https://developer.apple.com/videos/play/wwdc2021/10106/ https://developer.apple.com/passkeys/
That's basically the premise of the FIDO Alliance, which Google is part of: https://fidoalliance.org/what-is-fido/
Also relevant link - FIDO’s press release about Apple, MS, Google commitment to passwordless sign-ins.
https://fidoalliance.org/apple-google-and-microsoft-commit-t...
Not supported on free Google "legacy" org accounts (pre-Google Workspace), greeted with "Passkeys aren’t allowed on this account." message :/
Yea I see the same but I believe, according to their blog post, they are rolling out support on workspaces at a later date.
https://blog.google/technology/safety-security/the-beginning...
https://blog.google/technology/safety-security/the-beginning...
This is odd - as soon as this became available, I created a passkey on my Workspace account, but now it says "Passkeys aren’t allowed on this account". And it still prompts me to "simplify my sign-in experience" when I sign in on this account.
"They work on all major platforms and browsers"
Is any Linux distribution, let's say Ubuntu or Fedora a "major platform"? Is Firefox a "major browser"?
Is any Linux distribution, let's say Ubuntu or Fedora a "major platform"? Is Firefox a "major browser"?
It’s going to be anything that supports WebAuthn/FIDO2 credentials.
There are PAM modules you can install and configure for Linux and OSX.
Browser support is slightly different depending on the browser, but support for credential creation and assertion using a U2F Token (passkey) is supported by Edge, Chrome, and Firefox.
There are PAM modules you can install and configure for Linux and OSX.
Browser support is slightly different depending on the browser, but support for credential creation and assertion using a U2F Token (passkey) is supported by Edge, Chrome, and Firefox.
Very important caveat, this is only for roaming authenticators like Yubikeys (https://webauthn.me/browser-support). There is not (that I'm aware of) any support for platform authenticators on Linux (which is what most users will be thinking of when they use the word "passkey").
Roaming authentication is well supported on Linux, and you can cross-device sign in using your iOS/Android phone (assuming you haven't DeGoogled it), but the Mac/Windows experience of just having the computer itself act as an authenticator isn't supported. You're still going to need to use a locked down, proprietary device to log in, it's just that the proprietary device can help you log in on your Open device.
Roaming authentication is well supported on Linux, and you can cross-device sign in using your iOS/Android phone (assuming you haven't DeGoogled it), but the Mac/Windows experience of just having the computer itself act as an authenticator isn't supported. You're still going to need to use a locked down, proprietary device to log in, it's just that the proprietary device can help you log in on your Open device.
Can you link to more documentation on this issue? Why can my Linux box not act as an authenticator, perhaps using TPM or just with software security?
> Why can my Linux box not act as an authenticator
That is a really good question.
For whatever reason, I'm not aware of a single Open Source platform authenticator for any platform. It seems to me like that would be a pretty big priority for an Open standard, but what do I know?
Google has said they have "no plans" to support platform authentication on Linux[0]. I don't know if this is just them saying they don't plan to build a platform authenticator themselves, or if they're saying that if a Linux box advertises that it has a platform authenticator, they're not going to trust it.
Either way, passkeys basically require you to either buy a Yubikey/dongle (which will not support cloud sync) or to use a proprietary OS as your authenticator.
https://developers.google.com/identity/passkeys/supported-en...
That is a really good question.
For whatever reason, I'm not aware of a single Open Source platform authenticator for any platform. It seems to me like that would be a pretty big priority for an Open standard, but what do I know?
Google has said they have "no plans" to support platform authentication on Linux[0]. I don't know if this is just them saying they don't plan to build a platform authenticator themselves, or if they're saying that if a Linux box advertises that it has a platform authenticator, they're not going to trust it.
Either way, passkeys basically require you to either buy a Yubikey/dongle (which will not support cloud sync) or to use a proprietary OS as your authenticator.
https://developers.google.com/identity/passkeys/supported-en...
It's probably because biometrics support (via fingerprint sensors et al) isn't a standard part of the Linux desktop/notebook "platform"; and so most Linux devices would just be prompting you for a password to unlock your passkey anyway (like prompting for an SSH passphrase to unlock an SSH key) — at which point, why bother, if the whole goal was just to eliminate the possibility of being phished?
Becuase you would not be entering your password into the browser, or a web site, you'd be entering your password to a seperate password manager, presumedly with an OS-level dialog which would would be using the backend protocol to verify/hash against the origin domain and supply the right key.
iCloud syncing already has this problem though. If I lose an iPhone and I buy a new iPhone and sign into an iCloud account, my passkeys will get synced.
So I'm not sure I believe that really strong stances on potential phishing attacks are the real reason here. Passkeys with cloud sync are phishable.
> why bother
A single master password would still be a massive increase in security and would still eliminate a ton of phishing attacks. The cool parts of passkey aren't really the biometrics, the cool parts are how they get shared with websites. That's where the real phishing protection comes from.
So I'm not sure I believe that really strong stances on potential phishing attacks are the real reason here. Passkeys with cloud sync are phishable.
> why bother
A single master password would still be a massive increase in security and would still eliminate a ton of phishing attacks. The cool parts of passkey aren't really the biometrics, the cool parts are how they get shared with websites. That's where the real phishing protection comes from.
> If I lose an iPhone and I buy a new iPhone and sign into an iCloud account
Have you done that recently? What a godforsaken pain in the ass it is, especially if you don't have another Apple device handy that you are already signed in to.
Have you done that recently? What a godforsaken pain in the ass it is, especially if you don't have another Apple device handy that you are already signed in to.
It has been a fairly long while since I've needed to sync an iCloud account to a new computer. I'm mainly going off of https://support.apple.com/en-us/HT204974 so it definitely could be oversimplifying the requirements.
Though even ignoring SMS and recovery codes, I'm not sure that using a second Apple device as 2FA would change anything; we generally don't consider one-time codes to be unphishable.
But again, that's only me looking at the docs. Is there something I'm missing about the process that would block a phisher from using an iCloud password plus an SMS hijacking attack or phished one-time code to log in and set one of their devices as trusted?
Though even ignoring SMS and recovery codes, I'm not sure that using a second Apple device as 2FA would change anything; we generally don't consider one-time codes to be unphishable.
But again, that's only me looking at the docs. Is there something I'm missing about the process that would block a phisher from using an iCloud password plus an SMS hijacking attack or phished one-time code to log in and set one of their devices as trusted?
Isn’t an SMS-OTP as well as your old device’s unlock code enough?
If this is FIDO2, then it seems these projects might be useful on Linux...
https://github.com/bulwarkid
https://bulwark.id/
https://github.com/bulwarkid
https://bulwark.id/
This looks like an ssh public-private key scheme but with the private key locked to your (Google) device only. What am I missing. Why all the fuss?
It’s just a new name for WebAuthn/FIDO2 credentials. It’s easier to say, remember, and write the thus more marketable.
This support has existed for a while, but not with this rebrand. I hope more companies will adopt this approach as it seems like an effective strategy.
This support has existed for a while, but not with this rebrand. I hope more companies will adopt this approach as it seems like an effective strategy.
It's an industry standard with good cross-platform support. So you can also choose to have the private key locked to your Apple device (with iCloud syncing) and Windows too.
> with good cross-platform support
Not to rehash the entire previous post, but this should have a giant asterisk next to it. It's very technically cross-platform, but there is no batch interchange format. If you use Safari, your passkeys are only synced to iCloud. You can share them via AirDrop... to other Apple users. If you lose your phone, you can recover them... if you buy another iPhone.
You can use your iPhone to log in on a Windows device, that part is cross-platform. And you can add that device as a second authenticator. But there's no actual portability there. You have (limited) cross-platform support (there is no Open Source platform authenticator that I'm aware of, and I'm not aware of any platform authenticator for Linux). But you can likely use passkeys with whatever platform you want. It's just once you choose a platform, there's no way to export from that platform unless you per-site add a new authenticator.
Not to rehash the entire previous post, but this should have a giant asterisk next to it. It's very technically cross-platform, but there is no batch interchange format. If you use Safari, your passkeys are only synced to iCloud. You can share them via AirDrop... to other Apple users. If you lose your phone, you can recover them... if you buy another iPhone.
You can use your iPhone to log in on a Windows device, that part is cross-platform. And you can add that device as a second authenticator. But there's no actual portability there. You have (limited) cross-platform support (there is no Open Source platform authenticator that I'm aware of, and I'm not aware of any platform authenticator for Linux). But you can likely use passkeys with whatever platform you want. It's just once you choose a platform, there's no way to export from that platform unless you per-site add a new authenticator.
Passkeys are already device-bound; there would be no point in cross-ecosystem sync. They're maybe backed up to a provider's cloud, but that's in case you reformat your computer and want to restore it from backup; not for moving the passkey around.
Think of a passkey as a device identity credential. It gives credential X that you can register on your backend as belonging to device Y; not to user Y. You need to additionally keep in your backend a mapping from devices to users — where almost certainly, a user HAS MANY devices.
You know how, in well-thought-out auth systems, you can "sign in with a password" and "sign in with [SSO provider]", and those will result in signing into the same account, where both the password credential and the IdP subject-claim are separate "credentials" bound to that account?
Each passkey is a "credential bound to the account" in that sense. You create one for each device, and they all log you into the same account.
In short, they're a "third-party-ization" of the thing that Apple, Google, etc already do with their "you're trying to sign into your Apple/Google/etc account from a new device. Confirm this on an existing device" workflows — where each device creates its own separate credential, that is enrolled to your cloud account. This is that, but for any third party website, rather than just the cloud service itself.
Think of a passkey as a device identity credential. It gives credential X that you can register on your backend as belonging to device Y; not to user Y. You need to additionally keep in your backend a mapping from devices to users — where almost certainly, a user HAS MANY devices.
You know how, in well-thought-out auth systems, you can "sign in with a password" and "sign in with [SSO provider]", and those will result in signing into the same account, where both the password credential and the IdP subject-claim are separate "credentials" bound to that account?
Each passkey is a "credential bound to the account" in that sense. You create one for each device, and they all log you into the same account.
In short, they're a "third-party-ization" of the thing that Apple, Google, etc already do with their "you're trying to sign into your Apple/Google/etc account from a new device. Confirm this on an existing device" workflows — where each device creates its own separate credential, that is enrolled to your cloud account. This is that, but for any third party website, rather than just the cloud service itself.
> Passkeys are already device-bound
No, they're explicitly not, they're synced to the cloud for both iOS and Android. Microsoft also plans to do cloud sync (if they don't already).
Yubikeys are device identity credentials. Passkeys are user credentials, they get backed up off device. That's a really big deal that both Google and Apple have been heavily advertising about their implementations -- you make a passkey on your phone, lose your phone, buy a new phone, and you get your passkey back when you sign into your account. They are very much user credentials rather than device credentials; anyone who has access to your iCloud can use your passkeys.
Passkeys aren't bound to your iPhone, but they are inexplicably bound to your Apple devices. That's the portability problem. The major companies (Google, Microsoft, Apple) got rid of device-bound keys. But they kept the platform lock-in.
> where almost certainly, a user HAS MANY devices.
Speak for yourself, I have exactly one device that will work as an authenticator, and even it only works as an authenticator because I've been too lazy to install LineageOS on it.
Most people own one phone and a laptop, and they frequently travel with both of them at the same time. I think Google/Microsoft/Apple went the cloud-sync direction partially in acknowledgement of the fact that "use multiple devices" doesn't really work for everyone.
No, they're explicitly not, they're synced to the cloud for both iOS and Android. Microsoft also plans to do cloud sync (if they don't already).
Yubikeys are device identity credentials. Passkeys are user credentials, they get backed up off device. That's a really big deal that both Google and Apple have been heavily advertising about their implementations -- you make a passkey on your phone, lose your phone, buy a new phone, and you get your passkey back when you sign into your account. They are very much user credentials rather than device credentials; anyone who has access to your iCloud can use your passkeys.
Passkeys aren't bound to your iPhone, but they are inexplicably bound to your Apple devices. That's the portability problem. The major companies (Google, Microsoft, Apple) got rid of device-bound keys. But they kept the platform lock-in.
> where almost certainly, a user HAS MANY devices.
Speak for yourself, I have exactly one device that will work as an authenticator, and even it only works as an authenticator because I've been too lazy to install LineageOS on it.
Most people own one phone and a laptop, and they frequently travel with both of them at the same time. I think Google/Microsoft/Apple went the cloud-sync direction partially in acknowledgement of the fact that "use multiple devices" doesn't really work for everyone.
> Passkeys are bigger than that, they're not device bound. That's a really big deal that both Google and Apple have been advertising about their implementations -- you make a passkey on your phone, lose your phone, buy a new phone, and you get your passkey back.
You're interpreting "device" differently than I am, here. Maybe let me use a different word.
There's a physical hardware device (the device's "body") and then there's a particular installation of an OS (the device's "soul.") Unlike humans, these device "souls" can leave and come back (restoring from backup) or be reincarnated into a different body (transferring a backup to a new hardware device.)
What Apple, Google, etc. are claiming is that passkey credentials are bound to the soul of your device — the unique installation session that resulted in a unique product-key "activation" in their servers — rather than to the body of your device. So wherever the installation goes, the passkeys go along with it.
But this does not mean that passkeys are portable between installations. They still inherently represent "devices" — just semantic, abstract devices, that may be incarnated at any given time in zero or one physical hardware devices.
And, again, this is exactly how Apple's and Google's own device enrolment for sign-in to their respective cloud accounts works. I have devices listed in my iCloud account that currently have no "incarnated" form — the hardware was wiped, sold, and is now being used by someone else! — but those unique installations do still "exist" and could be "reincarnated", as long as I keep my iCloud Backup of them.
You're interpreting "device" differently than I am, here. Maybe let me use a different word.
There's a physical hardware device (the device's "body") and then there's a particular installation of an OS (the device's "soul.") Unlike humans, these device "souls" can leave and come back (restoring from backup) or be reincarnated into a different body (transferring a backup to a new hardware device.)
What Apple, Google, etc. are claiming is that passkey credentials are bound to the soul of your device — the unique installation session that resulted in a unique product-key "activation" in their servers — rather than to the body of your device. So wherever the installation goes, the passkeys go along with it.
But this does not mean that passkeys are portable between installations. They still inherently represent "devices" — just semantic, abstract devices, that may be incarnated at any given time in zero or one physical hardware devices.
And, again, this is exactly how Apple's and Google's own device enrolment for sign-in to their respective cloud accounts works. I have devices listed in my iCloud account that currently have no "incarnated" form — the hardware was wiped, sold, and is now being used by someone else! — but those unique installations do still "exist" and could be "reincarnated", as long as I keep my iCloud Backup of them.
> There's a physical hardware device (the device's "body") and then there's a particular installation of an OS (the device's "soul.")
This is an interesting theory of device uniqueness that would be potentially cool to build a service around, but it is inaccurate to how passkeys are implemented.
iCloud sync is cross-device; if you make a passkey on your iOS device, it gets synced to your Mac. You can also share them with other iOS devices that aren't even linked to your iCloud account using Airdrop. They're very separate from the OS or "instance" of your device's software.
And in fact, you actually can't use platform authentication in Safari unless you sign into an iCloud account to sync your keys. Not only is it not tied to the "soul" of the device, you're not allowed to tie it to the soul of the device. Apple requires you to tie it to your account.
This is an interesting theory of device uniqueness that would be potentially cool to build a service around, but it is inaccurate to how passkeys are implemented.
iCloud sync is cross-device; if you make a passkey on your iOS device, it gets synced to your Mac. You can also share them with other iOS devices that aren't even linked to your iCloud account using Airdrop. They're very separate from the OS or "instance" of your device's software.
And in fact, you actually can't use platform authentication in Safari unless you sign into an iCloud account to sync your keys. Not only is it not tied to the "soul" of the device, you're not allowed to tie it to the soul of the device. Apple requires you to tie it to your account.
[deleted]
There's no meaningful benefit of this over a password and 2FA authentication for users who are already proactive about security. I also doubt that passkeys will be protected by the fifth amendment the way passwords are, based on the "key vs combination" argument. While I trust Google password manager to help me remember passwords and even use sign in with google, I don't want to let Google or any company to manage my initial method of authentication for me.
At their core, passkeys are a easy and nice way to move from passwords to public private key cryptography. And hardware based authentication does allow more security. And by leveraging the tpm, hardware-backed keystore, or security enclave, you can use your phone and computer the way FIDO keys are already used.
But there are many reasons why I will wait as long as possible, maybe indefinitely before I start using passkeys. The idea of this being tied to Google or any other major company for my logins is not okay. There are many cases of people being locked out of Google accounts without the ability to appeal. I don't appreciate the idea of large companies being able to whitelist which passkeys are allowed, which is possible depending on how attestation certificates are handled. With current 2factor, you can control the secrets yourself if you choose to. While it's true that you can't be phished into sharing your passkey as easily, you also lose a lot of convience and flexibility in login management. And it makes login sharing or multi-account management very inconvenient and difficult.
I was hopeful with 2FA rolled out that my accounts would be more secure, but most companies give you very little control over which methods of 2FA are allowed or enabled. I don't want to be forced to enroll a phone number just to enable TOTP 2FA. I want to be able to choose between TOTP or HOTP for my accounts. I don't want to be forced to use a 2FA app that doesn't allow me to export and manage the secrets myself. In some ways FIDO keys solve some of those issues, but the hardware security aspect of it contradicts giving the end user the choice to self manage. I expect some policies will change over time based on uptake and issues people face.
https://www.concordlawschool.edu/blog/constitutional-law/fif...
Edit: Apparently, in iOS and Android, passkeys are backed up to the cloud, and iOS even allows you to airdrop them.
https://www.nytimes.com/wirecutter/blog/what-are-passkeys-an...
At their core, passkeys are a easy and nice way to move from passwords to public private key cryptography. And hardware based authentication does allow more security. And by leveraging the tpm, hardware-backed keystore, or security enclave, you can use your phone and computer the way FIDO keys are already used.
But there are many reasons why I will wait as long as possible, maybe indefinitely before I start using passkeys. The idea of this being tied to Google or any other major company for my logins is not okay. There are many cases of people being locked out of Google accounts without the ability to appeal. I don't appreciate the idea of large companies being able to whitelist which passkeys are allowed, which is possible depending on how attestation certificates are handled. With current 2factor, you can control the secrets yourself if you choose to. While it's true that you can't be phished into sharing your passkey as easily, you also lose a lot of convience and flexibility in login management. And it makes login sharing or multi-account management very inconvenient and difficult.
I was hopeful with 2FA rolled out that my accounts would be more secure, but most companies give you very little control over which methods of 2FA are allowed or enabled. I don't want to be forced to enroll a phone number just to enable TOTP 2FA. I want to be able to choose between TOTP or HOTP for my accounts. I don't want to be forced to use a 2FA app that doesn't allow me to export and manage the secrets myself. In some ways FIDO keys solve some of those issues, but the hardware security aspect of it contradicts giving the end user the choice to self manage. I expect some policies will change over time based on uptake and issues people face.
https://www.concordlawschool.edu/blog/constitutional-law/fif...
Edit: Apparently, in iOS and Android, passkeys are backed up to the cloud, and iOS even allows you to airdrop them.
https://www.nytimes.com/wirecutter/blog/what-are-passkeys-an...
Wait, this lets you use your device as the "passkey" to log-in into Google instead of you typing your Google account password. I don't quite follow how your lack of trust in Google password manager is relevant.
Most people will be using passkeys stored by Google or Apple's password manager services, in which case the device is an authenticator for the password manager, not the passkey. I think GP is saying they would trust password managers with passkeys less than with credentials because passkeys won't be usable without access to the password manager, and will be difficult-to-impossible to recover and to move between services.
> Unlike passwords, passkeys can only exist on your devices. They cannot be written down or accidentally given to a bad actor.
Pegasus ?
Pegasus ?
They negate this later with:
> In addition, some platforms securely back your passkeys up and sync them to other devices you own.
If they can be copied (or "synced"), they can be copied to a piece of paper and copied to a nefarious actor.
> In addition, some platforms securely back your passkeys up and sync them to other devices you own.
If they can be copied (or "synced"), they can be copied to a piece of paper and copied to a nefarious actor.
As far as I get hacking into phone and root access is not enough to extract secret key. There also Secure Enclave exploit needed and supposedly it will be much harder to come by.
I assume the goal is to keep people logged in. The bullshit reason is to get rid of passwords. I have passwords that are strong and 20 years old, so I regard passkey as evil.
Again, a reminder that this is an across the board terrible awful idea.
It's all the dangers of 3rd party passwords - namely, before you had two parties, now you have three and thus inherently less safe - but worse.
Now, it's just even HARDER for you to control your own keys to your own stuff.
There's one and only one reasonable way to execute this, and that's to include huge liability for the 3rd parties. Unless they'll pay up or otherwise fix in the event of a breach, this is a non-starter.
It's all the dangers of 3rd party passwords - namely, before you had two parties, now you have three and thus inherently less safe - but worse.
Now, it's just even HARDER for you to control your own keys to your own stuff.
There's one and only one reasonable way to execute this, and that's to include huge liability for the 3rd parties. Unless they'll pay up or otherwise fix in the event of a breach, this is a non-starter.
I don't understand your concern. How is it more difficult to control the keys? Why is it less secure than 2fa solutions?
Every worry I've heard about passkeys can be leveled at 2fa schemes as well. The upside of passkeys is they can't be phished, can't be revealed in data breaches, and can't be forgotten. What third company is involved? Are you thinking about syncing services? With the exception of Linux (for now), you can have passkeys enabled on any modern device. It is just public/private key sharing right?
A bad actor would have to have your device and be able to unlock it in order to get access to your accounts secured with passkeys. Every time passkeys are mentioned on HN the FUD starts flying and people lose their minds. Passwords are terrible with many weaknesses. There isn't perfect security, there are always weaknesses but I have yet to be shown how passkeys are worse than passwords for typical users.
Every worry I've heard about passkeys can be leveled at 2fa schemes as well. The upside of passkeys is they can't be phished, can't be revealed in data breaches, and can't be forgotten. What third company is involved? Are you thinking about syncing services? With the exception of Linux (for now), you can have passkeys enabled on any modern device. It is just public/private key sharing right?
A bad actor would have to have your device and be able to unlock it in order to get access to your accounts secured with passkeys. Every time passkeys are mentioned on HN the FUD starts flying and people lose their minds. Passwords are terrible with many weaknesses. There isn't perfect security, there are always weaknesses but I have yet to be shown how passkeys are worse than passwords for typical users.
My specific concern is the "tied to a device". The only devices that seem to support the keys are proprietary devices, that only offer to backup the passkeys to their proprietary services.
I can't see myself using this unless I can store the passkeys in my own keepassx (or similar) system, that I can manage 100% the backup, replication + storage of myself, without any assistance from a 3rd party.
I can't see myself using this unless I can store the passkeys in my own keepassx (or similar) system, that I can manage 100% the backup, replication + storage of myself, without any assistance from a 3rd party.
> Passwords are terrible with many weaknesses.
One being, when you're entering them on a phone in public, someone can watch you type them. This makes them easier to clone than biometrics.
One being, when you're entering them on a phone in public, someone can watch you type them. This makes them easier to clone than biometrics.
Oh come on. You can CHANGE passwords. That's the the point.
Passwords are safer not because they're bulletproof. They're safer because they fail elegantly. You can't change biometrics and that's why they're definitely worse. They might be acceptable as one of many factors, but they're absolutely the worst idea for a primary.
Passwords are safer not because they're bulletproof. They're safer because they fail elegantly. You can't change biometrics and that's why they're definitely worse. They might be acceptable as one of many factors, but they're absolutely the worst idea for a primary.
How do you know when to change the password?
> You can't change biometrics and that's why they're definitely worse.
Sure you can, you've got ten fingers and after that all it takes is a blowtorch.
> You can't change biometrics and that's why they're definitely worse.
Sure you can, you've got ten fingers and after that all it takes is a blowtorch.
This presumes Google is never the bad actor, not a smart assumption.
I think it’s a nonstarter because the n00bs and n0rm1es will have no idea what to make of it, and will quickly go back to passwords because they just work predictably.
To me it reeks of something that looked great, when you show a room of engineers. But for regular people?
To me it reeks of something that looked great, when you show a room of engineers. But for regular people?
Perhaps, but I recently added passkeys for Apple and Google accounts and the actual enrollment process and login didn't feel much more complicated than using the built in password manager for Chrome plus Touch or Face ID which people are already familiar with.
That itself may be too complicated for some but it essentially was a few automatic prompts and instructions to scan my finger to login after it was done.
That itself may be too complicated for some but it essentially was a few automatic prompts and instructions to scan my finger to login after it was done.
1. If you are using this to authenticate a non-Google service, can Google cut off your access to that service?
2. If your Google account is terminated, do you still have access to non-Google services?
3. Does Google possess sufficient information to log into non-Google services as you?
4. In the event that any of the above happen, do you still have the right to sue Google?