Top
Best
New

Posted by ashergill 2 days ago

Passkeys: They're not perfect but they're getting better(www.ncsc.gov.uk)
53 points | 134 commentspage 2
rstuart4133 1 day ago|
For me, passkey's have made it when I can pay several different, independent providers to store them for me, and authorise the devices I can put them on.

To expand on that a bit, I don't have a problem with banks or whoever insisting they be stored securely. That means I don't have a problem win the inference that they don't trust me to store or even see my own keys.

What I do have a problem with is not being able to back them up. Which means I have a problem with Apple, Google or even Bitwarden handing me out a free they can take away at any time.

Fix that, so I can have store my identity(ies) at multiple providers, and I happy.

noirscape 2 days ago||
At its core, the main drawbacks that need to be solved for them to be a viable option are imo:

* Improving OS flows. Every passkey implementer that's also an OS gets really excited about enrolling you into their proprietary clouds, and using alternate flows to respect the users wish to use their own manager is usually hidden in confusing UI forms that don't feel consistent if you don't already know what you're doing.

* Device loss scenario is already mentioned, although more broadly speaking a lot of the reasons people get leery is because all three major providers (Google, Microsoft, Apple) are notorious for their near black box technical support. Losing access to one of these providers on its own is already enough to heavily disrupt the average person's life. Having your login details stored with them makes this even worse.

* The FIDO Alliance Is Way Too Excited About Device Attestation And I Don't Like It. Basically the FIDO Alliance's behavior around passkeys reeks of security theater and them badgering an open source password manager for daring to let users export their passkeys in the format they preferred, rather than what the FIDO Alliance wanted (which is that passkeys must always be encrypted with a password) is telling. If they are as secure as promised, it's a bad look to start threatening device attestation as a means to get people to comply with your specific idea of security. The only real barrier right now to it outright being a thing is that Apple zeroes out the field and when Apple is the only meaningful halt to that kind of attestation, something has gone very wrong.

I think passkeys are interesting, but I just flat out don't trust the FIDO Alliance with the idea. They're way too invested in big tech being good stewards of the ecosystem, which is becoming increasingly unpalatable as more and more evidence piles up that they're really bad actors on everything else. (So why should we trust them with our credentials?) The idea genuinely has value (it's literally the same kind of mechanism as SSH keys), but the hostility towards user freedom is deeply concerning and a blocker to getting people to use it. Even non-technical people seem leery of them, just because of how aggressively big tech has been pushing it.

magackame 2 days ago||
God if it could just be a single key that you dump to paper or titanium plate and don't worry about backing up a zoo of keys/password with a cloud. Just take my one and only public key. If you care about per service privacy, you are welcome to use multiple. I don't think there is any compromise scenario where you would leak any single specific passkey and they are not bruteforcable. Why is it not as simple as that?
AlexandrB 2 days ago||
> * Improving OS flows. Every passkey implementer that's also an OS gets really excited about enrolling you into their proprietary clouds, and using alternate flows to respect the users wish to use their own manager is usually hidden in confusing UI forms that don't feel consistent if you don't already know what you're doing.

You're kidding yourself if you think that this is something Microsoft, Apple, or Google are incentivized to solve. Microsoft is especially bad here - pushing their crappy products in Windows every chance they get. Once some marketing director gets the idea that this can improve retention in Outlook or something the UI will get more confusing and the dark patterns will get darker.

noirscape 2 days ago||
I never said they had an incentive to solve it. I said that it's one of the big blockers to getting regular adoption. It ought to be obvious that all these issues aren't a problem if you look at it through the big tech lens: why is it a problem when we're providing the service. They're a problem when you're a normal person with a healthy distrust of big tech companies.

In practice, I expect someone to figure out a way to break into/bypass the OS flow entirely with a less "big tech wants your private details" solution and that's what winds up getting adoption.

physicsguy 1 day ago||
When they first came about it seemed like some websites didn’t work well with them and insisted on using the device password manager. I use BitWarden for everything so didn’t want to get into that - I want to be able to log into things on my personal and work Macs in Chrome, Safari on iOS, etc etc.

