6 ms·

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

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

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