Sadly did not dig into the whole “the other side decides which device you are allowed to use” topic, a feature inherently build into passkeys.

I think that is only an issue based on what Passkey attestation is configured by the relying party? From what I have read a lot of public facing companies implementing it will have passkey attestation statements configured as None, which typically means there isn’t an authenticator certificate verification.

Only companies issuing their own passkeys on company hardware has a reason to enable attestation (forcing use of company approved devices throughout). Any public facing service has no reason to use attestation.

I feel like there’s some potential in password-derived passkeys, which would get around the storage and hardware lock-in issues. It’d essentially be a master password like for BitWarden, but instead of needing an app to store a bunch of generated passwords, the master password could be all you need to authenticate.

Most of the sources of compromise for regular users would be eliminated because the password never leaves the client.

So…re-using the same password for every service and site?

Grandma, that’s enough internet for today, OK?

how old is your grandma?

Would be 100 right now if she had led out for a few more months.

Would be 100 right now if she had led out for a few more months.

at that age just knowing what a password is already a triumph

Well, she also had terrible dementia for years, so the only passwords she was going to remember was the Little Orphan Annie secret code of “Drink More Ovaltine.”

My MIL is a grandma, and I would give her a 75% chance of reading her passwords to “someone from the bank” if they caught her at the right time. Maybe she’s already done that, I’m not sure if she did that or almost did that once.

In the scheme I’m proposing, the password never gets sent to the server.

The issue of password reuse is the password getting sent to the site, because the prevailing approach is to hash the password server-side. Passwords leak because they get stored in plaintext, or hashed using outdated algorithms, or get logged with request metadata–bottom line, they end up stored somewhere that an attacker can get their grubby little paws on them, or in a way they can reasonably recover them.

Using a master password to derive a passkey client-side isn’t any different than using a master password to unlock a password manager. It just cuts out the middle step.

It’s not a bad idea but that idea breaks as soon as you have to change the master password. You would have to change every one of those passkeys. Which could be annoying, if you have a lot of them.

You might like the current implementation of bitwarden passkeys. You have the master password to unlock your vault of passwords and passkeys as per usual, but then the webpages connect with the extension to authenticate via passkey, so there’s no weak link where the password is sent, but changing the master password doesn’t affect all your other passkeys afaik.

Ah, gotcha.

So, basically a biometic key, but with a password? Isn’t that basically just a self-signed certificate, then?

Bitwarden lets you store passkeys in its vault, which I think is what you’re asking for? It’s mentioned in the post too.

I have some passkeys in my Bitwarden, and my Bitwarden account is protected with a USB + NFC Yubikey.

The experience is inconsistent across phone platforms at the moment, but it works great on computers. On Android, it currently only lets you use a password manager if the passkey is your primary credential for logging into the site. Android doesn’t support passkeys from password managers for 2FA yet.

Bitwarden lets you store passkeys in its vault, which I think is what you’re asking for? It’s mentioned in the post too.

No. I’m talking about using the password to directly derive the passkey. This would eliminate the need to store them in something like BitWarden.

What you are proposing is no different from using a password and wrapping it in custom transport security to send it to the server. This would result in everyone simply using the same password for all sites.

This just sounds like using the same password on every site. Am I missing something?

Passkeys have to be unique per site so that you can revoke one without having to change something on every other site.

The return of SASL DIGEST! (Or these days probably CRAM or SCRAM)

But yeah, the “hard” part would be that you don’t want the user to type in a password to the website because it could get snatched, so you’d want the User Agent to pop up a password prompt, you type it, and then it does the hashing etc internally and only dumps the hash into the request. So you’d still need some kind of standard for that.

Which is basically just HTTP auth from the 90s. So the good news is that’s always been possible, and already has broad support and works with all browsers! 😛

I do not like the idea of password-derived Passkeys, because then acquiring the password is once again all an attacker needs.

Passkeys work now because the device itself is the second factor, the “something you have”.

It’d essentially be a master password like for BitWarden, but instead of needing an app to store a bunch of generated passwords, the master password could be all you need to authenticate.

This exactly how the flow works with Bitwarden now; I’m not understanding how your system makes any changes other than how the passkey is derived.

In fact, that makes things less secure for two reasons: if attackers learn a master password, they can derive other passkeys from it for other sites even if they cannot access the vault (not possible with current passkeys) and if you want to change your master password, all your derived passkeys become invalid and need to be regenerated.

