Why passkeys are a step back for personal security: examining account lockout risks, platform lock-in, hardware key limits, and fragile recovery flows.
One complaint I have is browser insistence that a site must have a proper certificate to work at all.
I provide self hosted software with passkey support and probably over 90 percent of my users never set up property certificates due their private networks. So the passkey function is impossible for them.
Which means they must use passwords. Which are far worse in this scenario. The practical risk either way is arguably low for them, but to take a more mitm/phishing resistant technique and then force it to not work because mitm or phishing might be in play…
That doesn’t make sense, you’re suggesting using security (passkeys) over an insecure channel (HTTP). Even internal websites should use TLS. Am I missing something?
In an ideal world, they would be using TLS with a properly set up CA even for internal.
In practice, I can’t get most of them to do that, and instead they just click through the certificate warning and use it over https, but without certificate assurance.
So it’s still over https, though a fair argument can be made that hardly matters if the certificates aren’t validated, and browser ecosystem doesn’t consider ‘TOFU’ a valid approach like it generally is for SSH.
Anyway, the point is that passkeys are ‘security’ by virtue of not ever divulging the secret on the line. They can’t be sniffed, they can’t be captured by phishing, they can’t be retained for later use after a MITM. So the refusal to operate even with informed user consent means the user just uses a password, which is weak to all those things. In a scenario where it could provide the most mitigation is a scenario where the browsers refuse to let it try. Even the built in password manager will still auto-fill without certificate validation, one of the most risky places to be ‘helpful’.
One complaint I have is browser insistence that a site must have a proper certificate to work at all.
I provide self hosted software with passkey support and probably over 90 percent of my users never set up property certificates due their private networks. So the passkey function is impossible for them.
Which means they must use passwords. Which are far worse in this scenario. The practical risk either way is arguably low for them, but to take a more mitm/phishing resistant technique and then force it to not work because mitm or phishing might be in play…
That doesn’t make sense, you’re suggesting using security (passkeys) over an insecure channel (HTTP). Even internal websites should use TLS. Am I missing something?
In an ideal world, they would be using TLS with a properly set up CA even for internal.
In practice, I can’t get most of them to do that, and instead they just click through the certificate warning and use it over https, but without certificate assurance.
So it’s still over https, though a fair argument can be made that hardly matters if the certificates aren’t validated, and browser ecosystem doesn’t consider ‘TOFU’ a valid approach like it generally is for SSH.
Anyway, the point is that passkeys are ‘security’ by virtue of not ever divulging the secret on the line. They can’t be sniffed, they can’t be captured by phishing, they can’t be retained for later use after a MITM. So the refusal to operate even with informed user consent means the user just uses a password, which is weak to all those things. In a scenario where it could provide the most mitigation is a scenario where the browsers refuse to let it try. Even the built in password manager will still auto-fill without certificate validation, one of the most risky places to be ‘helpful’.
Yeah, this is the key. Distributing your own cert catalogues on a system level negates this issue. But then also that needs to be managed.
But key signing is essential anyways and I’ve often thought the CA system could be used outside of the client to server signing process.