A passkey is a resident webauthn credential.
3,177 karma · joined December 14, 2011
I'd guess that they most likely want multiple people to be able to access a single account. Passwords are forced to be shared because a password is typically implemented as a single credential - there's one valid password for that account.
This is .... not true for passkeys. If you want two people to access the same account, they both add passkeys to that account.
Sharing passwords happen because of a property of passwords. It's not some fundamental requirement that people have. What people want is shared access.
Oh, it's not their responsibility, sure. But moaning about the UX without considering the trade-offs and decisions that got us to this point isn't very useful. Passkeys are badly implemented on some sites. So let's fix that.
> This makes passkeys essentially the same as passwords.
Passkeys in a password manager are fundamentally different to passwords. Try copying the passkey private key into your clipboard from your password manager.
> Passkeys as encouraged by the big companies are all about vendor lock-in than security.
The fact they prevent phishing is just a useful side-effect? This is veering into conspiracy theory territory.
No matter how many UX barriers you put in place, an exportable credential will be handed over to an attacker by an unwitting user at some point.
The irony here is that many of the complaints in this thread seem to be complaining about how imperfect passkeys are. No-one disagrees that they're imperfect!
Mine too! We simply register multiple passkeys under the same "account" for a service and we can both log in as the same identity. Have I missed something? Why is this hard?
> Passwords, obviously.
Passkeys are trying to solve the phishing problem. I guess pretending that the problem doesn't exist is also some type of solution, but I don't think it's a very good one.
This isn't a controversial topic, the data is pretty unambiguous. If you give humans a secret they can put in their clipboard and train them to enter it into text boxes, some fraction of them will send their credentials to the wrong people.
> They want to share them across devices
I do this today on Bitwarden, Apple users do this today with Keychain. Who's the "they" here?
> sometimes even devices made by different vendors.
> they want to hand a passkey to a family member or friend
..... Why? What's the use case here?
Tying a credential to a single identity (and therefore, human) is another explicit design goal of webauthn. I seem to remember the original proposal was that locking a private key to a device in an unextractable, un-copyable way was an explicit benefit - if it can't be exported, then it can't be stolen/copied without the device also being stolen. This was softened with the purpose of allowing syncing amongst devices that already have a good story on sharing sensitive data, but this mechanism does not exist generically. There is no standard way, right now, that my iPad and Pixel device can share a private, sensitive piece of information without the help of a 3rd-party syncing provider. Without that, cross-platform credential sharing can't exist out of the box by default.
What are the other ways that people want passkeys to be better?
Sure, there's UX problems as we're still trying to figure out what good looks like here. But in the absence of specific, concrete suggestions about how we improve usability for unphishable credentials, it seems that passkeys are a pretty good go. Perfect? No. Better than passwords? Undoubtedly.
Does this mean that any HSM where inability to export the private key is a feature is also doing it for "vendor lockin" reasons?
Saying that "WebAuthn was much more public, but passkey was not." shows that you don't really have a clear and accurate mental model of what passkeys are. Maybe TFA might help?
Show me a widely available service that filters authenticators based on attestation attributes?
"2 days from now" could either mean "after 2*86400 seconds have ticked" or it could mean "when the wall clock looks like it does now, after 2 sunset events". These are not the same thing.
The intent of the thing demanding a future event matters. So you can have the right software abstractions all you like and people will still use the wrong thing.
The problem is that programmers are human, and humans don't reason in monotonic counters :)
The operational competence of the dba is the same in both cases.
Not all fluff is equal.
Sure you do. When your local tax office / hospital / large data holder of your personal data has an administrative interface that only uses passwords, then the administrator gets fished and your identity stolen, suddenly you care a great deal.
Generally, it's useful for midnight to be at night, and midday during the day. UT1 is not regular, so you need some form of correction. Then the debate is about how big and how often.
If, however, you think it's a float, then you can.
> If year < 1970 or the value is negative, the relationship is undefined.
Google explicitly built spanner (?) around the idea that you can get distributed consistency and availability iff you control All The Clocks.
Smearing is fine, as long as it's interaction with other systems is thought about (and tested!). Nobody wants a surprise (yet actually inevitable) outage at midnight on New year's day.
A delta between two monatomic values should always be non-negative. This is not true for Unix time.
There's very good reasons that are important behind why we try and keep UTC near UT1, so saying "it doesn't matter to anyone" without even entertaining that some people might care isn't very constructive.
It most certainly matters to a lot of people. It sounds like you've never met those people.
I guess they just didn't foresee the problem, or misjudged the impact. I can imagine it being very "let's kick that problem down the road and just do a simple thing for now" approach.