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
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
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.
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
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.
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).
Steve put so much time into it too. SQRL really is the superior method of the two.
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.

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...
I literally just completed a Secure Code Warrior formation mandated by work, and one of the videos states "websites with expired certificates transit your information unencrypted, leaving you exposed to hackers" 🤦 like bruh you're supposed to know better, you teach cybersecurity for fuck's sake.
I've met two sorts of dedicated cybersecurity experts:
The sort that only understands how to click 'scan' in various tools and repeat output and browser error messages without understanding nuance. Had a fun incident where the nuance really mattered in interop with a popular product in my niche, company said we must not implement the interop because it was hopelessly insecure. When I pushed back on the nuance (folks behind the 'vulnerable' tech had way much more sway in the market than we did), got told I should really educate myself and read the paper on the vulnerability to understand that my proposol to workaround it was impossible. For one glorious moment in my career, I got to tell them to look at the paper again and specifically the author (I had written up the vulnerability in the first place). After a brief shock though, he still went back to even though I may have found it and explained in key detail, I still must not understand the implications...
Then there's those that understand and can engage in nuance, but will still say inaccurate stuff, because they've learned being accurate and precise with the lay person doesn't work too well, and easier to just say "big scary" instead of explaining precisely the threat model and rationale. I will confess on a number of threads I have seen this happen and let it go without correction because correcting wouldn't have changed the core of the material, but would make the discussion go on even longer and waste more time. I personally can't bring myself to outright say the wrong things, but I do understand why it's the more practical strategy sometimes.
I'm the kind of 'tism where I can't get myself to tell white lies and will argue up and down until the truth prevails... sometimes to my own detriment, but I really like to understand the underlying mechanisms and the nuance underneath things, otherwise I feel lied to, and I thusly can't get myself to feel like I am deceiving others.
Please share the paper, I'm curious!
I'm trying to stay too anonymous, the paper is of super niche interest and the vulnerability comes down to a popular configuration being vulnerable, but a hardened configuration is possible, but requires randomizing some data that folks tend to leave non-random because it's the lazier way to set that up and it wasn't formerly recognized that the randomness of the data had security implications.
Computing and by extension cybersecurity has a lot of mouth-breather idiots because it's so new.
It's not so new anymore, however, it is widely known as an "easy" way to a strong six-figure salary, so we have a lot of gold-rush mouth-breather idiots that never would have gotten into this in the first place if not for the dollar signs. Really started to turn south around the time dot-com inspired early career people to get in on the bubble.
I think you a word, "cybersecurity" perhaps?
Oops. Thanks.
🎶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.
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 is a most excellent place for technology news and articles.