On Friday, December 15, 2017 at 4:06:02 PM UTC-6, Ryan Sleevi wrote: > It also perpetuates the myopic and flawed view as a phishing mitigation, > whose reliance is upon users checking it (again, user hostile), and > misleading both users and site operators into EV as a phishing mitigation, > when we do have more effective means that require less cognitive investment > by users and offer more reliable signals for sites (c.f. WebAuthN or > Credentials API)
I thought I was ready to stop responding to this thread, and then I read this and (I apologize but) I could not help myself. The notion that utilizing U2F/WebAuthN, etc., will stop phishing is.... risible. It completely ignores the on-boarding process. Certainly, I can envision the possibility that my bank has in-lobby enrollment kiosks, which utilize the same https origin as the retail website and which allow me to associate my hw credential to my account via a special captive portal there on the bank kiosk. That's theoretically how the future could evolve... Except no. They really are not going to do that. Probably ever. They don't need to and they will probably never need to, because they've already managed to push the risk to the user. Instead of that work flow, the user is at risk of being baited into entering all their personal information into a not_my_bank website which graciously enrolls their credential to no good ends (as this site won't even be there when the user comes back). Meanwhile, the user thought he was following a sane and normal on-boarding procedure. While on the topic of U2F/WebAuthN, it is noteworthy that current iterations effectively do not offer even a modicum of MITM protection. Assuming that one is able to get a bad certificate for the target website, the calculated auth token can be intercepted. I'm aware there are optional features which mitigate the MITM threat. These, of course, require protocol support inside the TLS endpoint and so will be pervasive...like good OCSP stapling support is, but with a deployment cycle that hasn't even started yet and a market penetration time-scale that might well be even worse. (As an aside, why did they not utilize the already in-browser and MITM-proof auth capability of TLS client certificates -- even if the token had to create a self-signed surrogate client certificate per origin to maintain anonymity -- all without needing new TLS bolt-ons?) You really, truly, can not absolve the user of a need for critical thought. We can merely help the user along. > Removing it will make some users sad. Those users are relying upon the UI > to guarantee the things the UI does not guarantee. Removing it will feel > like a guarantee has been removed. The guarantee never existed, so the > guarantee is not being removed. Except it sort of does guarantee, with reasonable limitations. That Stripe, Inc. [US] certificate that Ian got doesn't include a domain label for stripe.com, does it? The real stripe's web address is well known and obvious. This EV presentation may confuse, but it does not inspire confidence. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
