The passkey ecosystem is far from complete, but Google's implementation is now ready to use.
See full article...
See full article...
If you write an article to tell us that passkeys are great, and a bunch of people comment that they sound terrible, then something's wrong with the way you tried to convince us.
Honestly I am going a bit further than that.The cynic in me wants to lean towards marketing at least from Google's end. I feel like I see less explanations of the mechanics of Passkeys and more Google shoehorning the phrase "death of the password" into as many news releases as possible.
Now you're putting words in my mouth, and you know it too because you didn't do it in your original response. I guess it occured to you that 2FA codes are useless by themselves and easily changed.than potentially copied sheet with all your services/usernames/passwords
It's a lot harder to change your PII then it is to revoke and change 2FA codesthe rest stays in my wallet and can easily be replaced if compromised.
Maybe.I have to wonder how much more secure it is in practice. It seems to me that it's a pretty complex system with lots of moving parts. The more complex something is, the more likely there are security issues.
I get the theoretical improvement, but the devil is in the (implementation) details. I think I'd rather wait and see than jump in with both feet.
That's exactly what I said.If you use strong passwords, never use the same password (or an obvious variation like your dog’s name + the company name) on multiple sites, and never get phished, you’re fine if slower and less convenient. Unfortunately, that doesn’t work in practice - the reason why Apple, Google, and Microsoft implemented this is that they have literally millions of users who were compromised after failing at least one of those requirements.
Guessing that'd be those terrible, horrible insecure passwords? Hmmm ....
This seems such a terrible idea. If you know what you're doing, it seems neither easier nor faster nor more secure. I would rather not trust all my security to having a second device with me.
And I worry about the power border agents have to compel device biometrics, and through that, access to everything you have a login for.
The way a person who primarily uses Android and Linux logs in will look different and use a different flow than a person who uses all Apple platforms or a person who uses iOS or Android with Windows. There’s no way to list step-by-step instructions for all platforms in one article.
The fatal drawback isn't technical, rather it's about ease of use.Or, as we’ve seen in both recent thread, a group of people who read something scary about WebAuthn and didn’t verify the technical details but didn’t let that stop them from repeating the same falsehoods in every story. When you have a W3C standard implemented by most of the industry and recommended by almost all actual security experts, it’s probably not the case that someone randomly confabulating in a message board has uncovered a fatal drawback everyone else missed.
Good news, it’s still not a requirement and never has been.Among numerous issues that make me skeptical, the bluetooth requirement is a hard "No".
Disabled on my phone since day 1, and never on my laptop.
Complete dogshit communication protocol, and should never EVER be part of any authentication scheme.
Where do you keep those recovery codes and how do you get to them? Especially if, say, you drop your phone in a well while abroad?The fallback if you lose access to every device is a recovery code. That’s better than a password because it’s strong, unique, and can only be used once.
This is why everyone has issues with all these articles. Some claim bluetooth is required for proximity verification, others say it isn't. The "official" documentation is severely lacking, the password manager documentation doesn't actually state one way or the other. This seems like an incomplete integration.Good news, it’s still not a requirement and never has been.
It’s a matter of perspective. Security experts worry about a third party getting into their stuff. Non-security experts worry about accidentally irreversibly encrypting all of the family photos.Or, as we’ve seen in both recent thread, a group of people who read something scary about WebAuthn and didn’t verify the technical details but didn’t let that stop them from repeating the same falsehoods in every story. When you have a W3C standard implemented by most of the industry and recommended by almost all actual security experts, it’s probably not the case that someone randomly confabulating in a message board has uncovered a fatal drawback everyone else missed.
How is this multistep process easier than filling in a password?Passkeys are much, much easier to use so I don’t think this qualifies as fatal.
Passkeys without bluetooth proximity are going to be just as easy (if not easier) to phish due to push notification authentication.No, it’s not. You’re still easily phishable (yeah, I know you think otherwise. Lots of people make that mistake.) and that’s the most popular way to compromise people.
Passkeys are much, much easier to use so I don’t think this qualifies as fatal.
You’ve turned them on, right?
A question.
If a device with passkeys is fully compromised; does the bad actor now have access to authenticate to all of my accounts everywhere from that device (since he has the passkeys and is passing whatever security that particular device uses)?
I mean: I realize that my Yubikey has a similar problem (if someone physically has it, they can get to all my stuff), so this isn't necessarily new; but still.
This is why everyone has issues with all these articles. Some claim bluetooth is required for proximity verification, others say it isn't. The "official" documentation is severely lacking, the password manager documentation doesn't actually state one way or the other. This seems like an incomplete integration.
Talk about overlooking. "Somewhere safe" means "somewhere only I can get to after authenticating". This is like saying that I need to keep the spare key to my safe in my safe.Every service I've used that does recovery codes (usually required when enabling TOTP 2FA), basically yells at you HERE ARE YOUR RECOVERY CODES, SAVE THEM SOMEWHERE SAFE AND PRINT THEM OUT AS HARD COPY when you get to the point of setup where they'd be activated. This is not something, I think, that is actually worth worrying about people overlooking.
The app is the Camera. On iOS, pointing the normal camera app at the QR code shows a small yellow label/link saying "Sign in with a passkey". Dunno what Android does, but I'd wager it's similar.I'm not sure having to go find your phone, find the app to scan the QR code with, I guess you'd have had to go thru some setup for fingerprints...and hope it accepts your fingerprint (I have issues with fingerprint unlock on the devices I've tried it, such as after working in the yard or on the car it won't accept until my skin heals fully for several days).
That doesn't fit what I would call "easy"
I think it's simpler.Honestly I am going a bit further than that.
As I've been thinking about this a lot lately. This shifts the burden nearly to be entirely client's fault if this gets fully implemented. Database/password breaches are no longer what compromise individuals, but rather a loss of physical device or pressing "allow" on their passkey manager. This is a significant shift in liability if anyone's account were to get popped in the future as they can claim that nothing on their end can prevent this.
And this huge PR push/partial astroturfing claiming it will kill passwords without actually going into said details makes me continue down this rabbit hole.
Not only that, but unless they truly enforce the bluetooth requirement (which I highly doubt because that would effectively block people from granting temporary access to family/friends that are far from them) then as a single factor, this doesn't actually provide the common-person very much security benefits, but provides corporations huge liability benefits.
Also if you can remember your password, it will always be available to you, no matter the location or situation.How is this easier? It's like 10 steps to first login. It's mindbogglingly complex set of decisions with no clear consequences to an average user. Only an IT or security person would think this is easy.
A password is a lot easier even if it's insecure. The mental model is way simplet.
Where are you getting this information?It’s only a problem in that the comment sections are full of people repeating FUD without verifying any of the details (similar to the urban legends about biometrics).
Passkeys work on any device you’ve enrolled. Each device has a key which can be used to login and that works even if you’re in airplane mode on an isolated network.
Where Bluetooth comes in is one option when you want to use a system which does not have the passkey but you have something like a phone which does. You could login on, say, a public computer by using your phone to answer the challenge for that computer, where Bluetooth prevents an attack from occurring at more than a short distance from your phone (I.e. some guy in Belarus trying to phish you can’t do local Bluetooth and even if they could, the response timing check would fail). This is a convenience for that scenario but if that’s not something you do, you don’t need to think about it.
And what about all of the hospitals and manufacturing plants that rely entirely on thin clients via Citrix or RDP, where there is zero bluetooth support back to the host PC?I imagine all the desktop Windows computers used in businesses and government would need a whole lot of Bluetooth dongles to implement this.
Well, you just log into Find My, using your passkey, to locate/remote wipe your phone and….. oh
They charge websites/developers for "serverless" authentication service. It's not cheap either. After 10k verifications/mo free, it costs something like $0.01-0.05 per login.While Dan Goodin does a great job explaining the privacy and security benefits of Google Passkey system I must freely admit I do not trust Google about anything whatsoever. Especially, the Google Cloud.
I have to ask myself how has or will Google monetize their passkey system?
I can only assume we will pay with our private personal data put on sale, I mean securely shared with trusted third parties for a fee or as required by law, or corporate policy to improve the world or just because they feel like it.
I would be willing to pay a reasonable ONE TIME fee for a passkey authentication system that is truly, demonstrably beyound all reasonable doubt, private and secure.
Dan Goodin: Google passkeys are a no-brainer. You’ve turned them on, right?
Ron Amadeo: Switching [to passkeys] is probably a terrible idea right now
You do have a Ars Technica Slack, right? I'm wondering if there was a discussion there about the current maturity of Google's passkey implementation...
That's a good start, but unless you have at least two named authentication methods who have a conversation about something other than a man you're not going to be secure.Still not enough... you'll also need something borrowed and something blue. You'll need an old priest and a young priest. You'll need a raven's egg, blood of a hen, eyeballs of a crocodile and resticles of a newt.
keep in mind that the Supreme Court has upheld that you cannot be compelled to provide something you know, but that you can be compelled to provide something you have, and something you are.
Doesn’t that make passkeys kind of useless? I mean, now you have a non-passkey attack vector.Actually you just get your replacement phone, restore it from iCloud backups (which doesn’t require passkey, but whatever methods you set up with Apple), and then sync iCloud Keychain … which requires your old/lost devices unlock code worst case. Apple doesn’t know that, but you do. Once that’s done, you’re back in business….