Passkeys are worthless trash, invented explicitly to save Microsoft and Google money on password reset server time.

They do not solve session hijacking. Any attacker that has your granny on the phone to read them her password can also tell granny to go to a link and give them her session cookies.

Grannies love to hand out cookies.

That’s what CSRF mitigations are for.

Do you actually understand how any of the modern web works or does your knowledge stop at W3Schools tutorials from the mid-2000s?

No, sorry, I’m a network vegan. I only eat things that are grown at Layer 1. My packets are whole-grain and processed by hand. carried by pigeons. IP by Bird is how I surf the web, dude!

You think big tech did this to save… on … CPU costs of password resets?

This is actually really what you think?

Not the commenter, but they’re not taking about CPU costs.

Fair, but costs of resets overall. This is not a factor in tech giant costs.

You world be very surprised. It’s not what I directly work on, but there are entire programs dedicated to tracking and lowering the cost of password and account resets (and doing it securely). That last part is the hard thing. Large organizations can save millions of dollars if they can get people to not lose/forget their credentials -or- self service those resets (but even then, having that person do it is now losing their time and energy).

It’s not just indirect opportunity costs either, it’s direct costs to the IT organization. Smaller teams can absorb this stuff as a rounding error on their time, but the second you’re counting in the thousands, you need to deal with this type of thing. (And I’ll repeat: securely)

Now imagine doing it as a B2C+B2B organization like Google or Microsoft. The costs are staggering.

Not CPU costs, processing costs. Password resets are actually quite expensive. Microsoft and Google pushed the FIDO Alliance toward widespread use of a passwordless login credential because it benefited them. Google and MS get tens of millions of password resets a year. So if each one of those cost them $2 (some companies spend as much as $70 on each one if a human is involved), that’s literally tens of millions of dollars saved. Then you say “oh, for security” as the tie-in to not make it about your bottom line.

authx.com/…/how-much-does-a-password-reset-cost/ …jadaptive.com/the-true-cost-of-password-resets/ m365.fm/passwords-are-broken-passkeys-fix-everyth…

They solve the problem of people using the same password everywhere. That’s significant.

This article does a great job of articulating a lot of the uncomfortableness I have around passkeys. I’ve always said they make a lot more sense in an corporate environment but the level of control you lose in a personal setting is not commensurate with the protections and possible lock-in they offer.

I just don’t like passkeys. They are an overly technical solution to what is mostly a human problem.

Idk, when I want to log into my personal GitHub a bitwarden window opens from the extension, I click the GitHub profile I wanna sign in, and I do.

It’s a great implementation since it’s not linked to a physical device and it lets me authenticate in place. It’s still MFA, it’s just more comfy.

It’s not MFA if all you need is your bitwarden password.

Unless your bitwarden has MFA and locks after an amount of time commensurate with your security needs

True, but how does GitHub know your bitwarden has MFA? It only knows something has a valid credential.

Github doesn’t need to know how you implement it, just that your browser is handling it (and in this case the browser lets Bitwarden handle it lol)

I don’t think that github has to know that. You could be using a password manager and choose to make it a minimum character boring password or meet minimum complexity requirements or use the same password on a million sites. You have to secure your credentials; complying with the minimums of a service isn’t security.

GitHub doesn’t need to know that - I think that’s why it’s a bit of a cop out for MFA. Sure, your bitwarden may implement MFA, but just a chrome browser isn’t MFA.

Passkeys enable sites to offload the responsibility of securing accounts to the user, and if the user chooses a weaker way to implement them, GitHub doesn’t give a fuck.

It technically is, it’s not about the amount of actions you need to do, it’s about the amount of actions the platform you are logging in needs to do with you. That both interactions interface with a bitwarden local device makes the weak link your local device, which already was anyway.

Github only asks me for (bitwarden’s) passkey. That’s just a single factor.

If you’re using software that properly uses your device’s SE / TPM chip then it’s much more secure against malware, etc. And the main selling point is the much stronger phishing resistance (can’t trick you into logging in via a fake site, etc)

A securely stored modern certificate is going to be magnitudes more secure than password plus MFA.

The certificate path uses cryptography to prevent disclosure of your secret, and can’t be compromised when the site inevitably gets hacked.

I wouldn’t classify passkeys as MFA tho, they are a passwordless method that’s more secure than most MFA methods. Afaik it’s based on signed certificates or something like that and that’s virtually unhackable unless someone gets physical access to your device (and that’s game over anyway).

