Ask Slashdot: Why Do Firms Leak Personal Details In Plain Text? 252
An anonymous reader writes "Having entered my personal details (full real name, home address) to websites with an 'https://' prefix in order to purchase goods, I am still being sent emails from companies (or their agents) which include, in plain text, those same details I have entered over a secure connection. These are often companies which are very keen to tell you how much they value your privacy and how they will not pass your details on to third parties. What recourse does one have to tell them to desist from such behaviour whilst still doing business with them if their products are otherwise desirable? I email the relevant IT team as a matter of course to tell them it's not appropriate (mostly to no avail), but is there any legislation — in any territory — which addresses this?"
depends (Score:5, Interesting)
Re:Name and address? (Score:5, Interesting)
I am sure that the incredible fucktards at Air China who sent recently sent me a flight confirmation would like to know that.
It contained my full legal name, home address, and phone numbers. This does not bother me so much, as this is Sweden where most information of this sort is considered public knowledge. Want to know how much my flat is worth and what I paid for it? Did I pay taxes last year, and if so, how much? Feel free to hop on over to Skatteverket and file an info request.
The email also contained this:
Identifying document: US Passport
Identifying document number: #XXXXXX
Identifying document valid until: xxxx2020
Until 3 days ago, as I have not yet actually used this passport for travel, the only people on Earth who knew this number were me, the US Dept of State, and the Swedish Migration Bureau. Now who the fuck knows. Who THE FUCK knows.
And my girlfriend cannot understand why I threw a fit over this, or why I am talking about legal options.
Re:depends (Score:5, Interesting)
In the words of Tweak Tweak: "Uh... It's easy?"
Re:Name and address? (Score:5, Interesting)
The Government could fix the whole SSN issue by doing something direct and simple.
Publish all SSN's in a big directory.
They were never intended to be 'secret numbers' that would be used to validate anybody's identity. They were registration numbers for the Social Security System.
Publishing them ALL would force businesses and organizations to come up with real 'secure identifiers.'
Re:depends (Score:5, Interesting)
For most Security Leak issues, it comes down to a simpler problem.
Most people have crappy computer skills.
You can have a perfect system, but it takes one guy from sales or marketing to take the data, dump it as an excel of csv file and just email it or drop it in a public space because he just doesn't want to be bothered by dealing with IT
XKCD [xkcd.com] kinda shows this problem. We still don't have a good way to transfer files with people on different network. We have the technology but no clear standard.
Re:https does not mean they are stored encrypted (Score:5, Interesting)
It's opportunist encryption, which is worse than worthless, as it gives a false sense of security. All you need to defeat this encryption is to interfere in any way with the encrypted connection, SMTP is required to deliver the mail in plain text.
GPG is not a real solution as even no one among technically minded people I know uses it for encryption. Signatures, yes, especially in Debian where around 50% of posts on mailining lists are signed, but, I recall exactly one case when a piece of sensitive data I received was GPG encrypted.
But. an easy solution does exist: DANE. It's the only way to make that opportunist encryption mandatory (servers are required to abort delivery in face of failure), and DNSSEC prevents DANE settings from being stripped away by an attacker. Obviously, you need stapled certificates rather than mere CA selection, but that's common sense. With that, server->server and possibly client->server communication is secure, and when IMAP is protected by DANE, server->client as well. Local storage remains in plain text which is an obvious problem, but at least that is outside the topic of this discussion.
The problem is, I'm not aware of any mail software that actually uses DANE yet :(
Re:HTTPS means something specific (Score:5, Interesting)
Interestingly enough, several Swiss banks do. My bank, PostFinance (the bank run by the Swiss post office) uses S/MIME to sign all outgoing mail, including their periodic newsletter. No confidential content is ever sent via email -- users are directed to login to the (https-enabled) website to view the sensitive information. All PDFs, such as account statements, are digitally signed and timestamped by a third-party timestamping service to prove their authenticity.
It's nice to see *someone* getting it right.
Re:HTTPS means something specific (Score:5, Interesting)
Interestingly enough, several Swiss banks do.
Swiss banks must be decidedly more clueful than British ones then. Most of the British banks seem to think that putting some easilly obtainable PII in a plain text email allows you to authenticate it.
A few years ago, the Nationwide took to sending me marketing email that:
1. Came from a domain other than nationwide.co.uk.
2. Included web links to their product descriptions, but also not at nationwide.co.uk (can't remember the exact domain, probably something like nationwidebanking.co.uk or nationwideonline.co.uk - either way, something that could easilly have been registered by a third party.
3. Included the first half of my post code.
4. Wasn't electronically signed.
I complained to them, pointing out that although the stuff they linked to didn't actually ask for any personal account details(*), they were basically muddying the waters when it came to people being able to identify phishing emails from legitimate emails and that they were training people to expect legitimate emails to employ exactly the same properties as phishing emails, which is obviously very bad for security. I also pointed out that it would be better for them to use a technology like S/MIME to allow the user to authenticate the email, rather than some trivially publically available information like half a post code.
They responded - basically they couldn't understand any of my points about why what they were doing was a bad idea or why a postcode isn't suitable authentication criteria.
I escallated the complaint to the regulator. They refused to get involved.
In the end I ended up closing my Nationwide accounts - mainly because of several repeated screwups, one of which almost caused a house purchase to fall through (which they compounded by refusing to talk to me about when I was trying to sort it out); but their utter lack of clue about security certainly played a part.
Unfortunately, since that time, almost all the banks I use have started doing similar stuff. I brought this up with a friend who works in the highstreet banking sector (although not on the IT side) and he pointed out that the banks are generally not interested in security, they only want to limit their liability - if a bank were to sign all their emails and their key got compromised then the bank would be liable, whereas if the customer hands their details to a phisher because the bank has trained them that they should expect legitimate emails to look like phishing emails then the customer is liable.
No confidential content is ever sent via email -- users are directed to login to the (https-enabled) website to view the sensitive information. All PDFs, such as account statements, are digitally signed and timestamped by a third-party timestamping service to prove their authenticity.
I would find it very useful for banks, credit card companies, etc. to email my statements to me (encrypted and signed), as this would allow me to automate archiving of them. It seems very unlikely to happen any time soon though.
Here's a good example of bad email from a bank - in this case, Capital One, a credit card issuer, they email me monthly to say my account statement is ready for download from their website:
1. The email comes from capitaloneonline.co.uk - why not capitalone.co.uk, which is their usual domain?
2. It includes my name and the last 4 digits of my credit card number and says: "So you know that emails we send are genuinely from us, we will always quote the last 4 digits of your account number." - my name, card number and the fact that the card is issued by Capital One are going to be known by *anyone* who has accepted payment from my card. Not exactly great authentication credentials.
3. It includes an "access your account" link, which takes me to the sign-in page on the capitalone.co.uk site. At least they're using the right domain this time, but still it seems risky training people to click rand