Ok, been meaning to write a little about this, just couldn’t find the time.
To ALL those in charge of taking private information via secure webforms (credit cards, SSN, etc..) PLEASE READ THIS.
Yes, you must use an SSL encrypted webpage, yes you must only give that information collected to those who are directly responsible for billing the transaction. But DO NOT EMAIL all the information to anyone, and certainly don’t include it in the confirmation email!
I say this because I recently registered for a workshop I plan on attending. I’m not going to name the institution that is running it, nor am I going to mention the name of the course (though I must admit if I was presenting at the workshop I would be very pissed to learn that this was how they were sending confirmation emails). My company is paying for the workshop so they used the company credit card and the administrative assistant took care of the registration for me. Shortly after they registered me, I received the confirmation email. What did I find in that email that they sent to me (and to one other email address that we didn’t recognize), my contact information, all the contact information for the person holding our company card, the full credit card number, the Expiration date, and the CCV Code!
They emailed out everything you could possibly need to use the credit card at any online vendor in a plain text email over the unencrypted PUBLIC INTERNET!!!!
The fact that they had a nice SSL encrypted website to take this information just made the situation worse. Through their actions they have violated the trust relation they setup by presenting what appeared to be a secure internet transaction. By emailing the information they collected back over the internet, they placed that information at even more risk than if it was not emailed, but didn’t use an SSL cert. Now our credit information is being cached unencrypted on at least 2 email servers (most likely 4 or more) for who knows how long. If those machines are compromised or someone was having fun watching that traffic, they could now be purchasing a couple of big screen HDTV’s maybe a laptop or 4, subscribing to every porn site they want, etc..
People have got to remember that your responsibility for the secure transaction on the web doesn’t end at the SSL encrypted webform. It continues for as long as you hold and maintain that private information. End-to-end, review your policies, before it comes back to bite you.
I’ve been nice and I’m trying to work with these people to make sure they get this corrected. So far they seem to be listening (though action is a little slower). Hopefully they will get it, time will tell. If I had been someone less friendly, this could have been a much bigger headache for them.
In terms of egregiousness, that probably beats what I have. The parties responsible should be forced to…er…do something that would improve security. (That could have gotten more violent.)
I’m aggravated by a couple of Dreamhost’s policies. Dreamhost is an excellent place to have a homepage, host about a zillion domain names, and basically mess around, and they do some very interesting things technically, but I would definitely be leery of recommending it to anyone considering e-commerce.
If this were to change, I might reconsider: When setting up new user accounts, the new user’s password is sent to the user via e-mail, regardless of whether it was set manually or chosen by the user. Fortunately, access to their IMAP server can optionally be over SSL, so I mitigate this by setting my only access address to the mailbox I access via SSL—and remove (not just trash) the offending e-mail from the remote folder as soon as possible. I figure since Dreamhost is both the source and the destination of the mail, it can’t have been exposed to the public too much. But it’s messy. They should at least make it an option not to send passwords.
Another gripe I have is that you cannot access phpMyAdmin through their SSLed panel server; you must access it through a special subdomain of your own domain which isn’t SSLed (even if you bought SSL for your domain). I’ve worked around this by purchasing the static IP option and adding a CAcert.org-signed certificate, then installing my own copy of PMA.
All of this would be a lot more fun if it were more straightforwardly secure, though!