Since then though it’s rare I’ve run into issues like that, and the login flow is much better in sites that have adopted it. I did hit an issue in GitHub last week where after logging into things with passkey it then immediately wanted me to MFA which could use the same passkey. But these things are getting rarer.

sam_lowry_ 2 days ago||
How are passkeys different from API keys or just random chains of characters?

And why can't we have the use of such keys enforced by an EU legislation so that all businesses allow users to login using such strings of random characters?

The world would then be a better place.

MaxRegret 2 days ago||
Passkeys are a public/private keypair, where the service you're authenticating against has the public key and your browser has the private key. To authenticate, the browser demonstrates that it has the private key by signing and returning a challenge sent by the server.

So, unlike API keys, the actual passkey is never sent anywhere out of your device. Passkeys are more like SSH keys than API keys.

One difference between SSH and the WebAuthn protocol is that the challenge identifies which key it is expecting. So the user doesn't have to explicitly select which key to use.

dist-epoch 2 days ago|||
If you are not careful, you'll enter the random chains of characters into a phishing site.

But a phishing site can't steal your passkey and forward it to the real site, the passkey will just not work with the phishing site if you try using it there, it's locked to the authentic domain.

sam_lowry_ 2 days ago||
That's mumbo jumbo to me so far.

What's an authentic domain?

How is my passkey locked to it?

Scion9066 1 day ago||
The domain that the verifier (the site trying to authenticate you) is at is part of the cryptographic process. If the domain doesn't match (ie you're at a phishing site) then the results of the cryptography won't be valid for the actual correct site, only the phishing site (which gets the phishing site nothing it can use).
IcyWindows 2 days ago|||
Passkeys are a private key stored on your device with the public key registered with the server.

Servers should allow multiple passkeys per user (so you can register multiple devices), but many don't.

zzo38computer 2 days ago|||
X.509 already does that, and in a better way. It also makes it unnecessary to register multiple devices, if you allow certificate chains (the server would check the certificate chain; one of the was issued by the service and contains information about which account it is associated with; the other ones you can issue to yourself, optionally with more restricted permissions, and can be revoked or expire). That would also allow you to have passworded private keys, and/or to store one private key on a separate computer that is not connected to the internet to issue the other one to yourself in order to mitigate security issues (and you can revoke the certificate and make a new one if it is compromised or expires). X.509 also is not limited to only WWW, so it can be used with other protocols too.
sam_lowry_ 2 days ago|||
That's an implementation detail users should not care about.

The bigger question is... why don't we replace the login/password combination with just a string of randomly generated characters and call it a day?

Why protect these strings of random characters from users, call them passkeys and advertise them on all street corners?

Feels like a devil's plot to strip us from all the rights to our devices.

joshuamorton 1 day ago||
public/private keypairs (and therefore passkeys) provide cryptographically secure anti-phishing properties that passwords cannot.
WesolyKubeczek 2 days ago|||
> How are passkeys different from API keys or just random chains of characters?

As far as I understand it, in the same way that a public/private keypair differs from a random chain of characters you are used to shoving into the "Authorization: Bearer XXXXXXX" header.

gowld 2 days ago||
> How are passkeys different from API keys or just random chains of characters?

Passkeys are encrypyed so they can't be simply copied off your device.

angry_octet 1 day ago|||
They can most definitely be copied off the device, and the decryption key is in memory.
sam_lowry_ 2 days ago|||
So how are they better than API keys if I can not even backup them?
angry_octet 1 day ago||
I particularly dislike that Teams forces you to use Microsoft Authenticator for Passkeys, instead of a physical FIDO2 or Apple/Google Passkeys.
angry_octet 1 day ago||
I look forward to info stealers dumping Passkey apps and leakage via additional device enrollment, and not having clear mechanisms for rolling all your Passkeys.

Device attestation and signing transparency logs are quite necessary for users to have visibility of where/when Passkeys have logged in. Really they should also have key ratcheting so stolen keys become useless.

