Paypal follow-up

Some people wonder whether the situation with PayPal is that bad.  Well, at least the phishing part is.  Today’s mail included this little gem from points unknown pretending to be PayPal:

Attention! Your PayPal account has been limited!

[…]

[Link to a phishing site]

This is the Last reminder to log in to PayPal as soon as possible. Once you log in, you will be provided with steps to restore your account access.

[…]

How did I know this was a forgery?  Let’s take a look at the email headers:

Return-Path: <paypal@service.com>
Received: from mail.realinterface.com (mail.cecreal.com [66.101.212.157])
	by upstairs.ofcourseimright.com with ESMTP id n9GAJ9h3022332
	for <lear@ofcourseimright.com>; Fri, 16 Oct 2009 12:19:31 +0200
Received: from dynamic.casa1-15-233-12-196.wanamaroc.com ([196.12.233.14]) by
         mail.realinterface.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 16 Oct 2009 06:32:45 -0400
From: "PayPal Services" <paypal@service.com>
To: "lear" <lear@ofcourseimright.com>
Subject: Your PayPal account has been Limited
Date: Fri, 16 Oct 2009 10:18:53 +0000
Organization: PayPal
MIME-Version: 1.0
Content-Type: multipart/alternative;
        boundary="----=_NextPart_000_0000_01C6527E.AE8904D0"
Message-ID: <RI1BvDvIMYk5XYA4IyF00002a42@mail.realinterface.com>
X-OriginalArrivalTime: 16 Oct 2009 10:32:45.0859 (UTC) FILETIME=[00099730:01CA4E4C]

The first thing we note is the From: line.  While this line can be easily forged, in this case, the miscreant forged not paypal’s domain but service.com‘s.  Well, that’s not PayPal.  This one was easy to establish as a fraud.  But had we any doubts we would need look no further than the previous two lines (the last Received: header).  If we look at the address 196.12.233.14, which is claimed to be dynamic.casa1-15-233-12-196.wanamaroc.com, we note that the name it has begins with “dynamic”.  That name, and the numbers that follow in it, indicate that this is probably someone’s house or office PC, and not paypal’s email server.  Note I’ve highlighted to “To” line, with the address lear@ofcourseimright.com.  But that is not the address I’ve given PayPal.

What’s more, I happen to have an actual paypal.com set of headers to compare against.  Here is what it looks like:

Return-Path: <payment@paypal.com>
Received: from mx1.phx.paypal.com (mx1.phx.paypal.com [66.211.168.231])
	by upstairs.ofcourseimright.com (8.14.3/8.14.3/Debian-6) with ESMTP id n9E8KIwI026171
	for <xxx@ofcourseimright.com>; Wed, 14 Oct 2009 10:20:39 +0200
Authentication-Results: upstairs.ofcourseimright.com; dkim=pass
	(1024-bit key; insecure key) header.i=service@paypal.ch;
	dkim-adsp=none (insecure policy)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=paypal.ch; i=service@paypal.ch; q=dns/txt; s=dkim;
  t=1255508439; x=1287044439;
  h=from:sender:reply-to:subject:date:message-id:to:cc:
   mime-version:content-transfer-encoding:content-id:
   content-description:resent-date:resent-from:resent-sender:
   resent-to:resent-cc:resent-message-id:in-reply-to:
   references:list-id:list-help:list-unsubscribe:
   list-subscribe:list-post:list-owner:list-archive;
  z=From:=20"service@paypal.ch"=20<service@paypal.ch>
   |Subject:=20Receipt=20for=20Your=20Payment=20to=XXX
   |Date:=20Wed,=2014=20Oct=202009=2001:20:17=20-0700|
   |Message-Id:=20<1255508417.22290@paypal.co
   m>|To:=20Eliot=20Lear=20<paypal@ofcourseimright.com>
   |MIME-Version:=201.0;
  bh=q82fwVBPBq26WHflKsNcdbCIf3Vcc5wRznZ9tfI8+8k=;
  b=OPyR7evc/VcnTZyDZSlYCh9oLm+vmKt8qsocqMrAr7y/kg3P5+DhO3mB
   UDbhkCvqu+owm45X1te+PxoREXR9aMEuuD20ltP2B5f5JWf/MjICk6zc6
   gYv6pY6ZRFKclXFGvtViJwv0LsW8N7uaoiZCAh5mxrjfuJaF+SmNyX23c
   I=;
Received: (qmail 22290 invoked by uid 99); 14 Oct 2009 08:20:17 -0000
Date: Wed, 14 Oct 2009 01:20:17 -0700
Message-Id: <1255508417.22290@paypal.com>
Subject: Receipt for Your Payment to XXXX
X-MaxCode-Template: email-receipt-xclick-payment
To: Eliot Lear <xxx@ofcourseimright.com>
From: "service@paypal.ch" <service@paypal.ch>
X-Email-Type-Id: PP120
X-XPT-XSL-Name: email_pimp/CH/en_US/xclick/ReceiptXClickPayment.xsl
Content-Type: multipart/alternative;
  boundary=--NextPart_048F8BC8A2197DE2036A