But bitwarden uploads it to the cloud to be used on any computer, AFAIK.

Bitwarden uploads the whole vault (the whole json of passwords, passkey codes, MFA identifiers, credit card info…) encrypted with your master password. Meaning that whatever is on the cloud should be virtually unbreakable. That’s why every time you write the password in the extension or Android app or whatever it takes a second or two to open, because it’s downloading and decrypting everything locally.

When you update a password they need to reencrypt the whole vault and re-upload it again even though it’s wasteful since that’s their whole security plan.

This would be great if it worked consistently.

In reality, extensions work in some browsers but not others, on some websites but not others, and with passwords at least you can fall back to copying and pasting, or even typing, if auto-fill isn’t working in the context for whatever reason. With a passkey not only are you SOL, but it will delay your ability to move onto the password option if there is one.

The devils in the (implementation) details.

Agreed in general, but that’s how improvements roll out for anything basically.

You enable it where it works, and you keep using the nonce based MFA whose name I can’t recall right now for where it doesn’t work well.

It might sound annoying but that’s society, it takes a long time to adopt new tools and build a standard.

Passkeys are a good idea with an insufficient compatibility issue.

In self host vaultwarden and it’s great with my passkeys and very convenient.

Hosting? Passkeys is the thing with the Aegis app, no?

No, that’s MFA, the rotating number code thing. Passkeys are another thing.

Totp

I think their biggest weakness is the vendor lock in. Using a 3rd party password manager is the best solution for most people, so they arent locked to their phone. But they are right in saying none of it is quite ready.

I think the article is forgetting, they are password replacements, not account recovery replacements. Realistically, people are just as likely to forget a password, and account recovery proceedures still have to be in place. I dont see the issue there.

Passkeys are good they are just being pushed before properly fully developed, but we are slowly getting there.

Love them.

Using 1Password for sync.

Never ever failed to connect to QR code passkey request, even on weird corporate networks.

Portability has gotten so much better - there’s now a defined standard for portability that passkey providers are implementing.

Honestly I cannot understand the criticism at all.

I lose physical objects. That’s mine.

Passkeys don’t require physical storage at all. All of my passkeys are in the cloud, synced across platforms.

I agree with this article, i think all points mde are valid and true.

But is there a downside for using mozzila password manager? (other than being in the cloud) I think It allows you to sync your passwords and login information accross any device you use, it works well for phone apps, websites log in and cross platform credentials (ios, android, linux and webpages)

Hardware keys are nice but expensive solutions. I’d love to convince my boss we should have them for all senior people plus sensitive roles like accounts and HR. Currently liking the yubikey nano, although its a pain if I forget it. At least I’m not dependant on a third party service.

Microsoft & Bitwarden are my only two accounts currently that allowed me to use a physical Yubikey as a passkey and have it work on Firefox + Linux. Bitwarden login with passkey only works in the webapp though, not the browser extension, desktop app or mobile app.

Bitwarden login with passkey only works in the webapp though, not the browser extension, desktop app or mobile app.

I’m confused by this — I use passkeys stored in Bitwarden and they work fine in the browser extension and mobile app (I don’t use the desktop app often so IDK). Are there particular sites that it doesn’t work with?

I think they mean logging into Bitwarden with a physical passkey.

I mean logging into the bitwarden account with the yubikey. Passkeys stored in bitwarden are usually accepted

Bitwarden login with passkey only works in the webapp though, not the browser extension, desktop app or mobile app.

Can’t confirm, my yubikey is my 2nd factor for bitwarden and I login with it on both my phone and web browsers

It works as second factor, yes. It does for many services, but using it for actually passwordless passkey login doesn’t work for most services with my yubikey.

I don’t know that OP is wrong per-se, but I think they’re overstated a bit.

Their statement that passkeys are better than people using the same password, but are a step back for people using a password manager, is maybe a bit much. It’s basically the same, but sometimes better.

Most of their drawbacks are the hardware implementations, but that’s already true of people using hardware 2FA, and corporate management, which is already a problem if you use Apple’s or Google’s existing baked-in password managers.

But if you don’t already have both of those problems, the standard is basically just “instead of having the password manager pretend to type in a box, what if they dumped something into the stream directly”, and that extends to what if the UI didn’t ask for anything and just said “hey, do you want to login? Just let me know and it’s done”