oldestofsports 2 days ago||
So then I should store all my passkeys in a vault that I protect with a single password, how are passkeys safer?
etskinner 2 days ago||
Let's assume your vault/login has these properties:

- You have a strong unlock password that you don't use anywhere else

- You have a second factor set up for unlocking the vault (TPM in the device you're using, Yubikey, TOTP, etc.)

- The service you're logging into has good account recovery hygeine

The benefit, assuming those things, is that the passkey is phishing-resistant and social-engineering-resistant. If a user gets an email saying "omg, someone tried to transfer your paypal, click this link to log in", then when they try to log in with the passkey, the site the attacker is using won't be able to use the passkey (because the passkey is associated with a particular domain). Even if the user wanted to bypass this, there's specifically no way for them to extract the contents of the passkey.

That is very different from a user having their password stored in their vault. They could easily forget to check the domain, or get tricked by a very similar looking one, and copy/paste their password into the attacker's form.

abdullahkhalids 2 days ago||
My password manager (keepassxc) has a browser extension that only lets you autocomplete the password on a page if the url matches the one stored in the database.

Sure I could manually copy the password from the database, but in practice, this is fairly good security. It also doesn't treat the user as an always-idiot, which is a good thing in my book.

ewoodrich 2 days ago|||
I'm struggling to think of a reason why being "treated as an always-idiot" is an actual negative in this specific example.

I use Bitwarden and when the password autofill doesn't work as expected my first assumption from many previous experiences is that it's because a website changed something slightly in their auth flow or a particular page has a weird redirect/embedded login scheme different than the primary login, or similar "modern" web weirdness.

So if I get phished and let my guard down just that one time due to panic, sleep deprivation, or whatever else I'm glad that it gives me a second layer of defense against me reflexively clicking a couple times to copy/paste the password manually. A passkey dropdown with "No passkeys saved for this site" would be a massive red flag and stop me in my tracks before trying to do something else stupid.

abdullahkhalids 2 days ago||
Passkeys do protect you from such mistakes in a way the current implementation of the browsers/password managers/web-specs don't.

But that is after 10s of millions of dollars or more have been poured into the development of passkeys, resulting in new standard specifications, diverse implementations of password managers, etc.

Now, imagine the counterfactual world where those same dollars were devoted to improving the password infrastructure. Could we have forced the average person to always password managers with long randomized passwords? Could we have build better webspecs around password entry workflows, and forced websites to fix the issues you face? I think the answer is yes.

Against this counterfactual world, passkeys are not in practice much better.

stavros 1 day ago||
Except we already are living in that counterfactual world. Companies haven't been sitting on their hands while lamenting how bad passwords are, we've spent many times more money trying to make passwords secure than we've spent on developing passkeys.
eviks 1 day ago||
If we're living in that world, which websites block logins without a password manager?
skybrian 2 days ago|||
That works for you, but the website doesn't know you use a password manager, so they'll often want you to use SMS as a second factor.

Passkeys require some kind of password manager. That's the main benefit. The adoption problems are because a lot of users don't really understand password managers.

abdullahkhalids 2 days ago||
I bet that Google+Apple+Microsoft could have gotten 95% of the world on password managers by building excellent password managers into the OS, and demanding that one can only login into their websites with passwords that have at least 100 bits of entropy.

And it could have been done 10 years ago.

skybrian 2 days ago||
I don't think a password manager would get much adoption if it refused to save the passwords you already have?

Google's password manager does nag you about bad passwords, but it's easy to ignore.

Looks like it's been around ten years since it was introduced. It doesn't seem like enough.

abdullahkhalids 2 days ago||
Microsoft and Google forced organizations that were using their services to upgrade to 2FA over a few years. For a short bit it was optional, after that it's basically not possible to use these services without 2FA. Now even many grandmas are familiar with the idea that sometimes you have to copy a code from your sms to a website when logging into your bank account.

They could have done the same thing with passwords. They have 100s of millions of organizational users, who will do whatever corporate IT tells them to do. Microsoft can say, there is a password manager available on Windows. From now on, organizational users must use 100 entropy bit passwords. IT tells users - users must store passwords in the password manager and use the browser extension.

After three years of users resisting, everyone will give in. Same for university students, who will need it. After that the rest will adopt easily because it is the default thing to do.

scratcheee 2 days ago|||
The article explains the weaknesses of the password-centric approach:

> whether by phishing or exploiting the fact the passwords are weak or have been reused

1. Phishing is harder when you only ever enter your password into 1 place, and that one place is designed to be secure and consistent.

2. Much easier to have exactly 1 strong password than unique strong passwords for every website.

Is it better than a vault full of random passwords? Probably not, beyond pressuring the user into using the more secure method

velcrovan 2 days ago|||
So your real issue here is with credential managers, but I'll bite. In most cases the vault is not protected only with your master password, but with other cryptographic info that prevents the vault from being opened on untrusted devices. If one of your trusted devices is compromised, I guess you have other issues.
AlexandrB 2 days ago||
Uhhh, how does that interact with:

> Users are largely unsure about the implications for their passkeys if they lose or break their device, as it seems their device holds the entire capability to authenticate. To trust passkeys as a replacement for the password, users need to be prepared and know what to do in the event of losing one – or all – of their devices.

AlexandrB 2 days ago|||
The better question is: how are passkeys safer given that the recovery flow will be the same SMS or email based approach everyone uses today?
alexjm 2 days ago||
From the article... Passkeys:

- are generated securely and so can’t be guessed - can’t be phished - are unique for each website you use, so if one website is compromised it doesn’t put your other logins at risk

jauntywundrkind 2 days ago||
Nicely timed on the one year anniversary of FIDI Alliance's Credential Exchange Protocol and Credential Exchange Format. https://fidoalliance.org/fido-alliance-publishes-new-specifi... https://news.ycombinator.com/item?id=41847787

But afaik you still can't move Passkeys from Chrome or Safari to any other credential manager.

I was vaguely under the impression that there was a ton of push-back again import/export flows in general, that the CEP was going to be the only supported path. And it requires that your Credentials Manager have a public endpoint to send your credentials to. Which doesn't force but radically ups the challenge for individuals to self host or manage things themselves, will drive Passkeys to remain service provided only.

With governments upping their right to snoop, immoral intercept, it's hard to have too much hope that Passkeys can remain trustable & respectable. If the UK passes a law saying they can access all your keys, the odds are not in your favor that Google is going to make a Signal like stand & tell the UK to buzz off. It's unfortunate that these giant massive enterprises are so big are so many products all in one, because if there was a healthy Chrome business not tied to thousands of other profit lines, maybe Chrome would dare have some backbone & tell their majesty to go stick it where the sun don't shine. But these companies are so big that even the most immoral outrageous ridiculous laws end up being accepted. Passkeys seems like a huge painted target; maybe the next 15-20 years go by with no one trying to get in the cookie jar, but it seems inevitable that the moral rot and illegitimacy of governments will stoop down to making this good idea untenable & a joke, in a long enough time scale. Especially with the service-provider-only ecosystem that's being engineered and imposed here.

supportengineer 2 days ago||
Passkeys are great because they get sync'ed to all your devices, which makes it really easy to share access to those websites with other people ( who have access to devices on your account ). Like a spouse.
angry_octet 1 day ago||
This is also a problem because the security boundary of passkey security is now the entire cloud of that provider... And every app on every device you're logged in to.
marssaxman 2 days ago|||
What mechanism makes that happen?
Bolwin 1 day ago|||
Uh huh. And what if they don't? Or what if they do but would rather user their own device. Or what if they don't right now?

You know what's even easier? Sending them the password.

Mindwipe 1 day ago||
> Passkeys are great because they get sync'ed to all your devices, which makes it really easy to share access to those websites with other people ( who have access to devices on your account ). Like a spouse.

They certainly fucking don't.

I also have no interest in my credentials touching any cloud whatsoever.

More comments...