MIME-Version: 1.0

A few things to note: first, there my own mailer adds an Authentication-Results header, and in this case you see dkim=pass.  It’s done that by looking at the DKIM-Signature header to determine if Paypal really did send the email.  This is a strong authoritative check.  Knowing that PayPal does this makes me feel comfortable to discard just about any email from paypal.com that lacks this header.  Also, this email was addressed to the correct address (I’m not actually showing the address that I use).  Not every site uses dkim and that’s a pity.  One has to know in advance when to expect dkim=pass and one has to look at the headers to check.

Just by comparing email headers we can see that this is a poor forgery.  And yet it takes time and effort for people to determine just that.  And this is the risk that we consumers face.  If one decides that any email one wasn’t expecting from PayPal is in fact a forgery, then should someone break into one’s account, one may not notice that there is a problem.

Summarizing, here are the things that I’ve done to limit the chances of something bad happening:

  1. I use a single email address for PayPal that forgers are unlikely to know about.
  2. I look for the Authentication-Results header.
  3. Even if I think this is an authentic email, I will not click on links, but instead go to PayPal.com.

But it’s not all that easy for me.  It certainly isn’t easy for those who haven’t been paying attention to all of this stuff as part of their job.

The Saudis would like some handouts, please.

OilHere’s a rich idea reported by the New York Times: Pay oil producers for not producing oil.  That’s right.  Saudi Arabia wants “rich nations” to pay oil producers to help wean themselves from their dependency on oil.  That is- oil exports.  It’s just like paying farmers not to plant, right?  Wrong. In this case, oil producers still sell what the market demands, it’s just that since the market will be demanding less, OPEC and the like will get less.  According to the article, the Saudis have in the past gummed up the works on climate change protocols because of other nations’ refusal to accede to this sort of extortion.

Do the Saudis have a real problem?  Yes.  They and other large oil producers like Libya lack a sufficiently diversified economy, such that when oil prices dip, everyone suffers.  This is known as Dutch Disease, and oil exports are right to be worried about it.  Dutch disease happens because the demand of oil alone drives up national currencies, making all other industries in that country uncompetitive by price.

So here are a few questions:

  1. Can oil producers wean themselves off of oil without economic assistance?  After all, they’re taking in all of this money.  Can’t they use some of it to develop other industries?  It seems Dubai has been somewhat successful at this.
  2. Would economic assistance actually help?  If consuming countries gave them more money to compensate for losses of oil revenue, would producers just become dependent on the subsidy?
  3. Isn’t there a broader picture here surrounding to the West’s relationship to the Middle East?  Doesn’t good will count for anything?  And don’t we need some of that good will in that part of the world?

Dutch Disease requires complex solutions.  Simply providing a subsidy won’t do the job.  In fact, providing a subsidy could in fact prop up the national currency and compound problems.

And then there’s the fact that most of us feel as though we’ve been held over a barrel by some of the countries in question, and would like to have done with entanglements in the middle east.  Oil or no, however, the people in those countries are not going away.  They and we need an equitable way to live together in the future.

A lesson in transitive trust

CybercrimeGrowing up in the New York area in the 1970s, one never really paid attention to all the crime that occurred.  There just was so much of it.  Even when I lived in California, while a murder would make the local news, it wasn’t something that would shake the community.  A murder in the Zürich area, however, is rare.  Maybe it’s because everyone has a gun, as my friend Neal might say.  Who knows?  The point is that people here are not inured to that level of violence.

Now we are discovering the online version of that.  When last we left our situation, we were trying to figure out how best to protect ourselves from evil bad guys by limiting the damage dumb passwords can do.  Since then, it has been widely reported that 10,000 Hotmail account passwords were stolen.  But they weren’t the only ones.  Many of the people who use Hotmail accounts also have GMail and Yahoo! accounts, and many of those passwords are the same.  Why?  Because humans don’t like having to remember lots and lots of passwords.  And of course, if you were one of those people who used the same password between both and linked your Yahoo or GMail account to Facebook, that means that your Facebook account could have been compromised as well.  And that means that your friends may have been attacked, as we previously discussed.

How could this be worse?  Let’s add Paypal into the mix.  If you use the same password for eBay as you used for Yahoo!, now all of a sudden, you have invited someone to empty your bank account.  Had Paypal implemented an OpenID consumer for login, an attacker wouldn’t even need your password.

Now let’s aggregate all of the people who do that.  The popular OpenID providers include Google, Yahoo, and Verisign.  As the number of providers increases, the concentration of risk of any one single failure decreases.  Concentration of risk is a fancy way of saying that one is putting all of one’s egg in one basket.  On the other hand, from the perspective of a web site that uses OpenID or some other federated mechanism such as SAML, the information received from any random Identity Provider (IdP) could reasonably be considered suspect.

