On 10/3/2019 8:44 PM, Matt Palmer via dev-security-policy wrote:
On Thu, Oct 03, 2019 at 05:36:50PM -0700, Ronald Crane via dev-security-policy
wrote:
On 10/3/2019 2:09 PM, Ryan Sleevi via dev-security-policy wrote:
[snip]
I guess I wasn't specific enough. I am looking for a good study that
supports the proposition that the Internet community has (1) made a
concerted effort to ensure that there is only one authentic domain per
entity (or, at most, per entity-service, e.g, retail brokerage
services); and (2) has made a concerted effort to educate users to use
only that domain; and (3) that those steps have failed to significantly
reduce the successful phishing rate of the users that steps (1) and (2)
targeted.
Was it intentional to presume that (1) is correct or desirable? It’s
unclear if you believe it is, but if it isn’t (and for many reasons, it
isn’t), then naturally one might assume (2) and (3) don’t exist.
Yes, I do believe that (1) is desirable. It has a long history in the
context of brand identity (e.g., "Coke" in red and white script), where
virtually all consumers use it to identify authentic products and reject
counterfeits.
This is a valuable analogy, but I'm not sure how it advances the argument
you appear to be making.
To take the specific example you've provided, there is more than one product
made under the general brand of "Coke", most -- but not all -- involving the
word "Coke" in way or another. If we take the "domain name per product"
analogy, there would be a bunch of different "domains" for these products:
coke, newcoke, cocacolaclassic, dietcoke, cokezero, vanillacoke,
caffeinefreecoke, and so on.
That's before we start considering other products produced and marketed by
the same company under different names. There's a bunch of other carbonated
beverages, plus uncarbonated beverages, and even non-beverage foodstuffs,
that are all produced and/or marketed by the company that produces and
markets "Coke", at least in the country I'm from.
This is something of a nit, but my proposal is more along the lines of
"one domain per entity, or per entity-service", so in this case there
would be perhaps the single domain "cokedrinks.com", and paths or
subdomains for Coke Classic, New Coke, etc. Or, even better, the single
domain "coke.com" whose paths and/or subdomains house Coca-Cola's entire
product web presence.
...
Where the analogy breaks down is that in the case of phishing, people don't
typically try to "counterfeit" the domain name, merely "confuse"...
Agree.
Basically, many internet-based entities appear to have brought phishing upon
themselves by failing to extend the above to their internet presences.
Instead, they've trained their users to accept as authentic any domain that
has a passing resemblance to their rat's-nest of legitimate domains.
While there's a certain amount of truth to that, I think quite a lot of it
is users just not checking *anything* about the link they're clicking. The
amount of spam I get inviting me to login to various banking websites using
a link to yevgeniysflowershoppe.ua or the like would suggest that phishing
doesn't not absolutely rely on confusion. Your hypothesis relies on the
idea that users can be trained in any meaningful fashion, which the research
seems to not support at all.
Hmm. The idea that users are untrainable seems so foreign to me. One
reason is that, as I noted above, so many internet entities have been
training users to do the *wrong* things. It's not just rat's-nests of
legitimate domains. It's also non-ASCII-128 characters, thousand of
gTLDs, JS on-click handlers that make the link destination in the
browser's status bar unreliable, the app culture (e.g., install Joe's
Gas Station app today and get discounts!), and, unfortunately, even the
nature of hypertext itself (click, click, click, BOOM!). It's registrars
registering obvious phishing domains (are there no BRs for registrars?).
It's users running everything as root, mostly because they don't know
better. It's security bugs (ugh! I've reported >200 of these over the
past few years). It's caller-ID impersonation. It's....
To switch topics a bit, I am wondering whether a foundation-run
whitelist might help cut confusion-related phishing. This is not fleshed
out, but the basic idea that the user's browser tests domains against a
whitelist of domains that are known to be authentic. The foundation
running this project should prefill the whitelist with all
known-authentic domains. It should identify probable-phishing domains
(e.g., pretty much anything containing a string like "paypal" or
"facebook") and omit them from the whitelist unless it obtains
permission to include them from the appropriate administrative contact
for the authentic domain(s) that they're suspected of phishing. Domains
that do not appear to be phishing domains, and that don't appear in
major blacklists (e.g, GSB), should be added to the whitelist.
When the user attempts to navigate to a non-whitelisted domain, she gets
a blinking warning. She can proceed if she accepts the risk, as with
FF's site-cert-is-broken warning page.
Ideas?
-R
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
