It's that time of year - time to renew car tax. I figured I'd give the monthly direct debit a go and see whether paying the extra little bit is worth avoiding the yearly pain of remembering you need to find a few hundred quid up front.
For anyone who's not used it yet, the process of setting up is smooth and easy (in an almost distinctly non-government IT way), unfortunately it turns out there's a fairly big issue with the final step.
I should be fair, and point out that the service is provided by DirectGov rather than the DVLA directly, but IMHO it remains the DVLA's responsibility.
Don't email me that!
Once you've provided your details, and confirmed anything, you're told you'll receive an email confirming your purchase (and reminded that they won't be sending a tax disc).
That email arrived, fairly quickly containing the following (details changed)
Thank you for arranging to pay the vehicle tax for GH43ABC by Direct Debit.
Please can you check that the details below including your payment schedule are correct:
If any of the above details are incorrect please call us as soon as possible on 0300 790 6802. We are open 8am to 7pm Monday to Friday and 8am to 2pm on Saturday.
- Account name: MR B TASKER
- Account number: ****5678
- Bank sort code: 41-19-32
We'll come to why it's dangerous in a minute, but let's start with why it's a pointless an un-necessary release of my banking details.
Firstly, during the setup process, you are already given a page to review the information that you entered - so you've already checked it.
Even if that wasn't true, there's very little value in asking me to verify redacted data. If my account number was 12345678 and I'd entered 98765678, the 'mistake' is redacted and so can't be verified.
So before we even get onto the consequences of emailing this data, it's obvious that the reasoning for sending the data is flawed. They've obviously put some thought into it, given that they've redacted part of the account number, but don't seem to have followed that thought process through to it's logical conclusion.
Email is not a secure medium
Amazingly, this is still news to some, but email is not a secure transmission medium. Every relay between the sender and my mailbox can read (and copy) the contents of that email.
Depending on the configuration of those relays, someone listening on a network link between two relays can also do the same. Whether or not any intermediate relays use TLS for their connections is pretty beyond the control of both the sender and the recipient.
So the details above could have been copied by unknown persons, and neither I, nor the DVLA, would have any way of knowing.
Third Party Providers
From the email headers, we can see that they've opted to use Amazon's Simple Email Service to send their mail
Received: from a6-147.smtp-out.eu-west-1.amazonses.com (a6-147.smtp-out.eu-west-1.amazonses.com. [220.127.116.11])
So, thanks, DVLA - you've just sent a UK Taxpayer's financial details through a US providers system without any advance warning. The datacentre may be in the EU, but the US Government has already made it clear they don't really give a damn about little things like territoriality.
A number of people are, for very good reason, trying to avoid having their personal information go anywhere near US based providers, yet the DVLA is quite happily sending data there for them.
But the Information's Redacted
We'll come back to this in a bit more detail shortly, but it seems worth touching on - what use is 4 digits of an 8 digit account number?
It's a fair question, but largely ignores the fact that redacted data can often be correlated against other sources to fill in the gaps. There is no 'industry standard' on redacting details, and everyone seems to do it differently.
The DVLA have gone with redacting the first four digits, others choose to redact the last 4 (for example, T-Mobile used to ask you the last 4 characters to confirm your identity).
There are 14 digits to a sortcode and account number, and the DVLA have disclosed 10 of them with no guarantee that other providers aren't redacting other elements instead.
Now this, obviously, isn't the DVLA's fault - but it is something that should have been taken into consideration.
I have in the past, had debit cards (may have been Switch, can't remember) where the provider felt the following schema was a wise way to create the card number
[card type prefix] [sortcode][account number]
e.g. 4659 41193212345678
So if the user has one of these cards, the DVLA has also just emailed a substantial proportion of their card number to them, in clear text.
I've already mentioned T-Mobile's previous 'authentication' policies, but they aren't the only one.
Apple have been quite publicly identified as using some pretty poor authentication policies in the past (though you'd hope they've now changed that). The problem is that different providers consider different parts of bank details and card numbers as sufficiently 'secret'.
Banking Details in my Inbox
I may, quite reasonably, want to keep a copy of the confirmation email so that I can show I set up my tax payments if the DVLA ever 'forgets'.
The problem with that, now, is that if anyone were ever to compromise my mailbox, those banking details are now sat waiting as an extra bonus for them.
I've tried to keep this concise, but it's well known that data can easily be correlated against other sources in order to try and identify the contents of redacted elements - so a theoretical attacker may well not need to try 9999 combinations in order to find out the first 4 characters.
They may, in fact, not even need to try - never, ever, underestimate the power of social engineering. The email above gives an attacker 10 numbers which can be potentially be used to 'authenticate', especially if they can reach a sympathetic customer service adviser.
Whilst the details above may not give them access to my bank account, they could quite conceivably be used to gain access to other services. In an article similar to the Gawker article linked above, access was gained to the target's DNS management account and then used to extort the target into giving up their Twitter handle.
Whilst it might seem far fetched that any of this could happen - ask yourself this:
Given that the email cannot serve it's stated purpose (you cannot verify the redacted section) why take the risk by emailing those details out in the first place?