This leads to a few conclusions:

  • A large number of Identity Providers will require a service that provides some indication as to the reliability of the information returned by a given IdP.
  • The insurance and credit industries can’t manage concentrated risk.  We’ve seen what happens in the housing market.  The Internet can reproduce those conditions.  Hence, there will be limitations on transitive trust imposed.

Conveniently, you are not without any protection, nor are the banks.  There are large federated market places already out there.  Perhaps the two biggest are eBay and Amazon.  Amazon has the advantage of requiring a physical address to deliver to, for most goods, the exceptions being software, soft-copy books and downloadable movies.  In each of these cases, the transaction value tends to be fairly low, and the resale value of most of these items is 0.  It’s the resale value that’s important, because the miscreants in this business don’t want 150 copies of Quicken for themselves, nor can they really sell off an episode of House.

Paypal is another matter.  If someone has broken into your Paypal account, here is what they can do:

  • Empty it of any credit it might have;
  • Charge against your credit cards; and/or
  • Take money from your bank.

If you’re paying attention and act quickly, you might prevent some of these nasties from happening.  But first you will have to read a tome that is their agreement.  In all likelihood you have no recourse to whatever final decision they make.  If you’re not paying attention, your account and those associated with it become an excellent opportunity for money laundering.  What does it mean to pay attention?  It means that you are receiving and reading email from paypal.com.  That means that they have to have a current email address.  When was the last time you checked that they do?  Assuming that they do, it also means that you have to read what you are receiving.  Now- I don’t know about you, but I’ve been spammed to death by people claiming to be PayPal.  Remember, how this posted started by talking about being inured to crime?  Well, here we go again.

Can The Industry Stop break-ins on Facebook?

FacebookAfter my last post, a reasonable question is whether we in the industry have been goofing off on the job.  After all, how could it be that someone got their account broken into?  Everyone knows that passwords are a weak form of authentication.  Most enterprises won’t allow it for employee access, and we would string a bank CSO up by his or her toenails if a bank only used passwords to access your information. They use at a bear minimum RSA one time password tokens or perhaps Smart Cards.  So why are the rules different for Facebook?

They would say, I’m sure, that they do not hold the keys to your financial data.  Only that may not be true.  Have you entered credit card details into Facebook?  Then in that case maybe they do hold the keys to your financial data.  Even if you haven’t entered any financial data into Facebook?  Are you using the same password for Facebook that you are for your financial institution?  Many people are, and that is the problem.

Passwords have become, for want of a better term, an attractive nuisance.  It’s not that the concept itself is terrible, but they are increasingly difficult to secure, as the number of accounts that people hold continues to skyrocket.  Yes, the problem is getting worse, not better.  My favorite example is the latest update to the Wall Street Journal iPhone app, where the upgrade description says, “Application Enhancements to Add Free Registration & the Ability for Subscribers and Users to Login”.  What a lovely enhancement.  Right up there with enhancing the keyboard I am typing on to give me electric shocks.

Facebook is at least making a feeble attempt to get around this problem by offering OpenID access in some limited way (I tried using it from this site, and FB is broken, even though I can get into all sorts of other sites, including LiveJournal).  Still, it probably works for you if you are a Google, Yahoo!, or MySpace user, but for better or worse those sites themselves do not accept OpenID.  (The better part is that no one can simply break into one account and gain access to all of these other sites.  The worse part is that if you have some other OpenID, you can’t use it with these sites.)

OpenID has lots of problems, the biggest of which is that there is no standard privileged interface to the user.  This is something that Google, Yahoo!, and MySpace might actually like, because it means that they provide the interface they want to provide.  Unfortunately, programs, or more precisely the authors of programs, might find that a little irritating, since OpenID is so closely tied to the web that it is difficult to use for other applications (like email).

SAML and Higgins to the rescue?  OAUTH?  Blech.

There really is nothing Easy about EasyJet

easyJet.com

Dear friends Steve & Mary have returned from living in Australia, and so we will visit them in the UK.  To do this, I did my level best to try and find a cheap flight from Zürich.  “Cheap flight” and Zürich?  Say it isn’t so?!

It isn’t so.

EasyJet advertised a low fare on their web site.  Indeed it was fantastically low at CHF 312.27 for the three of us.  And so I clicked on buy.  But wait, not so fast.  First we had to turn down travel insurance for 71.85  CHF, and then we had to spend 108 CHF so we could check luggage (anyone with a kid checks luggage), bringing the total to 427.

But wait!  Want seats?  Forget it, but you can spend some extra bucks to get on the plane first.  We didn’t.

But wait!  That will be an extra 20 CHF for using your Mastercard over the web.  Only a certain Visa (not all Visas) get you a break on that.

But wait!  They didn’t even accept my Mastercard for reasons passing understanding (of myself or my card’s issuing bank).

So after all of that, we’re flying Swiss.  819 CHF, but at least we can book them.