The passkey is worse
4 points by zk
4 points by zk
Why is kcoleman plugging "Saigon Safe"? A bitwarden fork with 5 users. It is incredibly difficult to make a secure password manager extension, and recommending one is rash. I wonder if this article exists mostly to promote it. It is, of course, their AI assisted fork. https://www.kcoleman.me/2026/06/14/saigon-safe.html
Edit: And how do they propose this even happened? There's a bunch of non sequiturs. They willingly entered their password and OTP into this phishing site? That is the same attack passkeys are designed to prevent. And then how is the fake? bitwarden passkey popup relevant at all? if the attackers have already captured the credentials (which, again, passkeys would've prevented), then the attackers can register their own passkey and showing a fake apple password or bitwarden popup is not relevant.
but through the browser extension detection API, attackers new exactly which password managers they should fake. How kind of web browsers to give phishers exactly the right tools to use.
What? There's no such API to my knowledge. Also, while I dislike passkeys, this sounds exactly like the kind of attack that would have been prevented by using passkeys. Finally, the issue of allowing passkeys as a single factor auth method sounds like a Google problem, not a passkey problem.
If I had to guess (not going to install bitwarden to check), a lot of password managers inject their icons into the DOM (eg Lastpass used to do this). A page that is looking for password managers can look and see if there’s (un)expected changes to the username/password form elements.
So their complaint is that someone used a fake login screen to phish credentials, then try to add a passkey to the real account, and the "problem" here is passkeys?
What in the actual fuck. The entire first part of this is the poster child for "passkeys would have prevented this".
Next they'll be complaining that security bolts on doors are a risk because if you leave the house unlocked a bad guy could go in, lock the door and prevent you from getting in.
i see two prongs to this argument:
I can see how they author came to their conclusions, but my faith in passkeys as a way to prevent this phish from being possible in the first place (only entering password when prompted above the line of death, needing to match host exactly) is unshaken
I'm not someone who is opposed to passkeys, even with the recent articles going around... But I have never understood why Passkeys are so often used as a single factor. It makes sense to use passkeys in combination with another factor.
The incident/attack/phish in the beginning here really is quite scary and something I haven't heard discussed; an attacker adding their passkey to your account, giving them basically full control, since there's no second factor required (in Google's case here)
A user that already uses password+Fido2 quite rightly sees Passkeys as a drop in security for themselves.
But bare in mind that these users are a vast minority for most sites.
Most phishing victims don't have FIDO2 or even TOTP enabled, because it's a faff.
Sites that adopt Passkeys-as-single-factor have likely judged that it's better to protect more users against the sorts of attacks that OP experienced, than to hold out for them to suddenly be okay with password+2nd factor.
Sites could allow users to optionally do passkeys+pw. I'm not sure why more don't, since it has benefits, but it has costs too: every login flow is yet more testing/UI/risk/support.
The original phishing attempt, that you fell victim to, is essentially impossible with passkeys. The relying party for Google passkeys does not match sites.google.com, so your password manager would have simply refused to send the credential.
That said, you should know that given you are the author of the Bitwarden plugged in the article. One would hope, anyway.
The original phishing attempt, that you fell victim to, is essentially impossible with passkeys. The relying party for Google passkeys does not match sites.google.com, so your password manager would have simply refused to send the credential.
They vibe coded it. And didn't publish the changes they purport to have made to the github they linked. And why did zk remove a (presumably critical) comment by tuxes. Incredibly sketchy.
Excuse me? Why the baseless accusations? Where is this coming from?
I can't remove comments, I am not a mod.
Tuxes comment is still there, it's a reply to mine.
"[removed my author]" means author of the comment. I assume they replied to the post instead of my comment by mistake so then deleted it.
Only thing sketchy is you accusing me of stuff here... Shrug
Sorry I misunderstood that, that makes sense and I retract that portion of the accusation. I am still incredibly suspicious of kevin's extension.
All good. You mean the browser extension they plug in the article? Honestly I'm suspicious of it as well. I noticed the publisher info on chrome store is some weird dating app company.
Yes! That one, and the source kevin publishes does not match with the source code of the extension, although I have not done more than counting the files with differences (of which there are hundreds). I was on really high alert after that realization and I jumped to conclusions way too fast.
Hey, no worries. That's understandable. I should mention for context I found this article on Kagi Smallweb, and have never heard of this guy or the extension before.
And why did zk remove a (presumably critical) comment by tuxes.
Sorry, I removed my comment. It was roughly "passkeys prevent the issue OP experienced" but on reflection my comment didn't meet my bar for threads I want to be involved with, so I deleted it.
You're pretty spot on here actually.
(I'm NOT the author of this article, nor the extension mentioned in the article, not sure why a couple people have assumed that?)
I think why I made that incorrect jump is your comment reads a bit like a synopsis / motivating reason to make the article (while it is, instead, a motivating reason to post this article), and then I read tad's comment which also makes that conclusion which conditioned me to that leap.
But I have never understood why Passkeys are so often used as a single factor. It makes sense to use passkeys in combination with another factor.
I think its because Passkeys count as both a first factor (they are stored securely in something you have - a yubikey, your PC secured via the TPM chip, etc) and a second factor - something you know (a PIN) or are (a biometric) should be required to use the passkey.
I think it's that the model of "something you have; something you know" is not as relevant as it once was.
"Something you have; something you know" was driven by passwords not being effective against remote attackers, and so a second factor was useful to mitigate against that.
FIDO2 came around, and passwords don't add much on top: the biggest risk of remote attackers (phishing; password dumps) are thwarted, and the risk from local attackers isn't meaningfully reduced with passwords-as-a-factor anyway (compared to platform auth, or token pins).
So now we're in some sort of transition where many are looking for clear "something you have; something you know" but it's not the model that sites are using.
Passkeys are MFA just as SSH keypairs are MFA. They require possession of the private key and pin/biometrics/passphrase. It's possible to leave out the passphrase in SSH keypairs and it's possible to write a passkey implementation that doesn't ask for a second factor (e.g. the debug authenticator in chrome/firefox)