Re: Unicode domain names issue (Encrypting a "fake" domain name)

This thread is very focused on what's the right algorithm for preventing
homoglyph attacks. But why do we care about homoglyphs? Because they make
phishing for credentials easier.

But do homoglyphs need unique handling vs, other phishing attacks? First,
it's clear that homoglyphs are not a necessary component of a phishing
attack, facebook-com.nonsense.biz is also an effective strategy for
phishers. Homoglyphs are particularly scary to us though, because no amount
of training or vigilance on the part of users will work, we must have a
machine solution.

Given that, what machine solutions do we have for _all_ phishing attacks.

- There's ongoing work to implement U2F, to provide phishing-proof
credentials
- We use Google's SafeBrowsing API to check for known phishing sites.
- Probably there's lots of other things we already do that I don't even
realize!

But I agree with those who've argued for "the buck stops here" -- if
there's more we can do, we must, because even if registrars prevent
homoglyph there's 1001 other effective phishing techniques that need to be
stopped.

- Are there clever clientside algorithms we can use to detect phishing
websites above what SafeBrowsing gives us?
- Should the UI surface "this is your first time visiting this website"?

There's probably other good ideas out there.

Cheers,
Alex

On Fri, Apr 21, 2017 at 2:42 PM, Kyle Hamilton <[email protected]> wrote:

> The idea may be a variant, but it's by no means the same as what has
> been presented there.
>
> In the instant case, the font used in the address bar uses the same
> glyph shapes for both Latin and Cyrillic.  Might it be appropriate to
> use (and provide) a font that uses different glyphs for every
> confusable code point, and then provide some kind of user training on
> how if the shapes don't match what they're used to it might be
> phishing?  This would be demonstrably script-neutral.
>
> The downside is that it would unduly burden users whose
> shape-recognition is sub-par, but pretty much every other idea for
> protecting the users has been shot down by Mozilla reps on this list.
> I'm sorry, but this is not "somebody else's problem".  The users use
> your software, and you are the only ones they can hope to save them
> from threats that others refuse to take responsibility for.
>
> Mozilla has always claimed that it's focused on user security.  If
> you're enforcing the rule "if it works on one Firefox, it works on all
> Firefoxes" (in the context of "IDN owners might not use IDN if IDN
> doesn't work everywhere") to the detriment of user security and
> increasing phishability, are you really focused on user security?  Why
> is IDN display a sacred cow, when it increases the risk for your users
> to be scammed?  IDN owners don't apparently provide mindshare to
> Mozilla, nor contribute to the installed base.
>
> Mozilla reps on this list have tried to push the problem off on
> everyone else -- the registrars (of which a subset refuse to accept
> the responsibility, and cannot be compelled to do so), and the users
> who have no means to differentiate in the scripts (because IDN owners
> can't abide uncertainty).  For some reason, though, you're not trying
> to push the problem off onto the IDN owners who, as web site owners,
> already have to deal with the uncertainty of their users using
> whatever browsers with whatever security policies baked in that they
> choose to.
>
> -Kyle H
>
>
> On Fri, Apr 21, 2017 at 3:28 AM, Gervase Markham <[email protected]> wrote:
> > On 21/04/17 02:36, Kyle Hamilton wrote:
> >> Perhaps, only display non-punycode from codepoint sets used in
> >> languages already installed on the computer?
> >
> > Before we do another canter through the six different ideas that always
> > occur to people when first presented with this issue, the very unofficial
> > https://wiki.mozilla.org/Gerv%27s_IDN_Display_Algorithm_FAQ
> > might help shortcut the process. In this case, questions 7-9 are
> > relevant, as your proposal is a variant of the one those address.
> >
> > Gerv
> >
> _______________________________________________
> dev-security mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security
>