3 ms·

Nice find. To me it seems that WebauthN/PassKey was a significant project where all of the clever and highly paid engineers from the big corporations took part

Nice find. To me it seems that WebauthN/PassKey was a significant project where all of the clever and highly paid engineers from the big corporations took part. How can they overlook such an attack vector? Especially when the main selling point for the new technology is "resistance against phishing"? Even MS has in their FAQ: Are "Q: passkeys phishing resistant? A: Yes, passkeys are phishing resistant" [1] [1] https://support.microsoft.com/en-us/windows/passkeys-frequently-asked-questions-faq-0782c301-4b25-4a26-b7fd-3a7637d5fdd3 https://support.microsoft.com/en-us/windows/passkeys-frequen...

lxgr 2y ago
Security engineers aren't infallible. This is a really clever channel confusion attack that presumably just nobody considered. It happens, unfortunately.
- bflesch 2y ago
  Clever attack indeed - wouldn't have expected for this to be possible. I trusted the claims of Webauthn / Passkey being "phishing proof" without much consideration, because these claims came from highly respected companies. Unfortunately this is yet another example for "trust, but verify".
- sunshowers 2y ago
  I'm curious if folks tried to use a model checker. Seems like a model checker might be able to identify cases in the spec where invariants are violated.
  - lxgr 2y ago
    I don't think that that would have helped here: The invariant ("URLs purportedly resulting from a QR code scan must only result from an actual QR code scan") essentially follows directly from a specific threat scenario that was missed.
    - sunshowers 2y ago
      Yeah, you're right, that does seem to be very specific.
- 3np 2y ago
  Any professional should know this. Claiming any credential scheme is unphishable is not honest. Leading wider marketing with "phishing-resistant" is not far from that, knowing that the subtlety is lost on the public.
ajross 2y ago
> How can they overlook such an attack vector? Because secure engineering is extremely hard? That's two really quite uncharitable replies from you in this topic now, and IMHO it's really unwarranted. One of the worst smells for secure engineering is the insistence of the people involved that they'd never make a dumb mistake like "that other" group did. Basically nowhere is humility more of an asset than in this world.
- bflesch 2y ago
  I totally agree with you. That's why claiming your technology is "phishing proof" reflects badly on the people involved who are all supposedly experts in their field, and well-compensated on top.
  - lxgr 2y ago
    The protocol is; the implementations weren't, in this case. (To be fair, the specification didn't explicitly say "validate the origin of the pairing secret to actually be a QR code scanner", but that's still more of a missing (important!) implementation warning than a protocol design flaw.) Compare this with passwords, where the protocol is fundamentally phishable, with partial mitigations requiring user discipline (e.g. only ever using password manager auto-fill) and a lack of local or remote vulnerabilities.
  - WorldMaker 2y ago
    Most claims about Passkeys are "phishing resistant" not "phishing proof". This scenario is still more "resistant" than passwords: it requires a believable MITM proxy for a specific website that is also physically in someone's near-area network/personal-area network to pick up intentionally low powered Bluetooth LTE packets, and to click through a login flow that on most of these OSes/browser combos looks decidedly different ("remote login" instead of "real login"). Obviously that's still a threat model to consider, just as one should generally worry about logging into anything on a public Wifi, but the number of "ingredients" to get right on this phish attack is much higher than anything password related, and is much harder to scale (spearphish) because as amusing as it sounds to try to build a fleet of Raspberry Pis to blanket a public space it starts to get physically impractical. This is a "I'm going to phish a very specific person's wallet in meatspace" attack, not a "I'm going to remotely phish anyone on the internet's wallet". (It's also an attack we've already got mitigations rolled out in major browsers and more planned.)
