But just because we have a real problem doesn’t mean that all proposed solutions are actually going to be better.
Some of the biggest threats to consumers and businesses are phishing and password reuse – passkeys eliminate that entire attack vector. That was a primary concern when designing the protocol. I think eliminating the biggest attack vector people generally face is a pretty significant improvement.
The UX issues are real, but webauthn is a young protocol and the portability of passkeys is very new, as the initial conception was more about hardware bound keys. But if you are in the same ecosystem everywhere the UI is actually prety excellent imo. The UX and lockin concerns are a priority, and progress is actively happening, e.g. the very recent Credential Exchange Spec.
Passwords are a 50 year old solution and probably aren’t going to see much more improvement. Not to discredit the UX complaints here, but deciding to completely remove the option for a well supported, standards-based phish-proof authenticator (as opposed to making it an advanced feature or something) seems like a disservice to the users who now are forced to use a fundamentally less secure authenticator.
so, passkeys are only more secure in lieu of proper security training?
and they’re only “phish proof” if it’s impossible to transfer them across devices, otherwise bad actors can just ask for a picture of the QR code or whatever (and this might actually get some people who know not to share passwords!)
so, passkeys are only more secure in lieu of proper security training?
No, the problem is “proper security training” is not a thing that works. “Proper security training” means every person must be able to identify instantly every variation of phishing and social engineering attack, must have memorized long completely random passwords for every single app, website, and device that they use.
This is much like the other cases where there is a “this is all that is needed” mechanisms: pilots just need to stay awake, non-driving “drivers” just need to be alerted when they aren’t demonstrably in charge of a vehicle they are not meaningfully in charge of.
If the “solution” is not physiologically or mentality feasible, it is not a solution. It’s like telling a person hanging from a balcony by to hang on, and then saying that you have solved the problem.
and they’re only “phish proof” if it’s impossible to transfer them across devices
Indeed, and by design they were not transferrable, but then people complained that they weren’t transferrable and that was how we ended up here, with a proposal that takes us from “zero ability for a phisher to use passkeys to compromise an account to a non-zero ability”
otherwise bad actors can just ask for a picture of the QR code or whatever (and this might actually get some people who know not to share passwords!)
No, the entire point of passkeys is you can’t do this. This is the general - widely and effectively - used attack against passwords and 2fa authentication. It’s either manual and explicit (quintessential example being person calling someone claiming to be a bank, asking them to confirm their password, and confirm the secret code they get on their phone/email), or it’s more automated (fake sign in page that just forwards your password and the 2fa token you enter to the attacker).
Passkeys do not have any of those weaknesses, the server provides a nonce, the client chooses the passkey to use (if available) based on the server making the request (TLS - if that’s compromised then any authentication scheme is broken, and some separate material in some cases), the server making the request includes a nonce, the passkey implementation takes the nonce, and other misc data wraps it into a blob, throws that at an HSM saying “I want this signed with this key” (key being an identifier, not the actual material which is wrapped and only available to the HSM). The HSM asks the user for approval and authentication, if it gets that it performs the required cryptographic options and gives the blob to the browser, which sends it to the server.
The result of this is that it is not possible for a passkey based sign on to be proxied, relayed, or replayed via any medium because the authentication is dependent on a secure connection between the device performing the authentication and the service requesting it.
So they solved on problem and caused lots of other problems. They might have resolved an attack(!) vector but opened new problem vectors. Maybe an attacker can now not gain access, but so can’t the user. Don’t forget: availability is also part of security.
must have memorized long completely random passwords for every single app, website, and device that they use.
this is not what i’m advocating for… i’m advocating for password managers…
Indeed, and by design they were not transferrable, but then people complained that they weren’t transferrable and that was how we ended up here, with a proposal that takes us from “zero ability for a phisher to use passkeys to compromise an account to a non-zero ability”
they either need to be transferable, or there needs to be an alternate login method. either of these are phish-able.
[oh hello again in a different thread I think? :D ]
this is not what i’m advocating for… i’m advocating for password managers…
In which case, passkeys are strictly superior to passwords, because they lack the myriad well established weaknesses of password based authentication
they either need to be transferable, or there needs to be an alternate login method. either of these are phish-able.
The alternate log in system is much easier to protect against phishing as the server side can gate and restrict account operations following such, and, because it’s aware of the action, can detect suspicious account activity, notify the user via multiple channels, etc. Whereas transferring the information directly to the attacker via export mechanisms regresses security against these attacks to much closer to password+2fa.
In which case, passkeys are strictly superior to passwords, because they lack the myriad well established weaknesses of password based authentication
Here’s a counter example: I can store a password in my head and even if I have to flee my country and are stripped of ALL my belongings whatsoever, I can still use the password to access the service later. I can’t do that with passkeys. Hence, passkeys simply cannot be strictly superior.
If that is your threat model then the trade offs are different for you. But you need to recognize that your threat model in that case is very different from most average users.
But in that case you can just treat passkeys as simply a more secure, (depending on scheme) private, and convenient version of other 2FA systems. In which you lose account access in the absence of the 2nd factor.
But you need to recognize that your threat model in that case is very different from most average users.
Maybe. But that doesn’t mean the technical solution must only work for average users.
Look, if everyone always has the choice between passwords and passkeys, great. No objections. In fact, I would use passkeys myself for certain usecases. The problem is that a lot of people are pushing to completely replace passwords. Then I lose this option.
But in that case you can just treat passkeys as simply a more secure, (depending on scheme) private, and convenient version of other 2FA systems. In which you lose account access in the absence of the 2nd factor.
Actually, I dislike 2FA also. The reason is not 2FA itself but the way it is implemented. I.e. very often forcing me to provide a phone number (I often travel between continents, so that sucks) or forcing me to use a custom app and hence android or IOS (and a non-jailbreaked device) and so on.
I expect the same and worse to happen with passkeys.
To put your analogy more simply (I think), the nature of passwords is that the threat is malicious and evolves over time.
Falling asleep / being inattentive does not evolve and is not malicious. The threat is self-inflicted. Authentication attacks are not self inflicted and require an ever evolving defense strategy.
Well, they have the asymetric cryptography properties regardless, so training isn’t needed to get the advantages of being phish proof and not using shared credentials. (But would probably still be super helpful given the UX is so new)
On addition to QR there’s also a proximity requirement (generally Bluetooth or USB cable), so phishing would need to be a local physicial attack. Hardware bound keys are always going to be more secure but have huge UX issues for more casual users.
The webauthn protocol and passkeys were explicitly designed to be user accessible and eliminate phishing and shared credentials. With the somewhat pragmatic goal of including disability concerns for average consumers in the design
Webauthn isn’t a perfect spec and has some room for improvement, but imo it’s really thoughtfully designed. And for the properties they designed for I think it’s rock solid.
asymmetric cryptography isn’t phish proof if you just transfer the private key.
the proximity requirement seems like it would do more in this regard, but it also has a UX cost. any i would be surprised if there’s no way to circumvent it.
and the attack of gaining VNC access to a device still exists.
Phishing is having a user provide login credentials to a system controlled by a malicious actor instead of the intended target. The classic example being something like asking for google.com credentials on google.com.malicious-site.io or whatever. In that hypothetical phish attempt the passkey login ceremony would be a valid webauthn ceremony but would be bound to google.com.malicious-site.io and useless anywhere else.
You can get someone to transfer the private key but the advantage would be twofold in the proximity requirement, preventing the huge vector of remote attacks, and also in the fact that it would be a rare ceremony that the user would likely not be so used to as to go through on auto-pilot.
By the VNC attack do you mean someone compromising the actual host the user is using and leveraging the existing session? Yeah that’s definitely a vector, but I don’t think any application layer authentication mechanism could really protect against a host compromise to that degree.
The Cambridge Multiple-Access System was first introduced into service experimentally in March 1967, and has been fully operational since 1968. It runs on the Titan computer which was the prototype Atlas 2.
A conventional password system for logging-in is used, but is has associated with it a feature, due to R. M. Needham, that greatly improves its effectiveness. This feature is easily implemented and deserves to be better known. It consists in storing in the computer, not the original password, but a scrambled form of it. The scrambling is done by an algorithm resembling one for generating pseudo-random numbers. When first set, the password is scrambled and the result stored; when the user attempts to log-in and types his password, what he types is again scrambled and compared with the original version. Only if they agree, is logging-in permitted. Since the scrambling algorithm is virtually irreversible, at any rate without a great deal of computer time being used, no harm is done if the list of scrambled passwords gets printed out by inadvertence. It is not even necessary to keep the scrambling algorithm secret. The security of the system is further improved by the fact that users can set and change their own passwords from their consoles. Thus, it is not necessary for a password to be communicated to a second party, or even written down.
What advantage does the use of a passkey have over the use of a password manager? And I know that few people use password managers, so, what advantage does the use of passkeys has over … having your browser or operating system act as a password manager?
Well just to clarify a bit, you can use a passkey but have that passkey stored inside a password manager, including the browser or OS password managers. (They should really be renamed to credentials managers or something) .
In that experience, there would be little or no difference in the user experience, since they would proceed with Apple Passwords/Google Password manager/1PW whatever. It would just use a passkey instead of a password. But the user would transparently gain the advantage of using key-based auth including domain binding, and not using a shared credit like a password.
So they’d be safe from phishing, and also if the site theyre visiting gets hacked, there’d be no shared credential, things like password reuse issues are completely removed. Which is great since it removes an attack vector the use has little control over.
Sure, I have passkeys stored in 1Password and working fine. And actually, you mostly need to use some manager for your passkeys, doesn’t matter whether that’s 1Password or your Google account.
What I’m wondering is what advantages do passkeys have for regular folks over the use of passwords stored in a password manager? And note that browsers these days are password managers that work for normies.
yeah to echo what sunshowers says below, phishing resistance. Password managers make phishing much more difficult, but only as UX guardrails – shared credentials like passwords and TOTP MFA are always fundamentally phishable. Domain-bound asymmetric crypto like passkeys aren’t. So in the scenario of someone with a browser password manager switching form password to passkeys, they’d go from phishing be difficult to being impossible. This also solves for password reuse. Anecdotally a lot of my non-engineer friends who use a password manager don’t let the password manager generate the password for them, which greatly reduces the effectiveness of a password manger, but this would solve for that.
Also for most places they wouldn’t need to use MFA at all anymore, as the single factor of user-verified webauthn such as passkeys are generally considered more secure that password + TOTP/HOTP/push notification. TOTP MFA with a password manager isn’t to annoying but this would be a small reduction in friction.
He’s not completely wrong with most of the topics, but fundamentally the only one I care about is that passkeys in the current form are just a terrible user experience for most people who are not either using iphone + macs or a single android device.
I have 3 different OSes on my m
ain computers and an android phone. I don’t want my passwords to by synced by Google, if I can avoid it. I especially don’t want them synced to any MS Cloud and I actually trust Apple a bit more here, but not much.
If I were to accept passkeys I would need the following things:
I can add an arbitrary amount of devices, and none of them need to have a webcam, only a network connection
Nothing needs to live in any $BIGCO’s cloud sync
and yet some form of (printable/savable) backup OTP code is a bonus
Most “yay passkeys” pieces I have read so far assume I either never lose my phone, my phone never breaks, I don’t use Linux, or I want to sync my passkeys to someone else’s cloud.
And yes, losing access to my accounts is a much more real threat to me than someone stealing my long password.
Seems like Bitwarden might be of interest to you. I have had a pretty seamless experience storing and using my passkeys with it (across Linux and Android personally, and Windows for work).
You can also self-host a personal sync server if you don’t want to use theirs.
thanks for the pointer, I’v trialed vaultwarden in the past and I am not comfortable with it being exposed on the internet, or me having to run a VPN, and in general KeePass has worked out better for me.
I love passkeys as a second form of auth. GitHub did a great job with that. If my passkey is available then I sign in with a single tap on the touchid sensor or with FaceID. If not then I fall back to username/password/code.
On GitHub it is specially useful to have Passkeys to access sensitive settings. Like managing Teams & Collaborators just requires a quick tap to verify it is me.
I wish more websites did this.
No reason to fully dismiss passkeys. I think it was wrong to market them as full password replacements. I like to think of them as complimentary.
Hi. I have a masters degree from MIT and 30+ years experience in software engineering, including several deep dives into authentication technologies.
I cannot make passkeys work on my computer.
I use Windows, Android, Chrome, and 1Password. It’s all a confusing mess, even when I simplify to just Chrome+Windows. Sometimes a passkey works once to log in and not again. Most of the time they don’t work at all. Sometimes sites remember I tried to make a passkey once and it causes problems months later when I try to remember how to log in some other way than using the passkey I either lost or can’t access.
I’m just talking about basic stuff, can I log in? It does not work. Passkeys have joined OpenID in my mind as a complete product failure.
The problem with passkeys is that they’re essentially a halfway house to a password manager
This is utter nonsense. The author has completely failed to understand the purpose of passkeys.
The entire point of passkeys is to get rid of passwords altogether. Password managers are a halfway house to secure authentication, and the fact that their password managers doesn’t support passkeys is a problem with their manager not knowing passkeys
But can a password manager know passkeys with the same usability as with passwords?
What I can do today, if I need to login into something from my wife’s computer, is to pop open bitwarden’s tab, enter my master password and copy-paste the password for the specific thing I need.
My understanding is that this is not really possible with passkeys: even if I store a passkey in Bitwarden, I can’t use it in an ad-hoc manner, I need to at least install a browser extension? Or is there some user-accessible flow where I can manually copy-paste the challenge and the response?
Of course, this whole thing with entering my master password into computer I do not own is icky security wise, but security is just the second most important feature of the password manager. The first one is me getting access to my stuff when I need it.
What I can do today, if I need to login into something from my wife’s computer, is to pop open bitwarden’s tab, enter my master password and copy-paste the password for the specific thing I need.
Yes, this is the attack vector that passkeys mitigate. Because you can, and people do, put this into a form controlled by an attacker. Passkeys make this impossible.
My understanding is that this is not really possible with passkeys: even if I store a passkey in Bitwarden, I can’t use it in an ad-hoc manner, I need to at least install a browser extension?
Either the browser builtin mechanism or a browser extension. I think Mac/iOS know directly which app is providing passkey support if not the OS internal.
Or is there some user-accessible flow where I can manually copy-paste the challenge and the response?
No, because copy-pasting the challenge-response is literally the attack vector being prevented.
Anything you copy - from the site, your phone, or whatever - can be provided by the attacker, so if you could take that and get your passkey implementation to sign a response to that and paste that back you have provided a mechanism for an attacker to authenticate themselves as you.
The entire point of the passkey process is to prevent that attack, the authentication process is basically:
Browser makes a tls connection to a host
The host provides a random token for your connection
The browser looks up the passkey it has for the host
If it finds one, it (essentially) signs the bytes from (2)
It sends that back
(1+3) mean that passkeys can’t be bypassed by a phishing site (phishing breaks autofill, but not manual fill like you’re suggesting)
(2) means that the attacker cannot control the data you’re signing
(4) means that the attacker cannot get your secret material
(5) the host can now confirm that the device performing the authentication is the device it is communicating with
the moment the you, the user, are copying content you lose all of this and you’ve reduced the security back to the level of passwords.
I found the very end of @matklad’s comment significant.
security is just the second most important feature of the password manager. The first one is me getting access to my stuff when I need it.
When push comes to shove, essentially everyone prioritises, let’s call them functional requirements, over security—and the tiny number of people who do not can be disregarded because they threw their computers into lava many years ago.
I think it’s fine for people to throw their computers into the lava. It’s not so great to roll out functionality to throw other people’s computers into the lava because you have a different opinion about security and the privilege to be able to roll your opinion out globally.
Most people just want to press a button to log in, which is what passkeys allow, and do so more securely and robustly that passwords or password managers.
Yes it’s possible that for you the trade off for security is different than for other users, but saying “passkeys are bad because my trade offs permit reduced security properties in exchange for ease of new device logins” is not a reasonable position either.
To my knowledge no one is being forced to use passkeys, you’re perfectly able to use password+2fa wherever you would like, and other people can use passkeys - mostly I’m guessing due to the more streamlined login, but for me the strong security guarantees are the compelling part.
mostly I’m guessing due to the more streamlined login
People are onboarded by what looks like a more convenient login but I (and they probably too) have no idea about the edge cases. What happens if they lose a device? No way to figure this out really without going through it.
Yes it’s possible that for you the trade off for security is different than for other users
Most people with serious security requirements seem to be using Yubikeys anyway. For most normal people passwords written in a paper book are the best solution, and critical digital logins backed by some national identity or notary scheme so they can retrieve their accounts in the case of loss.
(I just got locked out of an old Google account because I don’t have access to the 2FA phone number anymore. Let’s just say I’m glad there wasn’t really anything of value in there.)
(I just got locked out of an old Google account because I don’t have access to the 2FA phone number anymore. Let’s just say I’m glad there wasn’t really anything of value in there.)
That’s what the backup codes that Google prompts you to save in a secure place after setting up 2FA are for.
It of course perfectly illustrates the failure modes of these systems and if I a CS graduate am bit by this, then for sure most normal people do not stand a chance.
It’s too bad every large website implementing passkeys has figured out that you still have to support email-based self-service recovery to avoid a flood of support requests.
All of these protections are pointless if every passkey can be bypassed through email. Attackers have no problem walking users through recovery flows.
Suppose I have a site that I usually log into from my phone, but today I want to connect to it from a browser on my mother’s computer. Is that simply prohibited in the name of better security? Or is there a way I can accomplish it if there is no password, only a passkey.
That’s up to the site, you’re fundamentally in a position of doing a new device log in, so you’d presumably need a full 2fa dance, which they could permit via your signed in phone, or whatever other mechanism they choose. However they would still have to take steps to mitigate the risk of that being used as a phishing/social engineering attack (you basically start to run the risk of creating the kind “account recovery” style mechanism scammers use to compromise accounts).
It seems to me that there is an irreconcilable issue here: either a site allows some kind of account recovery (and “log in from my mother’s computer” is an example of “account recovery”), in which case there is a risk of it being used in a social engineering attack, or it does NOT allow any kind of account recovery, in which case accounts can’t be recovered.
What I would like to see is some enhanced forms of validation needed when doing “account recovery”. But that ends up meaning that I CANNOT “get rid of passwords and just use passkeys instead” (which is the promise) unless I also give up completely on having ways to recover an account.
Because it’s not just technically illiterate users? There are many attack vectors that are not trivial to identify and human brains are notoriously bad at reading/seeing what they expect to see. Yes of course there are people who are more gullible than others, but the security of your account should depend on more than just never ever making a mistake.
A better question there would be “why should be able to use your service securely be dependent on expert level understanding of attacks?”
If as you say the problem is just not being technically literate I’m curious if you avoid/ignore 2FA mechanisms, because those exist simply to try and provide some of the guarantees you get from passkeys. If it’s just a matter of technical literacy then it’s just an annoyance during log in.
i’m struggling to see how transferable passkeys aren’t just isomorphic to passwords in a password manager.
i suppose with certain passkey schemes you could perform a challenge-response authentication over an unencrypted channel… but i’m not sure that’s desirable tbh.
i’m struggling to see how transferable passkeys aren’t just isomorphic to passwords in a password manager.
Any “move from service A to service B” is going to involve a cryptographic exchange, e.g. service A would re-wrap the key material to a key provided by service B (this is the “don’t leak the unwrapped key material”). But I agree, my concern is that supporting that opens a vector for scammers to convince people to transfer their keys to an attacker controller application which obviously is not going to care too much about actually keeping the data secret, which is a significant reduction in the security against social engineering (in that it goes from being actually impossible to being at all possible).
It is still important to understand though that even with that obnoxious problem passkeys are still fundamentally different from passwords, the reason they’re set up the way they are is to prevent any kind of man in the middle or social engineering attack. They’re not just an HSM backed password manager (that’s a bare minimum requirement of any password manager), they’re cryptographic keys that allow authentication that also proves to a server that the client performing the authentication is the client it is talking to. That’s not something any password or password+2fa/totp authentication can do, and that’s a weakness that is constantly being exploited.
But I agree, my concern is that supporting that opens a vector for scammers to convince people to transfer their keys to an attacker controller application
This is a legitimate concern, but I think the UI challenges are solvable. First, unlike copying and pasting a password, this is not going to be a common flow. People who are happy with a single vendor’s ecosystem will never use it and the flows between the big vendors are likely to be polished.
Even without multi-vendor support, the Apple flow is pretty good. You need to log into the new device with your Apple ID. This requires a password for bootstrapping but then requires a second factor p, which is typically another Apple device that tells you the device that you’re trying to log into and where it is. The latter is the biggest UI flaw because Apple’s geolocation is terrible and seems to be no more accurate than getting the correct country, but that should be fixable. You could also add a distance-bounding protocol over Bluetooth in here for the location-looks-wrong case.
This is a flow that users will do once when setting up a new device and can be flagged with ‘this is a new device setup thing, make sure that the target is your device, never let anyone else do this’ warning.
The bigger worry for me is coercion. If you have a person and their phone, forcing them to sync their passkeys to your device is quite easy. WebAuthn doesn’t seem to have a good revocation story for ‘this copy of my keys is a stolen one, please undo everything it’s done and lock it out’. Windows Hello has device-bound credentials, which carry the device identity with them so you can tell the difference between logins by the same user from different devices, but I believe that’s a non-standard extension.
Any “move from service A to service B” is going to involve a cryptographic exchange, e.g. service A would re-wrap the key material to a key provided by service B (this is the “don’t leak the unwrapped key material”).
isn’t this already handled by oauth? or am i misunderstanding what you mean here by “service”?
It is still important to understand though that even with that obnoxious problem passkeys are still fundamentally different from passwords, the reason they’re set up the way they are is to prevent any kind of man in the middle or social engineering attack.
MITM is addressed by TLS encryption
social engineering is an entire category of attacks, changing one technical detail may make some social engineering attacks more difficult, but it most certainly does not make all social engineering attacks impossible.
i’m really just struggling to see what “the point” is. it basically seem like making it slightly easier to follow good security practices at the cost of making it significantly harder to actually use services.
isn’t this already handled by oauth? or am i misunderstanding what you mean here by “service”?
Yes, but I think entirely due to bad explanation on my part. It’s a skill :D
What I’m talking about here is the passkey provider, e.g apple’s keychain, googles , 1password, etc
Something people constantly complained about with passkeys was you create your passkeys with Service A (say keychain) and you can’t simply transfer that passkey to a different tool like 1password, what you had to do was create a new passkey with the new provider you wanted to use instead. For a couple of sites that’s not an issue, but if you were say just planning to transition to a new ecosystem and wanted to move all of your credentials over that’s a lot of work.
The thing is that the reason passkeys did not permit the extraction/transfer of the material is because scammers are exceptionally good at convincing their victims to do things, like telling the person on the phone what their 2fa token is, or installing software and giving that software excitingly elevated permissions.
Introducing the ability to export passkeys to another provider opens the previously non existence option of an attacker convincing their victim to install a piece of software and then export their passkeys to it, and in doing so provide all the material to the scammer.
It is still important to understand though that even with that obnoxious problem passkeys are still fundamentally different from passwords, the reason they’re set up the way they are is to prevent any kind of man in the middle or social engineering attack.
MITM is addressed by TLS encryption
No TLS does not resolve this kind of man in the middle, as this isn’t just about MiTM of a network connection, it MiTM of the authentication path. The user is convinced, by whatever mechanism, to open a scam page. The url is not the real website, but it is objectively true that users are bad at recognizing this. The scammers are forwarding the content of the real web page to the user of the fake url, the user enters there password in the fake page (sites are good enough at breaking password autofill that even users who are using password managers routinely fall for this), the scam page sends that back to attacker who uses that to log in. If the site has some form of 2FA, the scammer simply forwards that request to the victim, the user is expecting this, so still does not question the need and enters the code, which is forwarded to the scammer, who then has successfully compromised the account.
Passkeys tie the authentication to the actual identity of page being loaded on the authenticating machine, so this kind of MiTM simply does not work.
social engineering is an entire category of attacks, changing one technical detail may make some social engineering attacks more difficult, but it most certainly does not make all social engineering attacks impossible.
All the social engineering attacks targeting authentication revolve around getting the victim to provide their passwords and necessary 2FA tokens to the attacker, which only works because the passwords and 2fa tokens are not tied to the device or connection being authenticated.
These are the ways that scammers compromise accounts in the real world, and passkeys prevent them in a way that is fundamentally not possible via any other mechanism (in the sense of “this authentication model is the only way to prevent these kinds of attacks”, “passkeys” just happen to be the implementation+branding we have for the model).
sites are good enough at breaking password autofill that even users who are using password managers routinely fall for this
Ah, this addresses my wondering why commenters are saying password managers are so insufficient. (I hadn’t personally encountered broken password autofill not being a reasonably reliable signal that one’s not talking to the right website.)
it’s super annoying, especially now so many sites have started breaking sign in pages into multiple steps, something that serves literally no purpose other than breaking automatic sign in and encouraging users to expect random page loads and page changes during sign in. Le sigh.
Still at least there’s fairly standard mechanisms for marking a password field so the autofill is actually possible, as opposed to the relentlessly stupid and brain dead password rules and restrictions that sites keep inventing, despite decades of research showing the outcome is worse passwords that are reused, and systematically selected. Mercifully NIST has finally updated their docs to say “stupid ass rules that prevent random passwords are stupid and you suck” :D
many sites have started breaking sign in pages into multiple steps, something that serves literally no purpose other than breaking automatic sign in
In my limited experience of websites with multi-stage sign-in pages, the Google Chrome password manager copes with them, even if it needs to have the user choose from the saved username/password pairs (if there are >1) at the username step and then again at the password step, which still keeps the passwords that the user is prompted to use limited to ones associated with the domain. I don’t doubt that there are worse sign-in pages with which I’m not familiar, though!
Oh yeah, I think they all manage it now, it’s just more work for the implementation (the site navigation and UI changes makes it much harder to link account and password fields). For autofill you have to approve the autofill multiple times, etc.
It literally just makes site login slower, password autofill more annoying to implement, and trains users to expect jank and weird page loads and refreshes scattered throughout a legitimate login.
It’s just a very weird and obnoxious decision by these sites.
But if you want to be able to share keys around and back them up without some third-party service (which may be niche requirements, but they are critical to me) then you need some form of serialized secret which is effectively a password. At that point you may make it user-readable and easy to type on a keyboard. Sure, I almost never do type it. But when I do need to it is invaluable.
At that point you may make it user-readable and easy to type on a keyboard
Passkeys are not passwords that are being kept secret from you, they’re a cryptographic challenge/response process.
They’re not human typable because passkey authentication means signing a server provided nonce as proof of identity, and the server is able to verify that the machine doing the authentication is yours because an attacker is not able to get your machine to sign the data that the server has given them. I tried to summarize in my response here https://lobste.rs/s/2mgwsz/passwords_have_problems_passkeys_have#c_mp7x0o
I should have been more clear that I am talking about the storage format not the authentication protocol.
You can also do challenge response with passwords (ex: SRP, OPAQUE). My opinion is that upgrading the authentication protocol without moving away from passwords as a secret format would have been a better approach. Password managers can become more aggressive about warning users when displaying and exporting passwords (to prevent phishing and similar) but we don’t throw away the concept of passwords that is so simple to understand that my grandparents can back up their password manager into a notebook.
Basically I feel that we gave up so much for an improvement that could have been added to the simple system. With a PAKE and some UX you get basically all of the benefits of passkeys but users can still understand how it works to a degree that lets them do useful things like authenticate on a friend’s machine.
useful things like authenticate on a friend’s machine.
This seems like the core disagreement here: some view this as an important UX feature, and some consider this to be a security bug in need of prevention.
Both sides have their point! And it indeed seems that it’s not actually possible to automatically separate useful “your friend’s machine” from malicious fishing.
I wish someone has stated the tradeoff more explicitly here. It is clear what attacks are prevented. It is not completely clear which valid use-cases are prevented as a collateral damage.
The problem is less a disagreement but rather one side (the passkey side) trying to push their opinion onto the other side. I’m okay to have the option to use passkeys in addition to passwords. The passkey folks don’t seem to like it, they need to replace passwords.
I mean, in this very thread there are some comments that say that passkeys have no advantage over passwords in a password manager, and the article itself kinda-sorta claims the same.
Things are very rarely one-sided, even if it looks like that from a particular side!
How does PAKE address the benefits of pass keys? I don’t think it does at all. You can MITM PAKE just as easily as any password, it’s just that the password doesn’t get leaked - the signed response does.
PAKE is great because the underlying secret never gets conveyed but it doesn’t address phishing. PAKE’s main benefit is that you don’t end up with “mypassword1234” scattered in your nginx logs or whatever.
Also, PAKE is not straightforward to implement on the server. I know that passkeys aren’t either, but I do just want to point out that it’s not simple. User signup becomes much trickier.
Ok, in that case the issue just becomes the non-escaping nature of (the original) passkey model.
The reason for that mechanism is specifically to prevent scammers from being able to get people to provide the actual secret, because once you provide the secret to the attacker they can authenticate with the material the server provides their own connection.
The reason folk want a password, is because they want to be able access the secret, and in other words defeat the above.
I guess a good way to think about this is, how would it impact your opinion if the passwords from your password manager were just base64 encoded ECC keys?
I believe that you can only protect people from themselves so much. This is why I would rather make it a UX issue than add technical limitations and proprietary sync protocols. We can make the UX very aggressive about letting people know that they are doing something risky. (Or for corporate secrets actually block exporting).
were just base64 encoded ECC keys
If they were of a reasonable length then I would be fine with it. Honestly if a portable and reasonably human-manageable export format for passkeys was standardized would be pretty fine with the whole system. Maybe it will land some day, but I feel that this is a critical feature that should have been mandated from day one.
I believe that you can only protect people from themselves so much.
If there is a well understood, and effective, attack that works consistently, and you can simply make that attack not function why would you not?
were just base64 encoded ECC keys
If they were of a reasonable length then I would be fine with it.
right, so your issue is not the authentication scheme, which is superior to password based auth, its that you can’t simply extract the key material and use it directly yourself. Despite not being able to do any of the authentication yourself - it’s not an operation any person is doing in their head - and it means you’ve taken on the burden of verifying the host identity of the forms you’re reading and filling out (which is not necessarily the same as “what is the url the location bar shows”)
It’s at the expense of friction, not ability. You can still log in. If my phone is my passkey I can have my phone authorize me via, for example, a QR code.
Because there are downsides that are not worth it.
We can lock everyone in their own house to prevent murder, STDs and many other things. But it is not worth the tradeoff. We can force people to eat a regimented diet to prevent a huge number of illnesses. But that isn’t a world I want to live in. We should help people to the right thing, but at some point we need to give people freedom.
Really, it’s fine for me if the passwords from my password manager are just base64 encoded ECC keys. I just want to be able to use my choice of password manager, and sync its encrypted database file however I please. I’m not hugely concerned if there is a standard way for the browser and the password manager to communicate that’s not copy-and-paste, either. What I am concerned about is having my choice of password manager constrained to e.g. Apple or Google.
What I am concerned about is having my choice of password manager constrained to e.g. Apple or Google.
It isn‘t with Passkeys. 1Password implements them, and any other password manager can too. Apple, and I guess Google and Microsoft also, provide APIs to hook into both password autofill and passkeys for 3rd party managers to use.
Funny that he mentions 1Password, but disregards that it solves the exact problem of synchronizing your passkeys between devices. The real problem seems to be though that 1Password doesn’t integrate well with mobile web browsers for passkeys.
Edit: Looks like Android 14 is needed for passkey integration.
1Password is decent enough for use in mobile web browsers. Android started having support for autofill services, so hacks involving accessibility access and draw over are no longer required.
Hard disagree. As a Xennial, I would call it a toss up if someone of my generation understands QR codes or not. Gen X and above: not at all. If you find one that knows what a QR code is, it is hard to find someone who can actually scan them (at least with any reasonable speed). I can’t make claims for the generations after me.
I personally still don’t understand passkeys. I would much prefer it just said “Log in with my iPhone” or “Log in with my Samsung phone”. Passkeys limited to whatever computer you’re using at a time is a nightmare. I remain completely unclear whether I should allow Proton Pass to hold my passkeys, a Titan key to hold my passkeys or my iPhone to hold my passkeys. I think PP is the right choice, but security isn’t supposed to be a guessing game.
I think passkeys are not going to pass muster and will go away.
if you sign up for a service on Windows, and you then want to access it on iPhone, you’re going to be stuck (unless you’re so forward thinking as to add a second passkey, somehow, from the iPhone will on the Windows computer!). The passkey lives on the wrong device, if you’re away from the computer and want to login, and it’s not at all obvious to most users how they might fix that.
While I agree that it’s tricky to implement passkeys correctly, if done right these kinds of user-facing issues can be solved very elegantly with great UX. In this example, when you go to the service’s login page on iPhone, you can have some client-side JS that detects that the user doesn’t have a passkey for the account, and show them a ‘log in with email’ screen. Once they log in with email, immediately redirect them to the ‘create a passkey’ page, show some wording that gets them to trigger the passkey creation, and have them set up the passkey. Then, next time they log into this service on iPhone, the same client-side JS detects the passkey and uses it automatically.
Yes, this can be a bit tricky to set up for the developer. But the good news is that someone just needs to implement this functionality once, preferably as a library or framework, or maybe as a SaaS.
when you go to the service’s login page on iPhone, you can have some client-side JS that detects that the user doesn’t have a passkey for the account, and show them a ‘log in with email’ screen
How do you know which account the user is trying to access? The flow would look like this:
User goes to login page
User enters username/email address
If user has a passkey associated with account, prompt user
User doesn’t have the passkey on this machine, hits cancel, proceed to next step
If user does not have a passkey, “login with email” notification
Login via email sent to user’s mailbox
Create a new passkey
Example normal flow:
User goes to login page
User enters username/email address
User enters password from their manager
It’s honestly not even close and for security reasons, there are serious limitations on what you can and cannot do to improve the UX for webauthn. The user will always be shown the browser-defined prompt – we cannot change that flow.
But the good news is that someone just needs to implement this functionality once, preferably as a library or framework, or maybe as a SaaS.
You’ll never get a monopoly on this and many many devs are going to have to reimplement it.
Further, I’m not sure how many people have had to implement webuathn, but I have for a prod system and let me pile on the bandwagon: it absolutely sucks to implement. To be crystal clear here: webauthn requires a relying party (the domain of the site registering to), so when testing everything you must use HTTPS. There is an exception for localhost but that doesn’t fully test everything end-to-end! Everything can work perfectly with localhost but the second you deploy you can run into configuration issues (e.g. you have a dedicated auth service so RP cannot be origin). At some point, you need to test with an HTTPS site. And I know what you’re thinking, “just use ngrok or something like it for local development.” That would be great except “ngrok” is a public suffix and is rejected from being used with webauthn. And guess what happens when you try anyway? It just sends a generic, non-descript error. Seriously, webauthn sucks from a dev perspective when you need to test something end-to-end. You basically need a fully functional staging environment to test it.
Passwords and totp are 1000x easier than webauthn to implement and I’m not really sure what we gain from it beyond a “hardware password specific to the site” which I don’t even like!
Finally, you don’t even own the passkeys when using the default browser passkeys! Until they support import/export where I can transfer the certs wherever I want, I don’t own them. It’s overall very limiting, feels like a couple big companies are getting all the benefits while everyone else suffers.
Passwords and totp are 1000x easier than webauthn to implement and I’m not really sure what we gain from it beyond a “hardware password specific to the site” which I don’t even like!
It’s part of mitigating risks, but not the only or even most important parts. For example, we absolutely should regulate milk sales so that companies are allowed to legally sell only pasteurized milk, not raw milk. Even then, we know that some people will insist on drinking raw milk and we should try to spread awareness of the dangers of raw milk to those who might listen. But we should absolutely engineer food networks and systems that try to ensure that only pasteurized milk is available to the general public.
But we have done exactly that and it works great. Passkeys incorporate this but you don’t need passkeys for this - U2F/FIDO2 tokens work great too. This is a huge win.
Not only that, but technical solutions are the only way to solve social engineering issues by their very nature.
Well, I’m a security specialist, so I guess today’s a new day haha. In fact, I don’t really know anyone these days in the infosec world who isn’t in accordance with my statement but I’m sure they’re out there - maybe a dozen years ago it was the predominant view that we just needed more training for people, but that’s long been out of fashion.
The source is sort of just a straightforward examination of the issue. If the human is both the authorizing party and the vulnerable party, authority or vulnerably has to be addressed. Making humans invulnerable to social engineering is almost certainly intractable[0] so we need to have them not be the authorizing party, which means delegating that authorization to some sort of technical solution.
We can think of this in terms of privilege boundaries, perhaps. Consider an unprivileged process on a Linux system. The kernel authorizes that process when it performs system calls. If the kernel is vulnerable, the attacker can assume the authorization properties of the kernel. We can solve this by patching every vulnerability in the kernel or, as we typically do, we can create a new authority like a virtual machine that the kernel is bound by.
This is not to say that user education or user control don’t merit efforts, only to say that for a given authority the “best” way to improve its security is to delegate authority to smaller, less vulnerable, specialized components.
[0] A good example of this might be Jim Browning[1]. Jim Browning is an expert on scams. He actually actively “scams” scammers. I don’t know that there are many people who have spent quite so much time as Jim in terms of actively engaging with scammers, their techniques, their methodologies, psychologies, etc. And yet Jim Browning was scammed - he was tricked into having his entire Youtube channel taken over.
[edited to note that totp/similar token based 2nd factor systems do nothing to mitigate any of the attacks that passkeys prevent]
Passwords and totp are 1000x easier than webauthn to implement and I’m not really sure what we gain from it beyond a “hardware password specific to the site” which I don’t even like!
I’m not sure I understand what you’re saying. The entire reason for passkeys existing is that they cannot be exploited in any of the myriad ways passwords are, and password managers do nothing to prevent any of these attacks. It seems like the issue is that you may not understand how passkeys work. The important part (from an authentication security PoV) is not that they’re held in an HSM (that’s just a requirement given the existence of malware) it’s the prevention of all of the myriad issues that password managers do not - and cannot - prevent:
MiTM/site interposing - attacker has a fake website that is just forwarding between you and the real site
XSS - attacker injects password extraction into the legit site
Social engineering - all the standard cases where you or someone else is convinced to put their password into a form either directly online or via phone
Malicious extensions - enough password stealing extensions have been found now for this to be a pretty clear issue (it’s fairly unavoidable given most valuable extensions require enough control and access to site content to do this if they’re compromised/bought by bad actor)
Password managers do not prevent this.
Password managers solve two, and only two, problems:
Weak passwords
Password reuse
TOTP and similar token based 2nd factor schemes make this harder, but fundamentally fail to the same set of MITM and social engineering attacks. TOTP and similar second factor attacks exist solely to mitigate the problems of password reuse and compromise, and are demonstrably bypassable by sufficiently motivated attackers.
Passkeys functionally wrap the 2nd factor into the core of the authentication process, and do so in a way that also cannot be MiTM’d by tying the authentication directly to the TLS connection with the host system.
It is unclear if you feel like you get some kind of value from having access to the raw/unwrapped key material, but it’s important to understand that the reason for that is that we have seen time and time again, that if there is a way to get someone - either the user themselves, or some variation of malware - to extract it then scammers are able to get that material from victims. By preventing the exposure of the unwrapped key material it is fundamentally not possible for an attacker to ever gain the ability to ever authenticate their own machine.
You are very much overcomplicating this. Read what I said carefully. When you go to a web page, you can have some client-side JS that detects any passkeys that you have stored that are tied to the domain, and automatically ask the user to log in with one of those. The user wouldn’t even need to enter their email address. This is called Conditional UI, see here: https://web.dev/articles/passkey-form-autofill
I get your point about testing, the only thing I can say to that is, you’ll need to set up a proper test environment with HTTPS instead of pushing directly to Prod 🤷♂️
Wait but if you support logging in with e-mail, what the hell is the point of the passkey? Just as optional extra tiny bit of convenience for people who don’t want to open their e-mail client when their session token expires? That’s not at all how they’re pitched though
If you support login with email but by default your UX flow guides users to automatically use passkeys as much as possible, then you are giving them an even easier auth experience than their usual ‘email’ login flow. Users will use your software not necessarily in the way that you intended for them, but in the path of least resistance. Make passkeys the path of least resistance and they will become users’ default flow.
If the backend supports several login methods, the attacker will simply choose the path of least resistance. If the user has reused bad passwords, then passkeys wont solve anything.
The linked post says
Some of the biggest threats to consumers and businesses are phishing and password reuse – passkeys eliminate that entire attack vector. That was a primary concern when designing the protocol. I think eliminating the biggest attack vector people generally face is a pretty significant improvement.
The UX issues are real, but webauthn is a young protocol and the portability of passkeys is very new, as the initial conception was more about hardware bound keys. But if you are in the same ecosystem everywhere the UI is actually prety excellent imo. The UX and lockin concerns are a priority, and progress is actively happening, e.g. the very recent Credential Exchange Spec.
Passwords are a 50 year old solution and probably aren’t going to see much more improvement. Not to discredit the UX complaints here, but deciding to completely remove the option for a well supported, standards-based phish-proof authenticator (as opposed to making it an advanced feature or something) seems like a disservice to the users who now are forced to use a fundamentally less secure authenticator.
so, passkeys are only more secure in lieu of proper security training?
and they’re only “phish proof” if it’s impossible to transfer them across devices, otherwise bad actors can just ask for a picture of the QR code or whatever (and this might actually get some people who know not to share passwords!)
No, the problem is “proper security training” is not a thing that works. “Proper security training” means every person must be able to identify instantly every variation of phishing and social engineering attack, must have memorized long completely random passwords for every single app, website, and device that they use.
This is much like the other cases where there is a “this is all that is needed” mechanisms: pilots just need to stay awake, non-driving “drivers” just need to be alerted when they aren’t demonstrably in charge of a vehicle they are not meaningfully in charge of.
If the “solution” is not physiologically or mentality feasible, it is not a solution. It’s like telling a person hanging from a balcony by to hang on, and then saying that you have solved the problem.
Indeed, and by design they were not transferrable, but then people complained that they weren’t transferrable and that was how we ended up here, with a proposal that takes us from “zero ability for a phisher to use passkeys to compromise an account to a non-zero ability”
No, the entire point of passkeys is you can’t do this. This is the general - widely and effectively - used attack against passwords and 2fa authentication. It’s either manual and explicit (quintessential example being person calling someone claiming to be a bank, asking them to confirm their password, and confirm the secret code they get on their phone/email), or it’s more automated (fake sign in page that just forwards your password and the 2fa token you enter to the attacker).
Passkeys do not have any of those weaknesses, the server provides a nonce, the client chooses the passkey to use (if available) based on the server making the request (TLS - if that’s compromised then any authentication scheme is broken, and some separate material in some cases), the server making the request includes a nonce, the passkey implementation takes the nonce, and other misc data wraps it into a blob, throws that at an HSM saying “I want this signed with this key” (key being an identifier, not the actual material which is wrapped and only available to the HSM). The HSM asks the user for approval and authentication, if it gets that it performs the required cryptographic options and gives the blob to the browser, which sends it to the server.
The result of this is that it is not possible for a passkey based sign on to be proxied, relayed, or replayed via any medium because the authentication is dependent on a secure connection between the device performing the authentication and the service requesting it.
So they solved on problem and caused lots of other problems. They might have resolved an attack(!) vector but opened new problem vectors. Maybe an attacker can now not gain access, but so can’t the user. Don’t forget: availability is also part of security.
this is not what i’m advocating for… i’m advocating for password managers…
they either need to be transferable, or there needs to be an alternate login method. either of these are phish-able.
[oh hello again in a different thread I think? :D ]
In which case, passkeys are strictly superior to passwords, because they lack the myriad well established weaknesses of password based authentication
The alternate log in system is much easier to protect against phishing as the server side can gate and restrict account operations following such, and, because it’s aware of the action, can detect suspicious account activity, notify the user via multiple channels, etc. Whereas transferring the information directly to the attacker via export mechanisms regresses security against these attacks to much closer to password+2fa.
Here’s a counter example: I can store a password in my head and even if I have to flee my country and are stripped of ALL my belongings whatsoever, I can still use the password to access the service later. I can’t do that with passkeys. Hence, passkeys simply cannot be strictly superior.
If that is your threat model then the trade offs are different for you. But you need to recognize that your threat model in that case is very different from most average users.
But in that case you can just treat passkeys as simply a more secure, (depending on scheme) private, and convenient version of other 2FA systems. In which you lose account access in the absence of the 2nd factor.
That is part of my threat model, yes.
Maybe. But that doesn’t mean the technical solution must only work for average users.
Look, if everyone always has the choice between passwords and passkeys, great. No objections. In fact, I would use passkeys myself for certain usecases. The problem is that a lot of people are pushing to completely replace passwords. Then I lose this option.
Actually, I dislike 2FA also. The reason is not 2FA itself but the way it is implemented. I.e. very often forcing me to provide a phone number (I often travel between continents, so that sucks) or forcing me to use a custom app and hence android or IOS (and a non-jailbreaked device) and so on.
I expect the same and worse to happen with passkeys.
passkeys do have many unavoidable downsides compared to passwords (for example, implementation complexity), meaning they are not strictly superior.
To put your analogy more simply (I think), the nature of passwords is that the threat is malicious and evolves over time.
Falling asleep / being inattentive does not evolve and is not malicious. The threat is self-inflicted. Authentication attacks are not self inflicted and require an ever evolving defense strategy.
Well, they have the asymetric cryptography properties regardless, so training isn’t needed to get the advantages of being phish proof and not using shared credentials. (But would probably still be super helpful given the UX is so new)
On addition to QR there’s also a proximity requirement (generally Bluetooth or USB cable), so phishing would need to be a local physicial attack. Hardware bound keys are always going to be more secure but have huge UX issues for more casual users.
The webauthn protocol and passkeys were explicitly designed to be user accessible and eliminate phishing and shared credentials. With the somewhat pragmatic goal of including disability concerns for average consumers in the design
Webauthn isn’t a perfect spec and has some room for improvement, but imo it’s really thoughtfully designed. And for the properties they designed for I think it’s rock solid.
asymmetric cryptography isn’t phish proof if you just transfer the private key.
the proximity requirement seems like it would do more in this regard, but it also has a UX cost. any i would be surprised if there’s no way to circumvent it.
and the attack of gaining VNC access to a device still exists.
Phishing is having a user provide login credentials to a system controlled by a malicious actor instead of the intended target. The classic example being something like asking for
google.comcredentials ongoogle.com.malicious-site.ioor whatever. In that hypothetical phish attempt the passkey login ceremony would be a valid webauthn ceremony but would be bound togoogle.com.malicious-site.ioand useless anywhere else.You can get someone to transfer the private key but the advantage would be twofold in the proximity requirement, preventing the huge vector of remote attacks, and also in the fact that it would be a rare ceremony that the user would likely not be so used to as to go through on auto-pilot.
By the VNC attack do you mean someone compromising the actual host the user is using and leveraging the existing session? Yeah that’s definitely a vector, but I don’t think any application layer authentication mechanism could really protect against a host compromise to that degree.
A bit older than 50 years!
“The cambridge multiple-access system in retrospect”, M. V. Wilkes, 1973
Titan was one of the first time-sharing systems.
Roger Needham is perhaps better known for the Needham-Schroeder protocol, the basis of Kerberos.
What advantage does the use of a passkey have over the use of a password manager? And I know that few people use password managers, so, what advantage does the use of passkeys has over … having your browser or operating system act as a password manager?
I’m asking because I see absolutely none.
Well just to clarify a bit, you can use a passkey but have that passkey stored inside a password manager, including the browser or OS password managers. (They should really be renamed to credentials managers or something) .
In that experience, there would be little or no difference in the user experience, since they would proceed with Apple Passwords/Google Password manager/1PW whatever. It would just use a passkey instead of a password. But the user would transparently gain the advantage of using key-based auth including domain binding, and not using a shared credit like a password.
So they’d be safe from phishing, and also if the site theyre visiting gets hacked, there’d be no shared credential, things like password reuse issues are completely removed. Which is great since it removes an attack vector the use has little control over.
Sure, I have passkeys stored in 1Password and working fine. And actually, you mostly need to use some manager for your passkeys, doesn’t matter whether that’s 1Password or your Google account.
What I’m wondering is what advantages do passkeys have for regular folks over the use of passwords stored in a password manager? And note that browsers these days are password managers that work for normies.
yeah to echo what
sunshowerssays below, phishing resistance. Password managers make phishing much more difficult, but only as UX guardrails – shared credentials like passwords and TOTP MFA are always fundamentally phishable. Domain-bound asymmetric crypto like passkeys aren’t. So in the scenario of someone with a browser password manager switching form password to passkeys, they’d go from phishing be difficult to being impossible. This also solves for password reuse. Anecdotally a lot of my non-engineer friends who use a password manager don’t let the password manager generate the password for them, which greatly reduces the effectiveness of a password manger, but this would solve for that.Also for most places they wouldn’t need to use MFA at all anymore, as the single factor of user-verified webauthn such as passkeys are generally considered more secure that password + TOTP/HOTP/push notification. TOTP MFA with a password manager isn’t to annoying but this would be a small reduction in friction.
Phishing resistance. Password managers add some friction to it but they’re not perfect. Passkeys use cryptography to make it impossible to be phished.
He’s not completely wrong with most of the topics, but fundamentally the only one I care about is that passkeys in the current form are just a terrible user experience for most people who are not either using iphone + macs or a single android device.
I have 3 different OSes on my m ain computers and an android phone. I don’t want my passwords to by synced by Google, if I can avoid it. I especially don’t want them synced to any MS Cloud and I actually trust Apple a bit more here, but not much.
If I were to accept passkeys I would need the following things:
Most “yay passkeys” pieces I have read so far assume I either never lose my phone, my phone never breaks, I don’t use Linux, or I want to sync my passkeys to someone else’s cloud.
And yes, losing access to my accounts is a much more real threat to me than someone stealing my long password.
Seems like Bitwarden might be of interest to you. I have had a pretty seamless experience storing and using my passkeys with it (across Linux and Android personally, and Windows for work).
You can also self-host a personal sync server if you don’t want to use theirs.
thanks for the pointer, I’v trialed vaultwarden in the past and I am not comfortable with it being exposed on the internet, or me having to run a VPN, and in general KeePass has worked out better for me.
I love passkeys as a second form of auth. GitHub did a great job with that. If my passkey is available then I sign in with a single tap on the touchid sensor or with FaceID. If not then I fall back to username/password/code.
On GitHub it is specially useful to have Passkeys to access sensitive settings. Like managing Teams & Collaborators just requires a quick tap to verify it is me.
I wish more websites did this.
No reason to fully dismiss passkeys. I think it was wrong to market them as full password replacements. I like to think of them as complimentary.
This. Probably coming from companies trying to lockin people and control things.
It’s too bad sqrl never got much traction
Hi. I have a masters degree from MIT and 30+ years experience in software engineering, including several deep dives into authentication technologies.
I cannot make passkeys work on my computer.
I use Windows, Android, Chrome, and 1Password. It’s all a confusing mess, even when I simplify to just Chrome+Windows. Sometimes a passkey works once to log in and not again. Most of the time they don’t work at all. Sometimes sites remember I tried to make a passkey once and it causes problems months later when I try to remember how to log in some other way than using the passkey I either lost or can’t access.
I’m just talking about basic stuff, can I log in? It does not work. Passkeys have joined OpenID in my mind as a complete product failure.
This is utter nonsense. The author has completely failed to understand the purpose of passkeys.
The entire point of passkeys is to get rid of passwords altogether. Password managers are a halfway house to secure authentication, and the fact that their password managers doesn’t support passkeys is a problem with their manager not knowing passkeys
But can a password manager know passkeys with the same usability as with passwords?
What I can do today, if I need to login into something from my wife’s computer, is to pop open bitwarden’s tab, enter my master password and copy-paste the password for the specific thing I need.
My understanding is that this is not really possible with passkeys: even if I store a passkey in Bitwarden, I can’t use it in an ad-hoc manner, I need to at least install a browser extension? Or is there some user-accessible flow where I can manually copy-paste the challenge and the response?
Of course, this whole thing with entering my master password into computer I do not own is icky security wise, but security is just the second most important feature of the password manager. The first one is me getting access to my stuff when I need it.
Yes, this is the attack vector that passkeys mitigate. Because you can, and people do, put this into a form controlled by an attacker. Passkeys make this impossible.
Either the browser builtin mechanism or a browser extension. I think Mac/iOS know directly which app is providing passkey support if not the OS internal.
No, because copy-pasting the challenge-response is literally the attack vector being prevented.
Anything you copy - from the site, your phone, or whatever - can be provided by the attacker, so if you could take that and get your passkey implementation to sign a response to that and paste that back you have provided a mechanism for an attacker to authenticate themselves as you.
The entire point of the passkey process is to prevent that attack, the authentication process is basically:
(1+3) mean that passkeys can’t be bypassed by a phishing site (phishing breaks autofill, but not manual fill like you’re suggesting)
(2) means that the attacker cannot control the data you’re signing
(4) means that the attacker cannot get your secret material
(5) the host can now confirm that the device performing the authentication is the device it is communicating with
the moment the you, the user, are copying content you lose all of this and you’ve reduced the security back to the level of passwords.
I too can make very secure systems if I ignore all the ways that people need and want to use these systems.
I found the very end of @matklad’s comment significant.
When push comes to shove, essentially everyone prioritises, let’s call them functional requirements, over security—and the tiny number of people who do not can be disregarded because they threw their computers into lava many years ago.
I think it’s fine for people to throw their computers into the lava. It’s not so great to roll out functionality to throw other people’s computers into the lava because you have a different opinion about security and the privilege to be able to roll your opinion out globally.
People forget that availability is part of security. If your only way to access a service is a passkey you can’t use, you can’t access your service.
Most people just want to press a button to log in, which is what passkeys allow, and do so more securely and robustly that passwords or password managers.
Yes it’s possible that for you the trade off for security is different than for other users, but saying “passkeys are bad because my trade offs permit reduced security properties in exchange for ease of new device logins” is not a reasonable position either.
To my knowledge no one is being forced to use passkeys, you’re perfectly able to use password+2fa wherever you would like, and other people can use passkeys - mostly I’m guessing due to the more streamlined login, but for me the strong security guarantees are the compelling part.
People are onboarded by what looks like a more convenient login but I (and they probably too) have no idea about the edge cases. What happens if they lose a device? No way to figure this out really without going through it.
Most people with serious security requirements seem to be using Yubikeys anyway. For most normal people passwords written in a paper book are the best solution, and critical digital logins backed by some national identity or notary scheme so they can retrieve their accounts in the case of loss.
(I just got locked out of an old Google account because I don’t have access to the 2FA phone number anymore. Let’s just say I’m glad there wasn’t really anything of value in there.)
That’s what the backup codes that Google prompts you to save in a secure place after setting up 2FA are for.
You don’t say! Thank you for the explanation.
It of course perfectly illustrates the failure modes of these systems and if I a CS graduate am bit by this, then for sure most normal people do not stand a chance.
Exactly. There is a reason why accessibility is part of the common understanding of security.
It’s too bad every large website implementing passkeys has figured out that you still have to support email-based self-service recovery to avoid a flood of support requests.
All of these protections are pointless if every passkey can be bypassed through email. Attackers have no problem walking users through recovery flows.
Suppose I have a site that I usually log into from my phone, but today I want to connect to it from a browser on my mother’s computer. Is that simply prohibited in the name of better security? Or is there a way I can accomplish it if there is no password, only a passkey.
That’s up to the site, you’re fundamentally in a position of doing a new device log in, so you’d presumably need a full 2fa dance, which they could permit via your signed in phone, or whatever other mechanism they choose. However they would still have to take steps to mitigate the risk of that being used as a phishing/social engineering attack (you basically start to run the risk of creating the kind “account recovery” style mechanism scammers use to compromise accounts).
It seems to me that there is an irreconcilable issue here: either a site allows some kind of account recovery (and “log in from my mother’s computer” is an example of “account recovery”), in which case there is a risk of it being used in a social engineering attack, or it does NOT allow any kind of account recovery, in which case accounts can’t be recovered.
What I would like to see is some enhanced forms of validation needed when doing “account recovery”. But that ends up meaning that I CANNOT “get rid of passwords and just use passkeys instead” (which is the promise) unless I also give up completely on having ways to recover an account.
Have to? Why is it the site’s responsibility to prevent technically illiterate users from giving their password to someone else?
Because it’s not just technically illiterate users? There are many attack vectors that are not trivial to identify and human brains are notoriously bad at reading/seeing what they expect to see. Yes of course there are people who are more gullible than others, but the security of your account should depend on more than just never ever making a mistake.
A better question there would be “why should be able to use your service securely be dependent on expert level understanding of attacks?”
If as you say the problem is just not being technically literate I’m curious if you avoid/ignore 2FA mechanisms, because those exist simply to try and provide some of the guarantees you get from passkeys. If it’s just a matter of technical literacy then it’s just an annoyance during log in.
Thanks for an explanation, it is helpful!
i’m struggling to see how transferable passkeys aren’t just isomorphic to passwords in a password manager.
i suppose with certain passkey schemes you could perform a challenge-response authentication over an unencrypted channel… but i’m not sure that’s desirable tbh.
Any “move from service A to service B” is going to involve a cryptographic exchange, e.g. service A would re-wrap the key material to a key provided by service B (this is the “don’t leak the unwrapped key material”). But I agree, my concern is that supporting that opens a vector for scammers to convince people to transfer their keys to an attacker controller application which obviously is not going to care too much about actually keeping the data secret, which is a significant reduction in the security against social engineering (in that it goes from being actually impossible to being at all possible).
It is still important to understand though that even with that obnoxious problem passkeys are still fundamentally different from passwords, the reason they’re set up the way they are is to prevent any kind of man in the middle or social engineering attack. They’re not just an HSM backed password manager (that’s a bare minimum requirement of any password manager), they’re cryptographic keys that allow authentication that also proves to a server that the client performing the authentication is the client it is talking to. That’s not something any password or password+2fa/totp authentication can do, and that’s a weakness that is constantly being exploited.
This is a legitimate concern, but I think the UI challenges are solvable. First, unlike copying and pasting a password, this is not going to be a common flow. People who are happy with a single vendor’s ecosystem will never use it and the flows between the big vendors are likely to be polished.
Even without multi-vendor support, the Apple flow is pretty good. You need to log into the new device with your Apple ID. This requires a password for bootstrapping but then requires a second factor p, which is typically another Apple device that tells you the device that you’re trying to log into and where it is. The latter is the biggest UI flaw because Apple’s geolocation is terrible and seems to be no more accurate than getting the correct country, but that should be fixable. You could also add a distance-bounding protocol over Bluetooth in here for the location-looks-wrong case.
This is a flow that users will do once when setting up a new device and can be flagged with ‘this is a new device setup thing, make sure that the target is your device, never let anyone else do this’ warning.
The bigger worry for me is coercion. If you have a person and their phone, forcing them to sync their passkeys to your device is quite easy. WebAuthn doesn’t seem to have a good revocation story for ‘this copy of my keys is a stolen one, please undo everything it’s done and lock it out’. Windows Hello has device-bound credentials, which carry the device identity with them so you can tell the difference between logins by the same user from different devices, but I believe that’s a non-standard extension.
isn’t this already handled by oauth? or am i misunderstanding what you mean here by “service”?
i’m really just struggling to see what “the point” is. it basically seem like making it slightly easier to follow good security practices at the cost of making it significantly harder to actually use services.
Yes, but I think entirely due to bad explanation on my part. It’s a skill :D
What I’m talking about here is the passkey provider, e.g apple’s keychain, googles , 1password, etc
Something people constantly complained about with passkeys was you create your passkeys with Service A (say keychain) and you can’t simply transfer that passkey to a different tool like 1password, what you had to do was create a new passkey with the new provider you wanted to use instead. For a couple of sites that’s not an issue, but if you were say just planning to transition to a new ecosystem and wanted to move all of your credentials over that’s a lot of work.
The thing is that the reason passkeys did not permit the extraction/transfer of the material is because scammers are exceptionally good at convincing their victims to do things, like telling the person on the phone what their 2fa token is, or installing software and giving that software excitingly elevated permissions.
Introducing the ability to export passkeys to another provider opens the previously non existence option of an attacker convincing their victim to install a piece of software and then export their passkeys to it, and in doing so provide all the material to the scammer.
No TLS does not resolve this kind of man in the middle, as this isn’t just about MiTM of a network connection, it MiTM of the authentication path. The user is convinced, by whatever mechanism, to open a scam page. The url is not the real website, but it is objectively true that users are bad at recognizing this. The scammers are forwarding the content of the real web page to the user of the fake url, the user enters there password in the fake page (sites are good enough at breaking password autofill that even users who are using password managers routinely fall for this), the scam page sends that back to attacker who uses that to log in. If the site has some form of 2FA, the scammer simply forwards that request to the victim, the user is expecting this, so still does not question the need and enters the code, which is forwarded to the scammer, who then has successfully compromised the account.
Passkeys tie the authentication to the actual identity of page being loaded on the authenticating machine, so this kind of MiTM simply does not work.
All the social engineering attacks targeting authentication revolve around getting the victim to provide their passwords and necessary 2FA tokens to the attacker, which only works because the passwords and 2fa tokens are not tied to the device or connection being authenticated.
These are the ways that scammers compromise accounts in the real world, and passkeys prevent them in a way that is fundamentally not possible via any other mechanism (in the sense of “this authentication model is the only way to prevent these kinds of attacks”, “passkeys” just happen to be the implementation+branding we have for the model).
Ah, this addresses my wondering why commenters are saying password managers are so insufficient. (I hadn’t personally encountered broken password autofill not being a reasonably reliable signal that one’s not talking to the right website.)
it’s super annoying, especially now so many sites have started breaking sign in pages into multiple steps, something that serves literally no purpose other than breaking automatic sign in and encouraging users to expect random page loads and page changes during sign in. Le sigh.
Still at least there’s fairly standard mechanisms for marking a password field so the autofill is actually possible, as opposed to the relentlessly stupid and brain dead password rules and restrictions that sites keep inventing, despite decades of research showing the outcome is worse passwords that are reused, and systematically selected. Mercifully NIST has finally updated their docs to say “stupid ass rules that prevent random passwords are stupid and you suck” :D
In my limited experience of websites with multi-stage sign-in pages, the Google Chrome password manager copes with them, even if it needs to have the user choose from the saved username/password pairs (if there are >1) at the username step and then again at the password step, which still keeps the passwords that the user is prompted to use limited to ones associated with the domain. I don’t doubt that there are worse sign-in pages with which I’m not familiar, though!
Oh yeah, I think they all manage it now, it’s just more work for the implementation (the site navigation and UI changes makes it much harder to link account and password fields). For autofill you have to approve the autofill multiple times, etc.
It literally just makes site login slower, password autofill more annoying to implement, and trains users to expect jank and weird page loads and refreshes scattered throughout a legitimate login.
It’s just a very weird and obnoxious decision by these sites.
It doesn’t if the username and password pages are served on separate random subdomains, which sso.duosecurity.com helpfully does for its customers.
Yes, but nobody uses client certificates, which would be the relevant equivalent part of TLS here.
As for social engineering: yeah, social engineers just have to go through the account recovery/new device enrollment flow.
But if you want to be able to share keys around and back them up without some third-party service (which may be niche requirements, but they are critical to me) then you need some form of serialized secret which is effectively a password. At that point you may make it user-readable and easy to type on a keyboard. Sure, I almost never do type it. But when I do need to it is invaluable.
Passkeys are not passwords that are being kept secret from you, they’re a cryptographic challenge/response process.
They’re not human typable because passkey authentication means signing a server provided nonce as proof of identity, and the server is able to verify that the machine doing the authentication is yours because an attacker is not able to get your machine to sign the data that the server has given them. I tried to summarize in my response here https://lobste.rs/s/2mgwsz/passwords_have_problems_passkeys_have#c_mp7x0o
I should have been more clear that I am talking about the storage format not the authentication protocol.
You can also do challenge response with passwords (ex: SRP, OPAQUE). My opinion is that upgrading the authentication protocol without moving away from passwords as a secret format would have been a better approach. Password managers can become more aggressive about warning users when displaying and exporting passwords (to prevent phishing and similar) but we don’t throw away the concept of passwords that is so simple to understand that my grandparents can back up their password manager into a notebook.
Basically I feel that we gave up so much for an improvement that could have been added to the simple system. With a PAKE and some UX you get basically all of the benefits of passkeys but users can still understand how it works to a degree that lets them do useful things like authenticate on a friend’s machine.
This seems like the core disagreement here: some view this as an important UX feature, and some consider this to be a security bug in need of prevention.
Both sides have their point! And it indeed seems that it’s not actually possible to automatically separate useful “your friend’s machine” from malicious fishing.
I wish someone has stated the tradeoff more explicitly here. It is clear what attacks are prevented. It is not completely clear which valid use-cases are prevented as a collateral damage.
The problem is less a disagreement but rather one side (the passkey side) trying to push their opinion onto the other side. I’m okay to have the option to use passkeys in addition to passwords. The passkey folks don’t seem to like it, they need to replace passwords.
I mean, in this very thread there are some comments that say that passkeys have no advantage over passwords in a password manager, and the article itself kinda-sorta claims the same.
Things are very rarely one-sided, even if it looks like that from a particular side!
Can you link to one of those comments?
DMed!
How does PAKE address the benefits of pass keys? I don’t think it does at all. You can MITM PAKE just as easily as any password, it’s just that the password doesn’t get leaked - the signed response does.
PAKE is great because the underlying secret never gets conveyed but it doesn’t address phishing. PAKE’s main benefit is that you don’t end up with “mypassword1234” scattered in your nginx logs or whatever.
Also, PAKE is not straightforward to implement on the server. I know that passkeys aren’t either, but I do just want to point out that it’s not simple. User signup becomes much trickier.
Ah ok, I think I understand what you were saying now, but to confirm, in essence passkeys perform authentication by
but you’re saying you’d prefer
which is fundamentally equivalent assuming the secret password has as much entropy as the cryptographic key.
Is that correct? At least as a general approximation?
Yes. I think you get my point.
Ok, in that case the issue just becomes the non-escaping nature of (the original) passkey model.
The reason for that mechanism is specifically to prevent scammers from being able to get people to provide the actual secret, because once you provide the secret to the attacker they can authenticate with the material the server provides their own connection.
The reason folk want a password, is because they want to be able access the secret, and in other words defeat the above.
I guess a good way to think about this is, how would it impact your opinion if the passwords from your password manager were just base64 encoded ECC keys?
I believe that you can only protect people from themselves so much. This is why I would rather make it a UX issue than add technical limitations and proprietary sync protocols. We can make the UX very aggressive about letting people know that they are doing something risky. (Or for corporate secrets actually block exporting).
If they were of a reasonable length then I would be fine with it. Honestly if a portable and reasonably human-manageable export format for passkeys was standardized would be pretty fine with the whole system. Maybe it will land some day, but I feel that this is a critical feature that should have been mandated from day one.
If there is a well understood, and effective, attack that works consistently, and you can simply make that attack not function why would you not?
right, so your issue is not the authentication scheme, which is superior to password based auth, its that you can’t simply extract the key material and use it directly yourself. Despite not being able to do any of the authentication yourself - it’s not an operation any person is doing in their head - and it means you’ve taken on the burden of verifying the host identity of the forms you’re reading and filling out (which is not necessarily the same as “what is the url the location bar shows”)
Because it’s at the expense of being able to do something useful (login on a device you do not own or where you haven’t synced your passkeys yet).
It’s at the expense of friction, not ability. You can still log in. If my phone is my passkey I can have my phone authorize me via, for example, a QR code.
Because there are downsides that are not worth it.
We can lock everyone in their own house to prevent murder, STDs and many other things. But it is not worth the tradeoff. We can force people to eat a regimented diet to prevent a huge number of illnesses. But that isn’t a world I want to live in. We should help people to the right thing, but at some point we need to give people freedom.
Really, it’s fine for me if the passwords from my password manager are just base64 encoded ECC keys. I just want to be able to use my choice of password manager, and sync its encrypted database file however I please. I’m not hugely concerned if there is a standard way for the browser and the password manager to communicate that’s not copy-and-paste, either. What I am concerned about is having my choice of password manager constrained to e.g. Apple or Google.
It isn‘t with Passkeys. 1Password implements them, and any other password manager can too. Apple, and I guess Google and Microsoft also, provide APIs to hook into both password autofill and passkeys for 3rd party managers to use.
Funny that he mentions 1Password, but disregards that it solves the exact problem of synchronizing your passkeys between devices. The real problem seems to be though that 1Password doesn’t integrate well with mobile web browsers for passkeys.
Edit: Looks like Android 14 is needed for passkey integration.
1Password is decent enough for use in mobile web browsers. Android started having support for autofill services, so hacks involving accessibility access and draw over are no longer required.
Scanning QR codes are not alien or cumbersome for users.
Hard disagree. As a Xennial, I would call it a toss up if someone of my generation understands QR codes or not. Gen X and above: not at all. If you find one that knows what a QR code is, it is hard to find someone who can actually scan them (at least with any reasonable speed). I can’t make claims for the generations after me.
I personally still don’t understand passkeys. I would much prefer it just said “Log in with my iPhone” or “Log in with my Samsung phone”. Passkeys limited to whatever computer you’re using at a time is a nightmare. I remain completely unclear whether I should allow Proton Pass to hold my passkeys, a Titan key to hold my passkeys or my iPhone to hold my passkeys. I think PP is the right choice, but security isn’t supposed to be a guessing game.
I think passkeys are not going to pass muster and will go away.
I feel like Whatsapp has proven that “scan a qr code for auth” is a pretty viable option.
I think the accent here is on “with a separate device”.
It’s kind of a pain to do if the other device is another desktop or laptop computer rather than a phone with a camera though.
You can invert the flow there and have the phone scan the QR code from the computer screen.
yeah… not sure how many dedicated PCs even have a webcam tbh.
I have never scanned a QR code and don’t see a reason ever do so.
The reason is as-stated. To authorize a device with a passkey.
Especially now that YouTube has changed the canonical URL for “Never Gonna Give You Up”, invalidating all the existing QR codes pointing to it.
While I agree that it’s tricky to implement passkeys correctly, if done right these kinds of user-facing issues can be solved very elegantly with great UX. In this example, when you go to the service’s login page on iPhone, you can have some client-side JS that detects that the user doesn’t have a passkey for the account, and show them a ‘log in with email’ screen. Once they log in with email, immediately redirect them to the ‘create a passkey’ page, show some wording that gets them to trigger the passkey creation, and have them set up the passkey. Then, next time they log into this service on iPhone, the same client-side JS detects the passkey and uses it automatically.
Yes, this can be a bit tricky to set up for the developer. But the good news is that someone just needs to implement this functionality once, preferably as a library or framework, or maybe as a SaaS.
How do you know which account the user is trying to access? The flow would look like this:
Example normal flow:
It’s honestly not even close and for security reasons, there are serious limitations on what you can and cannot do to improve the UX for webauthn. The user will always be shown the browser-defined prompt – we cannot change that flow.
You’ll never get a monopoly on this and many many devs are going to have to reimplement it.
Further, I’m not sure how many people have had to implement webuathn, but I have for a prod system and let me pile on the bandwagon: it absolutely sucks to implement. To be crystal clear here: webauthn requires a relying party (the domain of the site registering to), so when testing everything you must use HTTPS. There is an exception for localhost but that doesn’t fully test everything end-to-end! Everything can work perfectly with localhost but the second you deploy you can run into configuration issues (e.g. you have a dedicated auth service so RP cannot be origin). At some point, you need to test with an HTTPS site. And I know what you’re thinking, “just use ngrok or something like it for local development.” That would be great except “ngrok” is a public suffix and is rejected from being used with webauthn. And guess what happens when you try anyway? It just sends a generic, non-descript error. Seriously, webauthn sucks from a dev perspective when you need to test something end-to-end. You basically need a fully functional staging environment to test it.
Passwords and totp are 1000x easier than webauthn to implement and I’m not really sure what we gain from it beyond a “hardware password specific to the site” which I don’t even like!
Finally, you don’t even own the passkeys when using the default browser passkeys! Until they support import/export where I can transfer the certs wherever I want, I don’t own them. It’s overall very limiting, feels like a couple big companies are getting all the benefits while everyone else suffers.
You can phish passwords and totp.
i feel like trying to create a technical solution to social engineer is a mistake.
Trying to create a social engineering awareness solution is also a mistake imho, how much are we going to dump on the hands of the users?
Should we also stop teaching food safety, and instead mandate that all foods need to be sold pre-cooked?
People will always be exposed to various risks, and education is an important part of mitigating those risks.
It’s part of mitigating risks, but not the only or even most important parts. For example, we absolutely should regulate milk sales so that companies are allowed to legally sell only pasteurized milk, not raw milk. Even then, we know that some people will insist on drinking raw milk and we should try to spread awareness of the dangers of raw milk to those who might listen. But we should absolutely engineer food networks and systems that try to ensure that only pasteurized milk is available to the general public.
But we have done exactly that and it works great. Passkeys incorporate this but you don’t need passkeys for this - U2F/FIDO2 tokens work great too. This is a huge win.
Not only that, but technical solutions are the only way to solve social engineering issues by their very nature.
Got any source to back this up?? Every security specialist I’ve ever heard has said basically the exact opposite.
Well, I’m a security specialist, so I guess today’s a new day haha. In fact, I don’t really know anyone these days in the infosec world who isn’t in accordance with my statement but I’m sure they’re out there - maybe a dozen years ago it was the predominant view that we just needed more training for people, but that’s long been out of fashion.
The source is sort of just a straightforward examination of the issue. If the human is both the authorizing party and the vulnerable party, authority or vulnerably has to be addressed. Making humans invulnerable to social engineering is almost certainly intractable[0] so we need to have them not be the authorizing party, which means delegating that authorization to some sort of technical solution.
We can think of this in terms of privilege boundaries, perhaps. Consider an unprivileged process on a Linux system. The kernel authorizes that process when it performs system calls. If the kernel is vulnerable, the attacker can assume the authorization properties of the kernel. We can solve this by patching every vulnerability in the kernel or, as we typically do, we can create a new authority like a virtual machine that the kernel is bound by.
This is not to say that user education or user control don’t merit efforts, only to say that for a given authority the “best” way to improve its security is to delegate authority to smaller, less vulnerable, specialized components.
[0] A good example of this might be Jim Browning[1]. Jim Browning is an expert on scams. He actually actively “scams” scammers. I don’t know that there are many people who have spent quite so much time as Jim in terms of actively engaging with scammers, their techniques, their methodologies, psychologies, etc. And yet Jim Browning was scammed - he was tricked into having his entire Youtube channel taken over.
[1] https://en.wikipedia.org/wiki/Jim_Browning_(YouTuber)
[edited to note that totp/similar token based 2nd factor systems do nothing to mitigate any of the attacks that passkeys prevent]
I’m not sure I understand what you’re saying. The entire reason for passkeys existing is that they cannot be exploited in any of the myriad ways passwords are, and password managers do nothing to prevent any of these attacks. It seems like the issue is that you may not understand how passkeys work. The important part (from an authentication security PoV) is not that they’re held in an HSM (that’s just a requirement given the existence of malware) it’s the prevention of all of the myriad issues that password managers do not - and cannot - prevent:
Password managers do not prevent this.
Password managers solve two, and only two, problems:
TOTP and similar token based 2nd factor schemes make this harder, but fundamentally fail to the same set of MITM and social engineering attacks. TOTP and similar second factor attacks exist solely to mitigate the problems of password reuse and compromise, and are demonstrably bypassable by sufficiently motivated attackers.
Passkeys functionally wrap the 2nd factor into the core of the authentication process, and do so in a way that also cannot be MiTM’d by tying the authentication directly to the TLS connection with the host system.
It is unclear if you feel like you get some kind of value from having access to the raw/unwrapped key material, but it’s important to understand that the reason for that is that we have seen time and time again, that if there is a way to get someone - either the user themselves, or some variation of malware - to extract it then scammers are able to get that material from victims. By preventing the exposure of the unwrapped key material it is fundamentally not possible for an attacker to ever gain the ability to ever authenticate their own machine.
You are very much overcomplicating this. Read what I said carefully. When you go to a web page, you can have some client-side JS that detects any passkeys that you have stored that are tied to the domain, and automatically ask the user to log in with one of those. The user wouldn’t even need to enter their email address. This is called Conditional UI, see here: https://web.dev/articles/passkey-form-autofill
I get your point about testing, the only thing I can say to that is, you’ll need to set up a proper test environment with HTTPS instead of pushing directly to Prod 🤷♂️
Ah, I didn’t know you could use webauthn to select an account+passkey without first providing a username/email. That does seem better.
Thank you. Exactly how I feel.
Wait but if you support logging in with e-mail, what the hell is the point of the passkey? Just as optional extra tiny bit of convenience for people who don’t want to open their e-mail client when their session token expires? That’s not at all how they’re pitched though
If you support login with email but by default your UX flow guides users to automatically use passkeys as much as possible, then you are giving them an even easier auth experience than their usual ‘email’ login flow. Users will use your software not necessarily in the way that you intended for them, but in the path of least resistance. Make passkeys the path of least resistance and they will become users’ default flow.
If the backend supports several login methods, the attacker will simply choose the path of least resistance. If the user has reused bad passwords, then passkeys wont solve anything.