On Fri, Dec 15, 2017 at 5:38 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> 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. That is not what is required. There is no special enrollment dance - that is simply straight up misrepresenting it. Your vision is not aligned with the reality of it. While on the topic of U2F/WebAuthN, it is noteworthy that current > iterations effectively do not offer even a modicum of MITM protection. That is not correct. 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. This is both technically inaccurate and not relevant to the discussion of phishing. It borderlines bad faith to non-sequitor like that - as an attempt to shift the discussion and goals to avoid having to acknowledge the points made. > > (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?) I find it very difficult, in this context and this thread, and with the pejoratives used, to believe this is a good faith question, but it certainly is not productive. You can certainly ask on the WebAuthN discussion, in which I’m sure folks would be more than happy to point out the misunderstanding that underscores the question. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