And, like, should you be able to export from Apple’s built in store to migrate? Absolutely, but if you never used Apple’s passkeys in the first place, because ugh gross, then it’s not a problem you need solved yet.

There is one problem I’ll admit, which is that it’s easier to make a sketchy password manager that just pretends to be a keyboard. I myself don’t actually use passkeys because I sync my passwords with git and use pass, which is cool and I love it. And then I type them using a dmenu script and xdotool, which is silly and I love it. But that doesn’t work with passkeys which I can definitely store in git, but would require a real actual connection between my browser and the tool, in a way that I don’t think currently exists.

But just because I can’t use my sketchy crap, doesn’t always mean it’s a step back 😛

The article is saying that while passkeys could theoretically be better, the current implementation is bad because it cedes power to centralized 3rd parties, entrenching users who now have no way out when that 3rd party is incompetent or corrupt.

But does it? There are non-centralized third parties you can already use. In fact besides my sketchy password manager, is it not the case that every password manager real people are already using, already support passkeys, so it’s the same power you were likely already ceding to whoever you were already ceding it to.

But in the meantime a database leak doesn’t compromise things anymore.

Unless I’m missing something? Which is highly possible.

Read the article, it’s all covered there. Open source password managers like bitwarden and keepass are ideal, but passkey support and integration with the OS is not there yet. With text passwords, you always had to fallback of copy and paste. With passkeys, OS integration is crucial.

My guess is that it may happen, or the big companies like Google or Apple can keep shifting the standards to keep the open source options outdated, like what Google already does with web standards.

I did read the article, but I guess “remains especially inconsistent” sounded less dire than perhaps the reality is.

I don’t understand one thing about hardware keys. Aren’t they, like, easy to steal? Sure, someone could torture my Bitwarden masterkey out of me, but hardware keys seem to make sabotage much much easier.

They’re as easy to steal and misuse as a laptop with KeePassX on it. Hardware as a second factor was always a better use case.

You can PIN lock hardware keys

That’s good to know.

I am using my password manager, which is keepass.

I have tried adding pass keys to it, and have had mixed success. On some websites, it seems to work fine, and then on others, it seems to break miserably, and made me return back to a password.

I like the idea of passkeys, because then you don’t have a shared secret between you and the website, and you get a different key for every single website using public-private key cryptography. That’s fantastic, but the implementation still needs some work.

They’re going to have to pry my keepass out of my cold, dead hands.

For users who previously reused passwords across all their sites, passkeys are a huge step-up.

That is exactly why passkeys are a good thing. Basically everyone reused passwords everywhere.

Maybe 5 or 10 years ago, but who doesn’t use a password manager these days? They generate random passwords and remember them for you

So we should be using passkeys to access our password managers that generate random passwords and remember them for us! Ultimate protection.

xkcd.com/2501/

Huh I thought it was going to be the correcthorsebatterystaple comic

In my experience you’re more likely to find a sticky note on the desk with passwords than someone using a password manager, 2fa, or an ounce of ‘common’ sense.

Do you know any non tech people, especially over 40? Literally none of them uses a password manager.

Most of the non-techy people I know use the password manager built into their Web browser at the very least.

“use” I bet it just saves everything automatically, and they don’t even know their passwords are there. just “oh look, my password has appeared, lets click it!”

My current employer will not authorize the use of a password manager. I have a key fob for my Microsoft account, and another account does phone verification. I use one password. If they don’t want to put the effort in for account security then neither do I. I use a password manager for nearly all my other accounts.

I just remember my passwords idk lol. I never understood the logic of a password manager, someone hacks your manager they have everything in your life? Rather just run the risk of getting hacked one account at a time rather than they all get hacked at once when they get my password manager.

So make the manager’s password massive. There, that complete sentence just now is over 30 characters long and could literally be a password. You can double up security with a secret file that you must locate on your PC, in KeePass, at least. You can also add notes about entries, track more than just website accounts, etc. It’s just too much brainpower to remember individual websites’ passwords. All important ones have 2FA anyway.

Managers are local to your computer so you likely messed up big-time if it got hacked, whereas websites can get hacked entirely out of our control.

A password manager is better than passkeys in 2026

Some password managers can sync passkeys for you! Bitwarden can handle it

android doesn’t allow 3rd party apps to use passkeys nor autofill 2fa consistently. For passkeys, you are forced to use google services for it, or loose access, making it pointless. TOTP codes meanwhile can at least be copied and pasted manually from a password manager.

