What data types should I use SSL to pass?
April 11, 2007 1:10 AM Subscribe
What's acceptable and best practice when it comes to passing data in on websites securely and non-securely? I've always presumed finanical information should be passed securely, whilst names and address were OK non-securely? Am I right?
I run an health condition community where people have to enter their names, addresses, DOBs etc. One member asked to be removed as we weren't using SSL for their profile information. I'm (reasonably) happy that we aren't, but am I wrong? And are there any published guidelines?
I run an health condition community where people have to enter their names, addresses, DOBs etc. One member asked to be removed as we weren't using SSL for their profile information. I'm (reasonably) happy that we aren't, but am I wrong? And are there any published guidelines?
Anything that anybody could reasonably hold to be private should be shipped via SSL. Is there some good reason you're not already doing this?
posted by flabdablet at 1:41 AM on April 11, 2007
posted by flabdablet at 1:41 AM on April 11, 2007
It seems to me if you've already got the SSL overhead setup, it's not that hard to handle profile information through that channel as well. I would say, do it.
(Also, Malevolent's points are good - SSL is only one small part of the security picture.)
posted by heresiarch at 5:52 AM on April 11, 2007
(Also, Malevolent's points are good - SSL is only one small part of the security picture.)
posted by heresiarch at 5:52 AM on April 11, 2007
If you are sending complete, unmodified personal information like that, you're better using SSL for EVERYTHING. However, if you're doing stuff like X'ing the date and year of birth, or the first 5 digits of the SSN, or something, I'd say you're fine.
SSL encryption for a small website shouldn't take a lot of processing power (I think...someone may contradict me). You should probably get it working if you don't already - its a good investment, when you balance it against potential liability for data theft.
posted by plaidrabbit at 5:59 AM on April 11, 2007 [1 favorite]
SSL encryption for a small website shouldn't take a lot of processing power (I think...someone may contradict me). You should probably get it working if you don't already - its a good investment, when you balance it against potential liability for data theft.
posted by plaidrabbit at 5:59 AM on April 11, 2007 [1 favorite]
Thirding or forthing malevolent (eponysterical!). It depends on what your 'etc.' consists of, weighed against whether the person complaining is being oversensitive, or insecure about their physical condition and training regimen potentially being made public.
Even if you're not trading privileged information, you may be trading information which could be aggregated and correlated with other innocuous-on-its-own information to allow an attacker to build profiles of victims. Name and DOB on their own are innocuous, but complete DOB is sometimes used as a confirming identifier for other transactions.
For online exchanges of data, there are such things as too little security, and inappropriate application of security, but there's no such thing as too much security. I vote for buying a SSL cert and locking things down. If nothing else the improved security is a selling point to the membership.
posted by ardgedee at 6:07 AM on April 11, 2007
Even if you're not trading privileged information, you may be trading information which could be aggregated and correlated with other innocuous-on-its-own information to allow an attacker to build profiles of victims. Name and DOB on their own are innocuous, but complete DOB is sometimes used as a confirming identifier for other transactions.
For online exchanges of data, there are such things as too little security, and inappropriate application of security, but there's no such thing as too much security. I vote for buying a SSL cert and locking things down. If nothing else the improved security is a selling point to the membership.
posted by ardgedee at 6:07 AM on April 11, 2007
Use SSL. It's not difficult to implement and you should already be using it for usernames/passwords.
posted by beerbajay at 10:13 AM on April 11, 2007
posted by beerbajay at 10:13 AM on April 11, 2007
From a google search for "hipaa patient identifiers" I came up with this site. Anybody with health-related data should protect the following:
• Account Numbers
• Name(s) of relative(s)
• Biometric identifiers
• Names
• Certificate/License numbers
• Medical Record Number
• Dates
• Photographs and comparable images
• Device identifiers
• Postal Address
• Email addresses
• Social Security Number
• Fax numbers
• Telephone numbers
• Health Plan Numbers
• Vehicle identifiers including license plate numbers
• IP address numbers
• Web URL's
posted by tkolstee at 10:14 AM on April 11, 2007
• Account Numbers
• Name(s) of relative(s)
• Biometric identifiers
• Names
• Certificate/License numbers
• Medical Record Number
• Dates
• Photographs and comparable images
• Device identifiers
• Postal Address
• Email addresses
• Social Security Number
• Fax numbers
• Telephone numbers
• Health Plan Numbers
• Vehicle identifiers including license plate numbers
• IP address numbers
• Web URL's
posted by tkolstee at 10:14 AM on April 11, 2007
Name and address really should be secured as well. A potential thief or stalker could wreak a lot of havoc just with name and address (redirect/steal your mail, and that's just for starters), especially if you combine it with other identifiers like DOB or the last few digits of an SSN. (Mostly this is problematic because some places still stupidly use DOB+SSN digits as a shared secret for identification...)
Anyway, I think as a general guideline, anything that's specifically tied to or identifying a real-world person, ought to go over SSL.
Stuff that only identifies an online avatar (user profiles, other crap like that) doesn't need to be. But if you could use the info to go and find a real, living, breathing person out in the world, it's sensitive and should be encrypted.
posted by Kadin2048 at 10:19 AM on April 11, 2007
Anyway, I think as a general guideline, anything that's specifically tied to or identifying a real-world person, ought to go over SSL.
Stuff that only identifies an online avatar (user profiles, other crap like that) doesn't need to be. But if you could use the info to go and find a real, living, breathing person out in the world, it's sensitive and should be encrypted.
posted by Kadin2048 at 10:19 AM on April 11, 2007
This thread is closed to new comments.
The combination of name, address and DOB plus health details seems fairly sensitive to me, so I'd perhaps want to go out of my way to reassure users as much as possible. That means not only applying SSL, but also putting extra thought into server & application security, and avoiding collecting or retaining unnecessary data (e.g. do you really need DOB, or would year of birth be sufficient?).
If you don't use SSL then the data is vulnerable to being captured as it's transferred between the user's computer and the server, but in reality data more often leaks due to compromised servers and poor coding.
posted by malevolent at 1:38 AM on April 11, 2007