←back to thread

225 points Terretta | 1 comments | | HN request time: 0s | source
Show context
MarkMarine ◴[] No.41863214[source]
In one of the things that I do in my job, I run the auth system for a fintech, and passkeys are an incredible step forward for the typical user. Being able to migrate your passkeys between providers is a great step forward, I'm glad this is being implemented.

Lots of complaints about passkeys and "big tech paternalism" in the comments here, and frankly I don't think ya'll deal with the middle of the bell curve user base that much.

I've got users who, by literally no fault of their own, are being social engineered into reading back their SMS OTP codes to fake tech support. State of the art in industry is basically trying to understand every action that is happening on a device (via mobile phone network providers, location, their actions across multiple other sites, etc. etc. through vendors providing this type of intelligence... by vacuuming up all your data) to understand if fraud is happening by seeing if you can even trust the device that is getting the SMS. Every time we make a step forward in privacy, this gets harder and harder (fingerprinting devices is basically pointless now, so how do I tell if this should be a trusted device or not) so there is a driving force against improving user privacy coming from these vendors.

Passkeys are the first positive step in auth I've seen in a decade that the average user will pickup and use, it helps them login and helps them not try to set a weak password they shared with multiple sites, and they can't read it back to a scammer who is fake tech support.

Would I like passkeys to be more like ssh keys? um, maybe but I don't care about it one bit in practice. I use passkeys for everything I can and I've never once seen friction. The average user does not want to deal with backing up their passkeys or even thinking about them, heck most of them don't. If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec and do the work to get it implemented instead of complaining about it in the comments.

replies(4): >>41863610 #>>41863658 #>>41864267 #>>41867534 #
ndriscoll ◴[] No.41863610[source]
> If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec

Simple: clients meant for consumers SHALL NOT provide any attestation information. Those fields are intended to be used only by managed devices.

People can be free to use a device that has guard rails for them. The issue is when e.g. my bank forces me to prove I am using a malware device, which is pretty much everything from "big tech". Normies will stay on the normal path anyway and will be using one of those devices, so there shouldn't be a need to block the people who are using something weird, because by definition they are not the average user.

replies(3): >>41864753 #>>41866118 #>>41867552 #
lxgr ◴[] No.41867552[source]
Where are you still seeing attestation?

Both Apple and (I believe) Google threw theirs out when they moved to synchronizing passkeys, and they’re both widely supported by relying parties.

Other than that, I think it’s fair for e-signature etc. services to be able to require a physical, non-synchronizing credential like a Yubikey. With such a service, it’s not just your (as the key owner), but also others’ security on the line when breaches happen.

replies(1): >>41880222 #
ndriscoll ◴[] No.41880222[source]
That's good to hear. I don't see passkeys anywhere right now because browsers don't have software implementations and my computer isn't capable of a hardware one, which incidentally is part of why I'm not a fan of forcing it on people.
replies(1): >>41886264 #
1. lxgr ◴[] No.41886264[source]
Bitwarden has a software implementation that’s been working well for me at least in Firefox. I believe it should work in Chrome as well.