Questions:<p>1. If you are using this to authenticate a non-Google service, can Google cut off your access to that service?<p>2. If your Google account is terminated, do you still have access to non-Google services?<p>3. Does Google possess sufficient information to log into non-Google services as you?<p>4. In the event that any of the above happen, do you still have the right to sue Google?
Yet they still don't have a way to disable the 2FA prompt offered in the Gmail app (called "Google prompt").<p>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.<p>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.
How is this, practically, any better than existing 2FA? A 2FA code is stored on a device just like a passkey is.<p>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.
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 <i>durability</i> of my digital life <i>much</i> more seriously.<p>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.<p>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)?<p>I know that this is "possible"; it's all based on data and secrets recorded <i>somewhere</i>, 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?<p>[0] - <a href="https://github.com/susam/mintotp/blob/main/mintotp.py">https://github.com/susam/mintotp/blob/main/mintotp.py</a>
Related discussion yesterday at <a href="https://news.ycombinator.com/item?id=35801392" rel="nofollow">https://news.ycombinator.com/item?id=35801392</a>
> Passkey sync providers like the Google Password Manager and iCloud Keychain use end-to-end encryption to keep your passkeys private.<p><a href="https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html" rel="nofollow">https://security.googleblog.com/2022/10/SecurityofPasskeysin...</a> <i>claims</i> it's encrypted using "an encryption key that is only accessible on the user's own devices":<p>> 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.<p>> 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.<p>> 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.<p>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?
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.
>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.<p>So my password that I stupidly shared among my accounts and was then leaked, can still be used to compromise my Google Account.<p>Wake me when I can create a Google Account without a password, email, or phone number, period.
This still feels like a beta product, with a foot-gun of a UX<p>* 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)<p>* How does this work with desktop PCs that don't have a camera?<p>* 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.<p>It reminds me of the XKCD "standard" that now means we have n+1 protocols
can someone who understands the cryptographic basis explain how centralized this is?<p>it sounds like an app can consume passkey logins without registering with a provider?<p>do providers phone home when I log in? can providers block an app from using them?<p>can I self-host a provider, or is there a shortlist of approved providers?<p>is there any provider that allows me to backup private key without sending it to their cloud?<p>is it similar to openid in that it shares email etc with the app on login?
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.
"So long passwords, thanks for all the phish"<p>"The beginning of the end of the password"<p>This is confusing. Is there some plan on Google's part to kill passwords that I'm not aware of?
Not supported on free Google "legacy" org accounts (pre-Google Workspace), greeted with "Passkeys aren’t allowed on this account." message :/
"They work on all major platforms and browsers"<p>Is any Linux distribution, let's say Ubuntu or Fedora a "major platform"? Is Firefox a "major browser"?
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.<p>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.<p>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.<p>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.<p><a href="https://www.concordlawschool.edu/blog/constitutional-law/fifth-amendment-biometrics/" rel="nofollow">https://www.concordlawschool.edu/blog/constitutional-law/fif...</a><p>Edit:
Apparently, in iOS and Android, passkeys are backed up to the cloud, and iOS even allows you to airdrop them.<p><a href="https://www.nytimes.com/wirecutter/blog/what-are-passkeys-and-how-they-can-replace-passwords/" rel="nofollow">https://www.nytimes.com/wirecutter/blog/what-are-passkeys-an...</a>
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 <i>across the board terrible awful idea.</i><p>It's all the dangers of 3rd party passwords - namely, before you had two parties, now you have three and thus <i>inherently</i> less safe - but worse.<p>Now, it's just even HARDER for you to control your own keys to your own stuff.<p>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.