Live data from Hacker News

Passkeys: The beginning of the end of the password

blog.google

741–750 of 1001 posts

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

#746
post #365

Earlier quoted context omitted.

This is incorrect because you’re conflating access by request and access with a court order. Without a warrant, or even probable cause, police can get some meta data, but not everything in the cloud. In many places police can force you to use biometrics to unlock devices, but not compel a passphrase. (Passphrases are significantly harder for e.g. Greykey to glitch brute force than PINs.)

What's "access by request"? > Passphrases are significantly harder for e.g. Greykey to glitch brute force than PINs. PINs are their own thing, i.e. neither passwords nor passphrases. They form a hierarchy: Passphrases: High (enough) entropy; can be stretched into an encryption key using a PBKDF. Passwords: Medium entropy; long enough to be somewhat brute-force resistant in case of a database breach. Can't really be u…

The police just ask the company for the data.

https://en.wikipedia.org/wiki/Third-party_doctrine

---

You're introducing key stretching for unknown reasons. It's irrelevant for attacks on e.g. iPhones -- they're not cracking encryption, they're doing dictionary attacks.

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

#747

Earlier quoted context omitted.

You have the option to use a non cloud password sync method today. Best of all, that can sync a single password or private key across multiple vendors. This locking down inside bubbles really needs to go for me to want to use passkeys, I don't want to register 3 separate passkeys for each account I want to register 1 and sync them between my devices.

You’re not the target. Your average user who doesn’t even know what a password manager is or doesn’t want to use one is.

Agreed I'm not the average user but what does that have to do with the passkeys not being exportable between devices/clouds and instead being forever locked into only that vendor's cloud? The average user does not own only Google or only Apple or only Microsoft products nor do they want to enroll every account for every new device manufacturer key store instead of have options to use something else. This isn't predicated on existing use of a password manager it's just also a downgrade from that aspect of them.

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

#748
post #505
post #487

Just here to note that there are several huge problems with this approach from an actual security standpoint: First is that this changes from 2-factor authentication (something you have plus something you know) to single-factor (just something you have). Also be sure to notice in the article that they have changed their term there to 2-STEP authentication, not 2-FACTOR authentication, these are not the same thing, an…

On the contrary, it _is_ 2FA: One factor is something you have (the phone) and the other is something you are (your biometrics ). You need both to log in. The difference here is you're allowing your phone's enclave to store the magic secret, instead of your human memory. —If you're authenticating with a PIN instead of biometrics, it's still 2FA.

The phone unlocks with the bio-metrics but the passkey has no additional lock. Be careful to take note of what thing you are actually "unlocking".

For example, if your 2fa codes for a service are always sent to an email account that uses the same password as the site for that service, then you do not actually have 2FA in that case since any potential attacker just needs the one password to get into your email account and that automatically gives them access to the other service.

If the passkey is stored on the device, and the device unlocks by bio-metrics only, and there is nothing additional but to tap the yes button on a notification in order to get logged in. Then the site or service you are logging in to, has only one factor authentication. You can also notice this in the fact that the system here does not send the raw bio-metric data to the service, only the passkey. Therefore if someone copies your passkey or finds a way to man-in-the-middle the key exchange, they can unlock the the service without having your phone. Again one factor.

For it to be a true 2-FA system, you would have to send the evidence of what you are and actually hand over what you have. Both would be checked, and only then would you be logged in.

In the case of the usual password plus auth app codes. The codes, and the keys the are generated, from are in the auth app. That's not ideal either, it can still be messed with, but that's why we pair it with something you know, which is not stored anywhere (if it is written down anywhere, even as uncovered text in a database, or a file on your device, then the password is not a password any more, it's just something else you have).

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

#749
post #487

Just here to note that there are several huge problems with this approach from an actual security standpoint: First is that this changes from 2-factor authentication (something you have plus something you know) to single-factor (just something you have). Also be sure to notice in the article that they have changed their term there to 2-STEP authentication, not 2-FACTOR authentication, these are not the same thing, an…

I completely disagree. Even if you are concerned about evil maids (which are comparatively very rare), it is not the case that passkeys are "strictly worse" than a password. The core advantage is that they cannot be phished. And not only does phishing exist, it is way more common than people stealing your hardware used to authenticate you with a passkey.

In the case of networked hardware, the stealing the device part is a relatively minor concern.

For the case of passkeys, expect the bad actors currently playing the phishing game to shift from getting you to enter your password on a fake site, to getting you to install an app that either triggers the push notification to send the passkey or has a way to lift the passkey off the device directly. And in order for this tech to be useful, it will have to be expanded to cover nearly all sites and services available on the internet. So phishing will still happen in the form of bogus sites and services getting past whatever app verification equivalent process Google tries to put in place for services that would like to integrate with their passkey provider.

My claim that the passkeys are strictly worse than passwords applies specifically in the sense that, as a form of authentication, passkeys do not prove that the person logging into the site is actually the person they say they are. Passwords prove that only in the case that no one, who is not you, knows your password. Passkeys only prove you are who you say you are in the case that no one, who is not you, can unlock or otherwise get access to your networked and only loosely secured smartphone. It is easier to hack or steal a phone than it is to read your mind.

Though I grant you the point that one doesn't always have to read the mind, only trick it into giving up the goods. Fair enough but that is still the owner of the password DOING something whereas phones can be broken into through the network, through something the user did (like downloading malware), or through something they didn't do or know to do (like downloading updates).

It can also be broken into by way of something the owner had no control over, like a supply chain attack on app or system updates, a compromised third party service for one of the legit apps you have installed, or a zero-day hack for an app or the system itself.

Those situations are exactly why password systems must be designed NOT to store the password on any devices, whether that's a file on a phone or laptop, or a cell in a database. Every time the password is written down, it is effectively already compromised as an authentication tool because it's no longer just something you know.

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

#750
post #749

Earlier quoted context omitted.

I completely disagree. Even if you are concerned about evil maids (which are comparatively very rare), it is not the case that passkeys are "strictly worse" than a password. The core advantage is that they cannot be phished. And not only does phishing exist, it is way more common than people stealing your hardware used to authenticate you with a passkey.

In the case of networked hardware, the stealing the device part is a relatively minor concern. For the case of passkeys, expect the bad actors currently playing the phishing game to shift from getting you to enter your password on a fake site, to getting you to install an app that either triggers the push notification to send the passkey or has a way to lift the passkey off the device directly. And in order for this…

> My claim that the passkeys are strictly worse than passwords applies specifically in the sense that, as a form of authentication, passkeys do not prove that the person logging into the site is actually the person they say they are.

This isn't theory. Design should be data driven rather than ideologically driven.

> It is easier to hack or steal a phone than it is to read your mind.

Mind reading is observably not the only way to obtain somebody's password. As you say in your next paragraph, this is extremely important when considering passwords. Plenty of things work great if you simply exclude all the cases when they don't work great. Everybody sucks at detecting phishing, even security professionals. This is demonstrated through clear data. "Well, I had to do something to get owned" is not meaningful. We should not care about the ideological purity of practical systems. We should care about their practical outcomes.

> Those situations are exactly why password systems must be designed NOT to store the password on any devices, whether that's a file on a phone or laptop, or a cell in a database. Every time the password is written down, it is effectively already compromised as an authentication tool because it's no longer just something you know.

This is also largely wrong from a practical perspective. Chrome can happily store your saved passwords on disk if you don't want to sync with a backend service. This adds minimal risk, since a rouge program that can read all your files is very likely to be able to fuck you even if the passwords are only ever temporarily stored in memory.

Post reply on HN