One sometimes neglected issue connected with Internet security and privacy is the degree to which unencrypted URLs should be used to carry personal information. I’ve seen it frequently in unsubscribe links on email circulars: rather than having a unique user identifier, the user’s email address appears in the clear. This is okay if you’re at home and you only share your router with people you trust, but it’s a privacy risk if you’re using shared wifi, say at a cafe. Thus this is bad practice:
http://mail.exampleonlineshop.co.uk/unsubscribe?address=john.smith@example.com
And this is good practise:
http://mail.exampleonlineshop.co.uk/unsubscribe?id=e7902fecd2dcb1b28917bbca62ab4bc7
Let us assume this link is being accessed by the intended recipient in an Internet cafe. In both cases the cafe owner (or another wifi user running appropriate software) can see the web addresses that are being visited, but only the first one reveals personal information (namely, the email address and full name of the user). I classify this example as a privacy risk rather than a security risk, since having a person’s name and email address is not in itself usually enough to carry out identity fraud or compromise a person’s computer security. However, I think the second form is better, since it is very easy to achieve, and encourages the use and promotion of good practice even for trivial cases.
It is therefore worrying that this approach to thinking about security isn’t pervasive at Barclaycard, whose treatment of privacy and security needs to be exemplary for obvious reasons. I recently received from them an online statement via email, containing the customary text and html parts, plus a ‘view in browser’ link. That latter link looks like this:
http://mail.barclaycard.co.uk/a/hYI-$bksVvkJ8NKhjvjvUxJpBhjhkqqlq/hostedhtml?t_params=CUST_FIRSTNAME%3DJohn%26 PRODUCT_NAME%3DBarclaycard%2520VISA%26 LAST4DIGITS%3D6821%26 STATEMENT_AMOUNT%3D%25A3156.99%26 MINIMUM_PAYMENT%3D%25A356.43%26 DUE_DATE%3D20%2120Feb%252012%26 EMAIL%3Djohn.smith%2540example.com%26STATEMENT_DATE%3D26%2120Jan%252012
There’s a bit of trivial character encoding in there, but essentially it contains this information:
- First name
- Credit card type
- Last four digits of card
- Statement amount
- Minimum payment
- Bill due date
- Email address (and thus, in most cases, full name)
- Bill statement date
So, if I’d accessed that link via public wifi, all of that information is made available to whoever runs that network, or whoever uses that network and knows how to look. Users cannot trust all of those people, and moreover they shouldn’t have to worry about this stuff either. To be fair, there’s not enough information in that URL to mount a successful social engineering attack; one would probably need the full credit card number and a postal address, and perhaps even knowledge of recent purchases. But financial institutions simply should not be making this sort of information available when it is trivial to do it in another way.
Barclaycard have three obvious solutions available to them:
- https://mail.barclaycard.co.uk/a/hYI-$bksVvkJ8NKhjvjvUxJpBhjhkqqlq/hostedhtml?t_params= (same as before)
- https://mail.barclaycard.co.uk/a/hYI-$bksVvkJ8NKhjvjvUxJpBhjhkqqlq
- Don’t have a browser-based link at all
In the first two approaches, I suggest that Barclaycard uses an encrypted session; for a bank the extra cost is trivial. In the first case, the browser-based email can read the user parameters in the same way as before, but it is now encrypted and thus is unavailable to network operators and network sniffers.
The second option offers the same level of security as the first, but requires the server to access a database of emails on a per-customer basis, rather than dynamically building each email. This may raise costs higher than the risk warrants, but does make for a URI less likely to break in text-based clients.
In some cases, a non-encrypted version of (2) is acceptable, so long as clicking it does not return a browser page containing the personal information anyway (the unsubscribe example comes to mind). But in the Barclaycard case, all of the personal data is to be rendered to the screen without further authentication, making SSL a necessary part of the solution. Of course, the last option may be the best option: what sort of mail client these days would be unable to render at least the text part of an email anyway?
Out of interest, I tried accessing the Barclaycard mail server via SSL (here), and the resulting invalid-cert warning revealed that it belongs to a third party firm, chtah.com. That domain is owned by Experian CheetahMail, who, I expect, are contracted to do email sending on behalf of Barclaycard. So I’d wager that this is a minor security analysis gap regarding a third-party provider, which should be fixed after a gentle prompting. We’ll see!
Updates
29 Jan 2012: paradoxically, BC’s contact form is far too fastidious. Since it won’t accept colons or forward slashes in the message body – err!? – I’ve not been able to cross-ref this post.
30 Jan 2012: received an email undertaking to “inform the relevant department” – we’ll see if that comes to anything.
29 Dec 2012: was it the result of my contacting them, or just an upgrade? Barclaycard message URLs now appear in a much better form:
http://mail.barclaycard.co.uk/a/aCDbL9JEDanK8Na9a4dMqWs96.CBukSHWf/login
Success!