developer.android.com/identity/…/manage-passkeys

Actually not, 3rd party Android apps can act as passkeys providers

With Bitwarden you can even do your own self hosted sync of passkeys

bitwarden.com/blog/bitwarden-passkeys-mobile/

It’s android version dependent. Only 14 and up support 3rd party providers.

Passkeys are supported on devices that run Android 9 (API level 28) or higher.

On many devices, Credential Manager stores passkeys to Google Password Manager by default. Users can choose other password managers as its passkey providers in the System Settings on Android 14 or higher.

Given the slowness of android version rollouts, this will be an issue for a long time.

I also think supporting older androids is pushing apps to do it the “wrong” way and making it google specific.

14 and up seems to be about 80% of users, and I suspect there’s a correlation between people who want to use passkeys with a third party password manager and being within two major versions of current.

“I can’t run Linux because version 1.0 doesn’t support my GPU”

Really depends on what you mean by passkey, since it’s actually a fairly vague term for a bundle of technologies.

I don’t really care for password manager passkeys; just use a password, all it really does is save you from needing to enter a username in a login flow.

But I’m a big fan of hardware 2fa using non-resident keys (“passkey” lite); I’ll use a regular login flow with a password manager, then the 2FA step with a hardware token. Basically bulletproof (ditto if you secure your PW manager with hw 2fa) and painless.

Even pw synced passkeys at least have the benefits of both being phishing resisting + replay protected, as well as being able to use the TPM chip for extra local protection.

Hardware keys are logically simpler though

It’s a false dichotomy to have one or the other. I use passkeys as a quicker and more convenient way to log in to some sites, but I still have passwords in my password manager as a fallback.

Some websites prevent you from using a password if you set up a passkey.

Pass keys are horrible.

It seems like what’s actually horrible would be those websites’ implementation. But yeah, I’m definitely sticking with a manager.

The trap: Putting any 3rd party between you and your access.
It’s a 3 card monte game, but with security.

Roleplay: Mr. Jonsith did you know your house is vulnerable? Your simple little key can be used by anyone to get in to your house. Security!? Our Keypass system will super secure your house. You give us your key, and when you want access, you come to one of our 5 in town locations, request access from us by showing us this new key here, and we will let you into your house.

next year: “In order to lower our costs and keep your monthly rate low, the five locations near you are being consolidated into a single location in Farawayville.”

another year later: “In order to lower our costs and keep your monthly rate low, our physical locations are being migrated to an online presence accessible through the HahaTrickedYou app, now available in your app store.”

seven months after that: the app doesn’t work. web site disappears. company goes under.

Companies have had 13,000+ Data breaches in the last 5 years. Lets all put our access in one of those, so that when some thief get access to one, they get access to everything.

“But Lutra, they won’t have access-access the pieces arent all there … blah blah blah”

Oh, cool, Lets put all our access in one of those, so when they get access to one, they lock us all out of everything.

Me neither | aesthelete

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).

I’m not the biggest fan of passkeys, either.

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.

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.

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 - 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.

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.

Hardware security keys is the other option. The FIDO2 ones are compatible with most sites using passkeys.

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.

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).

SQuiRreL!

Yeah, no idea why not popular.

Because it doesn’t encourage vendor lock in to big tech.

Passkeys cross vendor sync is in the works right now and you can already self host with Bitwarden

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.

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

Steve put so much time into it too. SQRL really is the superior method of the two.

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.

www.corbado.com/…/qr-code-login-authentication

I still feel like phishing prevention alone justifies passkeys enough

Good article.

Currently passkeys are too much of a vendor lock-in to big tech.

Bitwarden support alone does not change that.

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.

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 figured it was something like that, thanks for the explanation!

Doesn’t help if you’re not using a huge provider such as Gmail or Hotmail

It worked with ProtonMail

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

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.

Wait, you type passwords? KeePassXC’s auto-type awaits!

You realize password managers just open up another attack vector right?

Gather round everyone, “ILikeBoobies” is giving tech security advice! 👂

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.

I’m the admin. Every time I try to open it up, I only get guides for doing it on a regular, personal MS account.

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.

🎶Security is Theatre🎶

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.

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?

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.

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…

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.

Computing and by extension cybersecurity has a lot of mouth-breather idiots because it’s so new.

I think you a word, “cybersecurity” perhaps?

Oops. Thanks.

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’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.

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

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.