I appreciate this article. Passkeys kinda came out of nowhere to me and I haven’t liked them since day one. So it’s nice to have my gut feeling vindicated with some actual info.
You know what u don’t like. Fucking xøcode sent to my email or a «magic link».
Srsly fuck off. Let me type my password
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…
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’.
This isn’t a good article @ouch. It’s dull, meandering and conflates issues.
Both Apple and Google want your identity anchored to their operating systems.
That’s true regardless of passkeys and why is Microsoft excluded here?
Logging into accounts on devices you own is the ideal scenario for passkeys. When you have to handle a colleague’s computer, it gets much more inconvenient. You could plug in a hardware key, but you don’t always have access to the ports.
What sort of drivel is this? Is anyone reading the article? I doubt it. Sorry, I’m not logging into important accounts on a colleague’s computer, regardless of being unable to squat and plug in a usb-dongle. The last statement even concedes that passkeys are an improvement for 99% of the user-population. It’s an improvement for 100% of the user-population. Like usual this is just drivel generated from friction around ‘newness’. It’s different–which automatically becomes scary for some users. The writing is just not coherent and there’s zero critique on passkey’s design and technicalities, of which there are things to criticize.
Get a physical passkey and if you have more than 100 accounts you have a problem. Buy two and use one as a backup in case you lose your first. Keep it in a safe and if you forget your safe’s combination… well, I guess we should abolish safes too: terrible account recovery support there. Yikes!
Passkey’s themselves can be protected with a PIN–the software I’ve used does not limit it to numbers. It can be your ‘master password’ if you want. This is a technical complaint of mine as all software I’ve used reference it as a PIN (personal identification number), which means numbers only. Except other characters are allowed. I’m not sure what the official spec. states.
🎶Security is Theatre🎶
Passkeys and 1FA were always just a duct tape solution for users resuing basic passwords without having to set a stronger password requirement or relying on users to use a strong password.
I think Chrome and Firefox should have decided on making an API for their builtin password generation and filling functions, that way any password manager would be able to integrate with foolproof functionality out of box.
People already use browser auto gen passwords for the reason that its faster and usually has an account sync built in. Now it would work with any 3rd party solution as well which covers enterprise and security minded users as well.
Users won’t use a password manager if it means you have to manually make an entry everytime you make an account.
Good article.
Currently passkeys are too much of a vendor lock-in to big tech.
Bitwarden support alone does not change that.
Microsoft 365 implementation of passkeys is sacrilegious somehow.
It requires only the Authenticator app from Microsoft and can use nothing else to create the passkey. The way this is implemented on iOS means that Authenticator comes up as an autofill option BUT IT ONLY SUPPORTS M365 and is useless for anything else. Leave it to Microsoft to take an open standard and bastardize it to the point of it being MORE CONVENIENT to just type a damn password.
The authenticator requirement was for regular MFA, with passkey you can use others like yubikey. BUT your admin can lock it to certain vendors so they could have selected Microsoft only.
Wait, you type passwords? KeePassXC’s auto-type awaits!
You realize password managers just open up another attack vector right?
bitwarden went from working great to buggy on browsers. sometimes the browser passes the request to the extension but most times goes to the os
What browser
i have had issues on Firefox, Chrome and Safari between Windows, Linux, and macOS
I agree the passkey user experience needs work, but man do I enjoy it over the haphazard ‘passwordless’ website login that just sends you an email.
I get it, they’re just skipping an attack vector and basically relying only on ‘2FA’. But now I have to go to a different app/tab, copy a code, and return to the site instead of letting the password manager fill stuff in for me. Some, like kickstarter, let you still have a 2FA code enabled so you have to grab your code from whichever authenticator and go to your email. Really nice login experience out of nowhere one day. \s
The best implementation of this I’ve seen has to be Ghost, an open source self-hostable newsletter/patreon thing. They detect what email provider you have and when you enter your email, will display a link to open your inbox. It’s super neat, and I haven’t seen it anywhere else, and I’m also not sure how they do it. For something self-hostable, I’ll definitely take one less attack vector.
Doesn’t help if you’re not using a huge provider such as Gmail or Hotmail
A DNS lookup on a domain says who runs the email server for email users on that domain (that’s how email senders figures out how to send you messages), and if that host is a known one then you can just pull the link to show. If you’re self hosting email then a few solutions can be recognized and login shown by guessing that the email software’s default URL pattern is used.
I still feel like phishing prevention alone justifies passkeys enough
I really wish that SQRL had taken off, as it solved most of the problems noted. It was effectively passkeys that you generated on the fly based on your private key (which you can back up and restore to other platforms if necessary) and the website domain by scanning a QR code (or clicking rh QR code if your on the same device) and sends the signed challenge to the website to auth you.
No need to login to your manager on random systems, no issues with platform lock-in, no worries about dedicated hardware, no worry about losing your access if your device dies (assuming you backup your shit).
Because the security is not better. I looked into it back then and it simply didn’t have a chance.
FYI, passkeys can also do the Qr thing.
Steve put so much time into it too. SQRL really is the superior method of the two.
SQuiRreL!
Yeah, no idea why not popular.
it does not depend on the name. like, we all use Transmission Control Protocol and HyperText Transport Protocol, and nobody cares because they don’t need to know. things can also be renamed before starting use in production, like we aren’t normally calling tech by their RFC numbers
Because it doesn’t encourage vendor lock in to big tech.
If SQRL was adopted, then the popular manifestations would have just as much vendor lockin, with built in password managers hosting the master private key without export option.
Passkey is not inherently vendor lock in. It’s mostly a consequence of password managers doing software passkeys and not making it reasonable to export private keys. It does have a mechanism a site can use to lock to “trusted vendors”, but if a site does that, that is on them for being dickish.
I dont understand the issue. Arent passkeys and password in any case just stored in a pw manager nowadays?
He talks about that if you read the article
Maybe im just lucky but proton pass and bitwarden (vaultwarden) both work fine for me. None of my accounts are linked to google or microsoft.
There is still nothing better than passwords.
I don’t want my access to be tied to a specific device. Devices get lost, or break.
I don’t want someone to be able to use my face or finger or eyeball to access my data. You can legally be compelled to unlock a device with your biometric security.
So current biometric security sucks. And passkeys suck.
Also, though…passwords suck for all the reasons that we all already know.
There has to be some better method that the owner can have full agency over, I just don’t know what. I don’t have the answers.
Hardware security keys is the other option. The FIDO2 ones are compatible with most sites using passkeys.
This pretty much matches my feeling for the last 20 years or so. Passwords suck and are outdated technology. But every single alternative that has been developed over the years has sucked more, not less. They all have single-point-of-failure, vendor lock-in, assumptions about your “device”, etc.
There’s a fantastic paper from a while ago that did a great job of covering what you’re getting at. It’s one of the most cited papers in password security research. Basically, everything we’ve ever found sucks but passwords seem to suck the least. Great read if you have the time - https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-817.pdf
That is a damn nice paper, thanks for sharing that! The comparison table is, if a little wacky-looking at first glance, a pretty great overview. I skimmed it for the abstract and conclusion but now I think it’s worth reading it in full.
Every attempt at using passkeys has been a step into murkier, less easily understood, less convenient security.
Passkeys may be a “step up” from password + TFA in terms of usability, but there’s such a variety of implementations and explanations of how those implementations “keep me secure” - I feel like any idiot who grabs my phone when I’m not looking and can follow my unlock finger smudges on the screen can use my pass keys… No thanks.
I’m not the biggest fan of passkeys, either.
The problem he is describing here is mostly with enrollment and account recovery and not so much passkeys. The risk of getting locked out of accounts exists whether or not you use passkeys. Code based authenticators are not any better in this regard. Enrollment and recovery are the hardest part of identity. Passkeys are meant to address phishing risks specifically. I would love to see us do better on account recovery whether or not passkeys get adopted. The thing is, passkeys adoption is pretty slow and it has little to do with the issues described in this article. People just find it complicated and confusing. Until it is dead simple and the default, it will not find broad adoption.
The core issue is identity. If people would protect a digital identity a little better than they protect a credit card, that could/should be the basis of everything. Any account “worth more” than the CC $50 liability limit should have additional layers ON TOP OF the secure identity, including front line security that must be passed before the secure identity comes into play, but that single identity could/should be an element of access control to all non-anonymous accounts.
Anonymous accounts should stick with passwords, and online material should be clearly attributed as anonymous, or sourced from a secure identity (signed by said identity and blockchained to provide provenance).
