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.
https is designed to prevent others from intercepting the traffic en route - it has basically nothing to do with how the data are stored. Should everything be encrypted? Yeah. Passwords should be salted+hashed+more because the company has no valid reason to know what the plaintext is. I hope that if I am buying something that they have a valid reason to know what the plaintext version of my address is - I don't think the USPS is that good (yet).
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.
Exactly, and their Term Of Services (if there are any), are probably not as secured as their website's sockets.
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.
...You're dealing with human beings, and human beings make mistakes.
That's why.
Let's not assign to incompetence that which may simply be apathy.
For personally identifiable information that is non-sensitive, is there any reason they should care about taking measures to secure it (especially when it's not their own)?
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.
It's forbidden in Poland. Similar rules apply in many european countries
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
How would one secure an email? Existing S/MIME and PGP are not commonly used.
A company cannot abandon email because it's the only notification method that is guaranteed to be delivered to the purchaser of goods. If you just show a confirmation number on the screen in big bold red letters and ask to write it down, 99% of customers will not notice that. Some may not even see it because they walked away or closed the browser as soon as the transaction went through.
So the problem here is far deeper, it's not just lazy programmers. Perhaps it won't be solved until every one of us has a personal FIPS 140-2 USB or smart card processor on a keyring.
Your name, address and phone number are published in the phone book. What's sensitive here?
On a Web site, it's done over an encrypted connection not to protect the information but to prevent a third party from sitting in the middle collecting payment information. The combination of personal information with payment information (credit card number and expiration date), that would be sensitive. On their own either set of information should be non-sensitive, but combined it's sufficient to pass the authentication checks merchants and credit-card companies do. But just personal information without any associated payment information, what's anyone going to do with that that they couldn't do by looking through your local phone directory?
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.
Most people would find it inconvenient when an important electronic receipt comes with all important fields blacked out. When I buy for a company online I forward these receipts to the accounting. What would I do if the email doesn't say what I bought, how much I paid, what c/c I used, and so on?
I understand that it is perfectly possible to have a purely HTTPS online store, without using email at all. You could print your receipts securely on your local printer (or into PDF) and submit those. However hardly any store on the Internet operates this way. And even if we make that additional step and revolutionize e-commerce, still we would have a partially broken system that has a huge disconnect between the arbitrary identity of the user and the verified identity of the credit card (thus allowing anyone to buy with a stolen c/c.)
In practical terms, email is not easily interceptable. En route it is usually encrypted with TLS. That is easy because SMTP servers do not insist on authentication of peers. So only the two endpoints, those that hold private keys, have access to the content.
One could say that the SMTP server itself is vulnerable. Well, it is, unless you run your own. I do. It's trouble-free. On top of that, nothing prevents the server from encrypting stored emails so that it's hard for an operator (or an intruder) to gain access. For example, generate keypairs for each account, and make sure that the SMTP/database box has only the public half. To read mail (and decrypt) you have to log in with your password, which just happens to decrypt the private key - and that can happen on a completely different (IMAP) box, and only in RAM, and only while you are using the server.
So for all practical purposes it is easier - and probably safer - to keep the current practice. Most retailers black out the c/c number anyway; the last four remain, but how many cases are known of actually recovering the full number this way? (Just send a Google Glass wearer to the checkout line at any store and capture as many cards as you care to.) The rest is not very likely to get stolen. As I understand, most thefts of login data occur directly from databases because they are either not encrypted, or encrypted with a symmetric algorithm, and the key just sits right there (it has to, otherwise you cannot encrypt.)
But if people want change, it should begin at the basics - with secure and sufficiently trustworthy authentication and encryption; this means that everyone gets issued at least one keypair inside of a dongle. Once you have that, everything else becomes trivial. As I understand, DoD has implemented exactly such a system with a common access card.
Your payment is sacred. All other, not so much. (Fixed)
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.
You are talking about A standard. The OP was talking about THE standard.
I can categorically say in the last 20 years I have not received an email implementing any of S/MIME. S/MIME is only marginly more wide spread than RFC1149
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.
The problem here is with how html links work... the link description (ie what you see) doesn't need to relate to the actual url (the href), so you often see a link which looks legitimate but actually goes to a malicious site, and many mail clients (and even browsers these days) dont make it easy to see the actual url. This is why slashdot puts the actual domain name inside square brackets after every link because it's far too easy to disguise a link to goatse as something else.
So your mail ends up looking just like every other phishing scam, which means that either people will distrust your mail, or become more likely to fall for phishing scams.
The fact is, computers in their current form and the internet as a whole were never designed for the non technical masses, and many many problems result from this.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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