Live data from Hacker News

Passkeys: The beginning of the end of the password

blog.google

251–260 of 1001 posts

Re: Passkeys: The beginning of the end of the password

#251
post #246
post #5

How is this more secure? They say "with a fingerprint, a face scan or a screen lock PIN", but basically all phones let you fall back to PINs if you dont want to do face or fingerprints. Pins are flat out not secure - typically just 4 digits. Yeah its probably better than 80% of people having "password123", but it seems strictly worse than a password + password manager? Or at least just having proper 2FA.

Being tied to a device, it defeats the most serious threats of phishing and weak passwords, for which attacks can be mounted on a global scale. 2FA via SMS is still vulnerable. 2FA with an app like Google Authenticator or VIPAccess is more secure because it is tied to a device.

The devices are far from being security bastion.

Re: Passkeys: The beginning of the end of the password

#252
post #238

I'm curious to get a take on Apple's documentation for passkeys and iCloud Keychain Recovery Escrow system [1] [2] There's multiple references in this documentation to phrases like "To sign in for the first time on any new device, two pieces of information are required—the Apple ID password and a six-digit verification code" or in the no-device-recovery escrow documentation: "users must authenticate with their iCloud…

My presumption has been that they will force a long recovery key to be printed by you for recovery OR the enrollment of designated trusted users that can approve an account recovery.

They already force you to do either of those things if you want end-to-end encryption for all content types (which they called increased data protection).

Re: Passkeys: The beginning of the end of the password

#253
post #163
post #94

There is a legal advantage that passwords have that passkeys and FIDO and so on do not have. In civilized countries, no one can force you to hand over a password (as you have a right to not incriminate yourself). That does not hold for property which can be confiscated or even biometric attributes which can be taken against your will legally. Theoretically, passkeys could still offer this advantage if they are stored…

Passkeys are an authentication mechanism, and as such replace (authentication) passwords, not (encryption) passphrases. A password (at least as I understand the term) is used to authenticate to some third-party entity to get access to your data or services. The (implied or legal) contract here is: "Only give access to my data to anybody that can provide my password." Government authorities can in most cases just go t…

Great! Where I can type those passhphrase in google mail or o365 or million other serivces to secure my data ?

Oh? Nowhere? Then why you're even talking about the distinction ?

Also passphrase definition is definitely not "a password used for encryption", I dunno where you pulled that from. Original meaning is just "longer, more secure password"

Re: Passkeys: The beginning of the end of the password

#254
post #15

Earlier quoted context omitted.

Because it's a PIN protecting a certificate stored on the device. Even if you know the PIN but don't have access to the device, you can't use it.

And the pin is the same functionality as activating a hardware authenticator like a Yubikey.

… which have historically yielded credentials at any touch, without a need for a PIN, fingerprint, or face scan.

Re: Passkeys: The beginning of the end of the password

#255

I’m a Linux user. I don’t have an android/iOS/macOS/Windows machine. Is there a solution? Is this being used to push Linux users off the internet? Can I just fire up emulated Android and be ok? Am I screwed? Googling indicates I am, indeed, screwed. Pretty concerned about this future.

Yubikey is supported; which has linux compatibility.

Re: Passkeys: The beginning of the end of the password

#256
post #189

This looks and feels like passwords with extra steps... I mean now i need to "store, manage and secure" my per-user-certificate sorry "my passkey" myself and if its get compromised its my fault, how are passkeys more "secure" than enforcing a secure long password that the user can't change unless he met certain conditions and its conveniently stored inside the password manager i just built. What happens if i lost all…

Passwords can be both stolen (they are valid for multiple authentications) and are susceptible to phishing/MITM attacks. TOTP/HOTP solves the first problem by making the credential provided during authentications single-use, but they're still susceptible to phishing/MITMs (since you don't know where you're entering your OTP). WebAuthN solves both. > What happens if i lost all my devices due to a fire? Passkeys are sy…

> Passkeys are synchronized to your device ecosystem vendor by default (i.e. Google or Apple, and soon also third-party password maangers on Android)

That's a showstopper for me, personally. Not saying the idea is a bad one (at all!), but I won't be using it for myself.

Re: Passkeys: The beginning of the end of the password

#257

I wrote about my experience with passkey support on other services here: https://news.ycombinator.com/item?id=35758918 . That experience was mostly negative. For anyone implementing this, the user experience matters and requires usability testing of a lot of combinations. In comparison to those, Google’s support seems better. It worked, was transparent about what was going on, and gave me the option to create the key…

> it just said I already had a registered key on this device Is this Android? Because, before this change, there was no way to register a real WebAuthn-based passkey with Google, at least when I was trying with chrome (it did not prompt the webauthn popup, just the OS-native security key popup).

This was on an iPad. My experience before had been that I was able to register an iCloud passkey for Google 2SV when using Safari on iOS/iPadOS, but I was unable with Chrome.

At that time, I inspected the registration request Google sent to Chrome and found it was passing a private option that Chrome recognized. According to what I found in web searches for it, the option created a legacy U2F key, and they needed to do that because there were existing Android devices that they could not upgrade and that would not support log-in with WebAuthn keys.

Re: Passkeys: The beginning of the end of the password

#258
post #5

How is this more secure? They say "with a fingerprint, a face scan or a screen lock PIN", but basically all phones let you fall back to PINs if you dont want to do face or fingerprints. Pins are flat out not secure - typically just 4 digits. Yeah its probably better than 80% of people having "password123", but it seems strictly worse than a password + password manager? Or at least just having proper 2FA.

This is more secure, passwords can't be stolen from the site. Sure, let's go with the assumption that your phone can be stolen. It would be only your phone. If a site has 100 million users, an attacker could steal 100 million passwords. With this approach, the attacker would have to steal 100 million phones. No matter what password manager you use, with a password length of 100 characters. The entire password list (e…

This keeps you from ever sending the password to the site (similar to e.g. SRP).

Most sites already don't store the password. If you have a sufficiently strong password (i.e. very long, randomly generated, stored in a password manager), it is likely not computationally easier to recover the password from a hash than it is from a public-key. The only improvement here is that you don't have to trust that the site is following best-practices for storing passwords, as you never send them the password.

[edit]

It also prevents phishing attacks for those using some form of entering a password other than autofill from the password-manager.

Re: Passkeys: The beginning of the end of the password

#259
post #135

WebAuthN is great, but I can't help but feel that Passkeys are actually a step backwards. At least on iOS, there is no way of preventing them from being synced to iCloud, which is the opposite of what I want for high-stakes credentials like bank accounts or government e-signatures. I've tried to raise [1] a related issue (i.e. the inability for relying parties to opt out of credential syncing, if not an explicit requ…

You can't even use Passkeys on iOS without using iCloud; if you opt out of iCloud, Passkeys are disabled.
Post reply on HN