0xbadcafebee 2y ago
The way things like this are developed is not by "clever and highly paid engineers". They're developed by a cabal of businesses led by a standards body to try and wrangle all the competing interests into one solution for everyone's problems (lol jk, it's to solve the problems of the most influential organizations involved). Because the whole process is design-by-committee on crack, the solutions don't tend to be technically very good. But they don't need to be, because they're not trying to solve a technical problem, they're trying to solve a business problem. The solutions they come up with are always ugly and broken at first, and don't account for all the needs of everyone (remember, only the most important's needs get met first), so they eventually churn out a fixed version and that becomes the version everyone ends up using long term. WebAuthn/Passkeys/FIDO/etc aren't even one solution or standard. They're a cobbled together patchwork of different pre-existing standards with some extra pixie dust mixed in. Almost everyone agrees that the users and implementers are who loses out when these things are pushed. But a couple giant businesses have an easier time solving their problems, which are large-scale security problems. And all the rest of us use it, because we tend to defer to large powerful authority figures, and we don't know what the hell else to do. Whatever universal solution is pushed will continue to suck balls, because there are too many different use cases, and no single solution will ever work well for all of them. What has worked, is working, and will continue to work, is to simply support a variety of different security mechanisms independently, and allow users to install a password manager which wrangles it all for them, across different use cases, sites, applications, devices, organizations, etc.
everybodyknows 2y ago
I'd also ask: Why can't MS explain them coherently? From just the first two FAQ items: > Passkeys are like digital keys ... But Joe User doesn't yet know what a "digital key" is, not yet anyway, so this is at best a forward reference. > The public key is registered with the website or application. Joe has no idea what "registered" means in this context.
- nolok 2y ago
  For the record, Joe has no idea what a public key is either
  - jmhammond 2y ago
    Microsoft is using “like” in this case to be a simile. The passkey is being compared to a digital version of a physical key, the brass object used to unlock doors.
ziddoap 2y ago
>Even MS has in their FAQ: Are "Q: passkeys phishing resistant? A: Yes, passkeys are phishing resistant" [1] Phishing resistant is different than phishing proof. Passkeys remain phishing resistant, even in light of such an attack.
- AStonesThrow 2y ago
  I don't know about today, but in the 1980s, "water resistant" for wristwatches meant that you could wash your car and the hose-spray wouldn't turn it into a brick. Can today's "water resistant" smartphone be dropped into a swimming pool with no ill effects? I don't know. But "resistance" as a marketing term is often far overblown, even with strict product standards in place, and for cryptography/authentication there is zero consumer protection or transparency. Any accountability for service providers is usually lip service anyway. Read your software licenses: there are no warranties, for any purpose, ever.
wkat4242 2y ago
They say phishing resistant. They don't say phishing proof. And this is not an easy thing to exploit.

lxgr 2y ago

Security engineers aren't infallible. This is a really clever channel confusion attack that presumably just nobody considered. It happens, unfortunately.

bflesch 2y ago
Clever attack indeed - wouldn't have expected for this to be possible. I trusted the claims of Webauthn / Passkey being "phishing proof" without much consideration, because these claims came from highly respected companies. Unfortunately this is yet another example for "trust, but verify".
sunshowers 2y ago
I'm curious if folks tried to use a model checker. Seems like a model checker might be able to identify cases in the spec where invariants are violated.
- lxgr 2y ago
  I don't think that that would have helped here: The invariant ("URLs purportedly resulting from a QR code scan must only result from an actual QR code scan") essentially follows directly from a specific threat scenario that was missed.
  - sunshowers 2y ago
    Yeah, you're right, that does seem to be very specific.
3np 2y ago
Any professional should know this. Claiming any credential scheme is unphishable is not honest. Leading wider marketing with "phishing-resistant" is not far from that, knowing that the subtlety is lost on the public.

ajross 2y ago

> How can they overlook such an attack vector? Because secure engineering is extremely hard? That's two really quite uncharitable replies from you in this topic now, and IMHO it's really unwarranted. One of the worst smells for secure engineering is the insistence of the people involved that they'd never make a dumb mistake like "that other" group did. Basically nowhere is humility more of an asset than in this world.

bflesch 2y ago
I totally agree with you. That's why claiming your technology is "phishing proof" reflects badly on the people involved who are all supposedly experts in their field, and well-compensated on top.
- lxgr 2y ago
  The protocol is; the implementations weren't, in this case. (To be fair, the specification didn't explicitly say "validate the origin of the pairing secret to actually be a QR code scanner", but that's still more of a missing (important!) implementation warning than a protocol design flaw.) Compare this with passwords, where the protocol is fundamentally phishable, with partial mitigations requiring user discipline (e.g. only ever using password manager auto-fill) and a lack of local or remote vulnerabilities.
- WorldMaker 2y ago
  Most claims about Passkeys are "phishing resistant" not "phishing proof". This scenario is still more "resistant" than passwords: it requires a believable MITM proxy for a specific website that is also physically in someone's near-area network/personal-area network to pick up intentionally low powered Bluetooth LTE packets, and to click through a login flow that on most of these OSes/browser combos looks decidedly different ("remote login" instead of "real login"). Obviously that's still a threat model to consider, just as one should generally worry about logging into anything on a public Wifi, but the number of "ingredients" to get right on this phish attack is much higher than anything password related, and is much harder to scale (spearphish) because as amusing as it sounds to try to build a fleet of Raspberry Pis to blanket a public space it starts to get physically impractical. This is a "I'm going to phish a very specific person's wallet in meatspace" attack, not a "I'm going to remotely phish anyone on the internet's wallet". (It's also an attack we've already got mitigations rolled out in major browsers and more planned.)

0xbadcafebee 2y ago

The way things like this are developed is not by "clever and highly paid engineers". They're developed by a cabal of businesses led by a standards body to try and wrangle all the competing interests into one solution for everyone's problems (lol jk, it's to solve the problems of the most influential organizations involved). Because the whole process is design-by-committee on crack, the solutions don't tend to be technically very good. But they don't need to be, because they're not trying to solve a technical problem, they're trying to solve a business problem. The solutions they come up with are always ugly and broken at first, and don't account for all the needs of everyone (remember, only the most important's needs get met first), so they eventually churn out a fixed version and that becomes the version everyone ends up using long term. WebAuthn/Passkeys/FIDO/etc aren't even one solution or standard. They're a cobbled together patchwork of different pre-existing standards with some extra pixie dust mixed in. Almost everyone agrees that the users and implementers are who loses out when these things are pushed. But a couple giant businesses have an easier time solving their problems, which are large-scale security problems. And all the rest of us use it, because we tend to defer to large powerful authority figures, and we don't know what the hell else to do. Whatever universal solution is pushed will continue to suck balls, because there are too many different use cases, and no single solution will ever work well for all of them. What has worked, is working, and will continue to work, is to simply support a variety of different security mechanisms independently, and allow users to install a password manager which wrangles it all for them, across different use cases, sites, applications, devices, organizations, etc.

everybodyknows 2y ago

I'd also ask: Why can't MS explain them coherently? From just the first two FAQ items: > Passkeys are like digital keys ... But Joe User doesn't yet know what a "digital key" is, not yet anyway, so this is at best a forward reference. > The public key is registered with the website or application. Joe has no idea what "registered" means in this context.

nolok 2y ago
For the record, Joe has no idea what a public key is either
- jmhammond 2y ago
  Microsoft is using “like” in this case to be a simile. The passkey is being compared to a digital version of a physical key, the brass object used to unlock doors.

ziddoap 2y ago

>Even MS has in their FAQ: Are "Q: passkeys phishing resistant? A: Yes, passkeys are phishing resistant" [1] Phishing resistant is different than phishing proof. Passkeys remain phishing resistant, even in light of such an attack.

AStonesThrow 2y ago
I don't know about today, but in the 1980s, "water resistant" for wristwatches meant that you could wash your car and the hose-spray wouldn't turn it into a brick. Can today's "water resistant" smartphone be dropped into a swimming pool with no ill effects? I don't know. But "resistance" as a marketing term is often far overblown, even with strict product standards in place, and for cryptography/authentication there is zero consumer protection or transparency. Any accountability for service providers is usually lip service anyway. Read your software licenses: there are no warranties, for any purpose, ever.

wkat4242 2y ago

They say phishing resistant. They don't say phishing proof. And this is not an easy thing to exploit.