zlacker

[parent] [thread] 1 comments
1. lxgr+(OP)[view] [source] 2024-12-27 19:51:15
What specific gripes do you have with WebAuthN that makes you want to reimplement it?

All the problems I have with it as a user originate from either reyling parties doing dumb/user-hostile things (enforcing resident keys even though I'm perfectly capable of remembering my email address or my username, improperly layering WebAuthN with existing second factors etc).

These are possible because WebAuthN is trying to provide for many use cases at once, but I've never felt like it was missing something, and user-friendly behavior is definitely possible. I've seen many examples at this point.

replies(1): >>somat+UP
2. somat+UP[view] [source] 2024-12-28 04:45:02
>>lxgr+(OP)
No good way to manage(save/restore) the keys. but the real killer for me was that it requires a hardware token to work, while a hardware token is better, it sort of sucks as a hard requirement for all users.

Really, I don't want to reimplement webauthn, I will will probably be sticking with basic auth as it just works. However, I was hoping to finally get decent public key auth. and webauthn is close, really close, but it is like the designers gave up at the last second and said "no, we don't want this to work in the general case", all it would have took was to say software token are an ok fallback. I was so close that out of frustration I spent a weekend with an experiment to make public key auth work for everybody. It works, but is a bit pointless as then I, the service needing to authorize somebody, is the same person providing them their public key management system. I might as well cut out the all the ridiculous bit twiddling and just use cookies for all the security that grants the end user.

[go to top]