spf-discuss
[Top] [All Lists]

Re: A hole in planned phishing-prevention?

2004-06-03 16:48:28
On Thu, 2004-06-03 at 18:20, David Brodbeck wrote:
On Thu, 3 Jun 2004, Daniel Quinlan wrote:

1. SPFv1 isn't intended to fix phishing, but someday a crypto addition
   like DomainKeys could do it.

Uhm...if it's not intended to fix spam, and it's not intended to fix
fogeries/phishing...what's the goal, exactly? ;)

It is intended to allow you to measure the authority of a certain mail
client to use a certain domain.  This doesn't fix spam, but it helps to
avoid someone impersonating example.com to avoid detection as
themselves.  Currently, if you impersonate example.com, example.com
takes the brunt of dealing with your questionable practices, with no way
to track you down.  If you want to send me a spam, then you have to do
it as yourself -- the end goal here is that blacklists, by IP and
domain, will be more useful, because the records that exist to measure a
domain's spam-quotient will be more accurate.

As far as fixing phishing, there is nothing stopping people from
registering bigbank-customerservice.com to attack people who have
bigbank.com accounts.  But it is then bigbank.com's responsibility to
let people know that they only send email from the bigbank.com domain,
enforce that policy within their own corporation, and it is the user's
responsibility to not trust something just because it matches
/.*bigbank.*/, or whatever policy bigbank wants to enforce.  And this is
where the law (or at least, interpretation of the law) hasn't caught up
yet -- it should be considered a serious crime to impersonate someone
with the intent to defraud using a similar domain name, but it should be
okay to register bigbanksucks.com without Big Bank getting all upset --
or at least more upset than if someone registers
bigbank-customerservice.com.  Unfortuantely, most people consider
critical opinions to be a bigger problem/threat than impersonation with
the intent to defraud.

This is the same problem with SSL and current browser practices for
https connections.  All the little padlock does is show that the cert
used to connect to bigbank-customerservice.com is assigned to
bigbank-customerservice.com, not that it's actually associated with Big
Bank proper.  This is a social problem though, and I'm not sure it has a
valid technical solution.  Making certificate validation easier for the
user won't do anything if the user can not be bothered to be aware of
the kinds of attacks they, and their accounts, could be exposed too.

I have a friend who doesn't like it when he gets asked to verify his
birthday when he calls his bank, or that his credit card company
contacts him to make sure he actually made a big purchase.  He says
"they already know that, why are they asking again!??!".  I recently
used a balance transfer check and the credit card company called me and
apologized for having to verify that I used them -- I told them I didn't
mind and WANT that service (she said it was good to hear someone say
that).

A couple of months ago, I had a run in with the customer service
department of a popular on-line banking service, because they used (an
unencrypted server at) surveymonkey.com to conduct a customer service
survey.  I told them that there was no way for someone to be sure that
this email about the survey they were sending their customers actually
came from them, and that they should try to integrate this survey with
the rest of their website, under their regular SSL cert, to afford at
least some measure of legitimacy.  I was told that it wasn't that big a
deal, because they weren't asking for any personal or account related
information, but this hardly solves the problem (these things don't
exist in a vacuum -- if they make a habit of using outside services to
conduct some of their business, people will come to expect that and
won't think it's that a big a deal when it happens as part of a phishing
scam).
-- 
Andy Bakun <spf(_at_)leave-it-to-grace(_dot_)com>