Hacker News new | ask | show | jobs
by alpos 1137 days ago
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, and they know that. It's important that you know the difference too if you want any kind of real security. If you use passkeys plus an authentication code app, then you have 2-steps (for whatever that's worth) but not 2-factors since they are both just a piece of code on your device, if they are both on the same device, that's even less secure since they can both be compromised at the same time, and in practice they will be.

Second is that the now single factor authenticator is strictly worse than a password because it is something that can be taken away from you and manipulated without your permission.

Third is that the keys are not private since the passkey provider is storing them for you and/or copying them around. This means they can be spied on, stolen, or demanded by the government, all without you even knowing someone else got access to your stuff.

The last glaring issue I can see for the time being is that it relies on a simple, easily cracked unlock pin, or worse still fingerprint/facial recognition bio-metrics as the only way to keep someone, other than Google, out.

One might be tempted to think facial recognition or fingerprints are pretty good security but it's already been demonstrated that people can break those mechanisms quickly and the cops can and will use your fingerprint and/or mug shot to unlock your phone if it's locked by biometrics only. They are not allowed to force you to give your real password, but the courts do allow them to use any means they like to break into your phone. Even if they damage it in the process, they just have to pay you back for it, they still get to take your data and use it against you.

Just some things to keep in mind before anyone gets too excited about this "new" invention. There's a reason we still have passwords even though we've had Smart ID Cards (such as DoD's CAC system https://www.cac.mil/) and other device driven access controls for decades now.

2 comments

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.

> 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.

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).