Slashdot Mirror
Ask Slashdot: Why Do Firms Leak Personal Details In Plain Text?
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?"
It really comes down to what their privacy policy says, the country you are in and if they claim they do not share any information with 3rd parties and you were smart enough to use separate email addresses or unique identifying information so you can show the information had to originate with them then in many countries there definitely are legal avenues you can follow. But for the most part you are shit out of luck, find someone else to deal with. I started creating unqiue information that I can easily map to individual sites so I will know who is fucking me over whenever I register somewhere.
The reason you get emails with your personal information has nothing to do with https (secure) v/s http (insecure), it has to do with the company you did business with sharing/selling your information with their 'business partners' and / or selling it to marketing companies, and the tracking cookies from other websites you've visited.
Linux is unix training wheels, while BSD *is* unix.
People are waaaaay too paranoid these days. There is nothing sacred about your name and address. No one can steal your identity with it. If the email had your SSN or DOB in it, that would be different. But your name and address? If you have a landline phone, it's probably in a phone book and on numerous telephone directory websites and has been for years. Public court records have your name and address too. Nobody cares.
I believe that his point was that the exact information that was sent encrypted is now being sent in plain-text over email. So, what's the point of using HTTPS to send private information if it's leaked right back through plain-text on port 25, and what can be done to tell companies to stop forwarding all those details through emails. Maybe they could email a link telling the user where to log-in to see his invoice instead of forwarding all his private information through email.
Why should they care?
There's no benefit to them keeping your information safe, it costs them time, money, and effort to do so, and there's no real consequences when they screw up. They will just put out a statement saying "all of our customer information was stolen, we recommend everyone change their password, and the hole is now patched - it can't happen again!".
Also, they can blame the thieves. "It wasn't our fault, it was that scoundrel who noticed that you can change the account number in the URL to get into someone else's account."
As to "we value your privacy", what does that actually mean? It means that companies have discovered that people trust companies that make that statement, and are more likely to purchase from such a company.
That's all it means, and no more. It doesn't mean that they care or that they abide by the statement, it means that they think they can get more business by using that phrase liberally in their public-facing documents.
You're living under the naive assumption that companies mean what they say and will do what they promise. They do what the consumer protection laws force them to do - any statement that reflects these laws is probably true, while the rest is simple puffing.
I think the analogy would be whispering something into the company's ear, then having the company yell loudly back "OK, Bob Smith, you ordered a 5-month supply of boner pills, and is your phone number still 867-5309?!" I think the lack of conceptual security awareness contiguity evinced by the rather ramshackle habits of securing one transmission via HTTPs on the one hand and then not securing a future transmission in any way shape or form on the other hand is what seems to have irked the anonymous reader. Companies often contain multiple freely self directing agentive humans who often do things in ways which can appear on the outside to be dissonant.
So, what's the point of using HTTPS to send private information if it's leaked right back through plain-text on port 25
A locked front door and an open back door is better than two open doors. Although yes, they should lock the back door. What we really need is industry-standard secure-ish email.
The question is, who are you worried will find this super secret sensitive information (Your name, address and fact you use the site)?
The government? They don't need to intercept the e-mail they have easier ways of knowing it?
Some criminal targeting you specifically who manged to intercept this e-mail? He already knows who you are all he learned is you use this site,
simply seeing the IP is enough?
Some random script kiddie on the internet? intercepting e-mails is not that easy, yes they are in plain text but they are not broadcast over the internet for everyone to see
you have to position yourself along the route it travels (and this route normally doesn't change much) and attack somewhere along it, not impossible but hardly effortless. and why would he?
Which only leaves corporate espionage targeted against the site you are visiting, which though more likely then any other vector still seems a bit far fetched, and in the end all they learn is your name&address.
There are plenty of serious threats out there on the internet, this doesn't seem like one of them.
focus your worrying else where.
He's not claiming that the data is stored encrypted. All he is saying that the data he sends encrypted shouldn't be sent back to him unencrypted later.
Generally speaking, retail sites (Ones who have the really important information, like credit card numbers and the like) also only store hashed passwords. So asking for a password will get you a temporary link e-mailed (usually requiring further security questions) to set a new password. Other personal information, your name and e-mail address, are not considered worth securing, as you automatically send them out with every message you send, and all your mail is invariably addressed to you with your full name by your other contacts.
Postal addresses are generally something of a grey area. On the whole, they're not particularly secured (Anyone who was determined to find out could find your address from the phone book, electoral roll, or other public list). Credit card numbers are typically secured by removing/obscuring all but the last 4 digits, and items ordered are again typically treated as "Better to include with a receipt, as a double-check, than to exclude".
There is, as always, a fine balance in the "Privacy is required" to "more information is better" debate, but leaving that aside, while SMTP is a plain-text transfer medium, it generally requires quite a lot of work to actually get someone's details. For instance, you have to:
This isn't easy, or practical. Sure, if you want to, you can do it, but what is the point? If you're stalking them, there's much easier methods (going through their trash, trawling public records, google searching their name). If you're selling to them, there's easier ways (Buying details lists from credit bureaus, mass mailing).
The problem of secure e-mail has been around for a long time, and many solutions have been proposed for the problem (S/MIME, PGP, Domainkeys), but it's largely a chicken-and-egg problem - Secure mail systems are not universally supported, so it's not used/Secure mail systems aren't used, so they're not supported. Solving this problem is left as an exercise for the reader. Obviously.
Your payment is sacred. All other, not so much. (Fixed)
No smpt doesn't support encryption between servers.
Actually it does. But obviously both servers (sender and receiver) must be configurered to use it (which most aren't, unfortunately). And sender must be configured to check receiver's certificate (which even less are).
It's not a protocol issue, but a configuration issue.
And knowing this, it is indeed unwise to include such confidential info in an e-mail.
HTTPS means that you have a securely encrypted connection with the remote server. Not that the people who own the remote server are going to keep your privacy sacred.
But it does mean that nobody on the path can listen in on the connection. Which is defeated if then the same info is sent back over an unencrypted channel.
In those places, a $100 bill would work as well or better than a passport for getting through checkpoint guards. The idea that someone would bother with your passport number in trying to forge a passport to get through there is rather laughable, since they didn't even bother to check said number to see if it was legit.
At a border with better security? Not going to work. Passports have a lot more security to them than that, particularly now.
Basically if places have weak security, the have weak security. Someone isn't going to bother to try to get a legit name and number to forge a passport. If they have tight security, then it wouldn't do any good as they check the other features, which wouldn't match.
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 :(
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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.
and his solution is to mail the IT department at the company, like the PHB there gives a fig (or possibly even understands the problem)
When he should do is mail the legal department instead, or failing that the CEO or CIO. They might not understand the situation either but they'll understand the words "privacy" and "violation" and sit up, then they'll pass the blame on to the IT PHB and he'll have to "just fix it" in some way. Which he will do by getting an underling to remove most if not all of the personally identifying information from all emails in a overly-broad way, until the Marketing department decides it needs to put your address on every email all over again.
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
http://blog.nexusuk.org