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.
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.
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.
So…re-using the same password for every service and site?
Grandma, that’s enough internet for today, OK?
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.
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
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.
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.
The main problem is if that you lose the device that’s physically attached to the passkey… You’ll lose your account.
I’d just prefer a biometrics-first approach.
Unless hackers started cutting people’s fingers, which is something just too risky for a rational hacker to do so it’s more than improbable, biometrics are way more secure, consistent, battle-tested and most important, more convenient and, by design, unforgettable.
Biometrics is inherently not securable and the only viable method of using it ever is locally only to unlock a different secret, which actually can be secure.
Most biometrics is trivial to duplicate, fingerprints can replicated from photographs.
Biometrics are battle tested and got annihilated in every conflict. It’s a total loser.
Naww… biometrics are easy to steal or coerce from people.
Lmao, easy to steal.
What’s going the hacker to do? Cut off your fingers or extract your eyeballs? 🤣🤣🤣🤣
How the fuck have you never heard of fingerprint copying?
Every fingerprint scanner which attempts to apply liveness detection has been fooled.
No biometrics is secure when used remotely. Ever. You can literally just replay the biometric data people send you after you create a phishing site and hack their accounts if it was sent raw.
That was a long time ago and things are better now but it’s just an example.
That’s why you shouldn’t use on device storage for them, like Apple/Google want you to. Biometrics are shit, I prefer passwords if we are having no passkeys. I agree they are not perfect, but we can improve them and they will be a lot better than passwords for the majority of people.
Also, you wont lose your account, youll just have to go through a recovery process. Exactly the same as you would now if you forgot a password or lost a MFA code.
Biometrics are NOT shit.
And the recovery process is useless if you don’g have acess to your recovery method. Passkeys create the Ouroboros kind of situation.
Passkeys are just more convenient replacements to passwords, ideally suited for a password manager flow.
For most people, this works really well and is a lot better than remembering loads of passwords. It’s easier to get people to remember a single stronger password and use passkeys to login to services.
The whole lose access thing isnt as big of a deal breaker as you make it sound. Considering the large amount of people that forget their passwords and constantly reset them, passkeys can help. There’s a reason popular sites just ask you for a code from an email now instead of even prompting for your password.
You want to use biometrics to individually login to services, great. But what about those of us who don’t want to rely on biometrics? That’s where passkeys do both jobs.
Don’t proper biometrics also lock you to a device? My phone isn’t sending my fingerprint anywhere, it’s comparing data against its baseline and then attesting that. If you did it any other way, then any data leak means you’re exposed literally forever.
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.
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.
They solve the problem of people using the same password everywhere. That’s significant.
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?
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.
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.
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.
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.
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.
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.
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.
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 passkeys are in the cloud, synced across platforms.
No, Passkeys are generated on device against a public key on the server side. If you lose the device where you created your local, private key, then you lose access to everything. Also there’s FIDO (and implementations as YubiKey and NitroKey).
That’s not how it is and not how they were designed. It was assumed from the beginning that they would live in “an ecosystem”, ie tied to secure storage and secure distribution by some system handled user side and indeed that is what phase 1 looked like: Google, Microsoft and Apple stored them on your device and replicated them across your devices. Phase 2 introduced a “interception” API so other providers could get involved easily - so providers like 1Password could rely less on browser hacks and also offer secure storage and secure distribution. Then finally, phase 3, now more or less locked down, described a portability system so that you can migrate to other ecosystems.
This is a good encapsulation of why passkeys are having a hard time. There are so many different ways to interact and it’s confusing for the user. There are physical FIDO keys, there are keys you create per device, then there are passkeys that the “device” is a password manager like bitwarden which is cloud based and follows you from wherever. It feels like they offer very different levels of security but do not look very different to the passkey issuer.
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.
Can’t confirm, my yubikey is my 2nd factor for bitwarden and I login with it on both my phone and web browsers
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
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.
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 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 don’t understand one thing about hardware keys. Are 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.
