←back to thread

225 points Terretta | 3 comments | | HN request time: 0.015s | source
Show context
troupo ◴[] No.41856125[source]
I came across an opinion I largely agree with: https://mastodon.social/@lapcatsoftware/113308133338196824 and https://mastodon.social/@lapcatsoftware/113308273654667583

> These big tech companies will do anything possible to prevent users from ever actually being able to access their own passkeys.

> Export and import should have been extremely simple. Instead, they took years to come up with some convoluted system where the only possibility is to transfer from one vendor lock-in to another vendor lock-in.

> With passkeys, the big tech companies are executing a coup d'état of authentication, just like they did for HTML itself.

> In the end, they control every protocol, become the gatekeepers for the web.

replies(8): >>41856181 #>>41856189 #>>41856247 #>>41856254 #>>41856772 #>>41862312 #>>41862676 #>>41881156 #
NikolaNovak ◴[] No.41856181[source]
So it's not just me!

I feel like I either misunderstand pass keys or live in some twilight zone where they're ok even though I cannot wrote them down or memorize them, I can only have invisible magic stuck on my phone.

If I show up naked, I can login to the system via password but I am conpletely useless with a pass key. And for somebody like myself who uses multiple devices daily (two phones, two tablets, several laptops and desktops), it seems a nightmare to set them all up or maintain:-(

It feels a system designed for those who live by their phone and trust some specific service provider with their life. I'm not in either of those categories :-(. I still don't understand what the "Keepass, "little black notebook", and "good memory" equivalents are.

replies(3): >>41856209 #>>41856253 #>>41856425 #
izacus ◴[] No.41856425[source]
> I feel like I either misunderstand pass keys or live in some twilight zone where they're ok even though I cannot wrote them down or memorize them, I can only have invisible magic stuck on my phone.

There seems to be a lot of misunderstanding of passkeys indeed. They're in no way different than that random password stored in your password manager and can be (with this standard you're commenting on) moved around wherever you want them.

All passkey sites also support fallbacks to just password or other auth mode.

replies(4): >>41856498 #>>41857306 #>>41859826 #>>41867764 #
NikolaNovak ◴[] No.41859826[source]
>> All passkey sites also support fallbacks to just password or other auth mode.

Is this a guaranteed thing? Are we saying any account I create cannot be Created with just a pass key; and that no site or service is able to discontinue the password option?

replies(2): >>41862292 #>>41863202 #
9dev ◴[] No.41863202[source]
It is by necessity; at the very minimum, you’ll need an OTP via email, since you need an out-of-band method of identifying the user during the registration.

I actually built a small web application that’s entirely passwordless, and it works really smoothly. I don’t get the antipathy towards Passkeys.

replies(2): >>41864825 #>>41867776 #
lxgr ◴[] No.41867776[source]
Passkeys are like SSNs, drivers licenses, passports, local phone numbers etc.:

They work perfectly well for 95-99% of people, but oh boy are you screwed if you are in the remaining 1-5%…

Unlike for all these other “forms of identification”, there’s a chance passkeys will bridge the remaining gap, but we’re not there yet, hence many people are cautious.

replies(1): >>41867827 #
9dev ◴[] No.41867827[source]
A lot of people here seem to ramble about this, apparently without ever having actually used Passkeys themselves: They are nothing like SSNs, driver licenses or other static IDs. A Passkey is generated per device/site combination, where the client holds the private key, the site receives the public key, and the user can optionally share their private key among user devices depending on their client software. That's all it is. How are you "screwed", and what does it even mean "they don't work perfectly" for you?

What's more, passwords work well for a much smaller percentage that has learned to use password managers. Everyone else is subject to regular breaches, and suffering. This is a problem Passkeys get rid of entirely. There is no good argument against using Passkeys over passwords. Not one.

replies(2): >>41867854 #>>41868177 #
1. lxgr ◴[] No.41867854[source]
I know how they technically work.

I was referring to how 99% of people have (or can easily get) an SSN, license etc., but for 1% it’s absolutely impossible for various reasons, so any flow requiring one for non social security or tax declaration purposes is an unnecessary obstruction to them when other alternatives exist.

Don’t ever believe that passkeys will always stay strictly optional. As soon as something works for 99% of potential customers, the 1% can be deprecated for efficiency/security/… purposes.

And I’m even not anti-passkey or anything, I personally like them and will take them over SMS OTPs any day. But they’re just not done yet, and I really hope they get done in a way that works for everyone before they start becoming mandatory in some places.

replies(1): >>41868012 #
2. 9dev ◴[] No.41868012[source]
I dunno. Should we then proceed to keep up the awful situation we currently have for the 99%, just to avoid any inconvenience to the 1%? That's not how democratic societies usually work.

What reasons are there for not using Passkeys? So far, the only things in the threads here were vague fears of vendor lock-in by people who apparently overlooked the fact that Passkeys are supported by a lot of password managers other than just iCloud Keychain and Google, including open source software.

What is this 1% that we should sacrifice a clear solution to password breaches for?

replies(1): >>41868349 #
3. lxgr ◴[] No.41868349[source]
As I said: Most likely the ideal solution really is passkeys, just not in their current form.

I just wish their governance was a bit more aligned with users rather than just big tech. This would be something where Mozilla could really shine, for example, but I haven’t really seen them in the relevant forums, and they were quite late on WebAuthN as a whole.

Some focus on avoiding lock-in and (somewhat orthogonal to that) enabling non-cloud credential duplication would be great, to name a few remaining issues.