Posted by Susan Rust on March 4, 2010 at 4:18pm
Hey SDUG, Sandcamp seems like an ethereal memory....Anyway, we have an ecommerce project where the client would like to collect sensitive information, like insurance and social security number data. We would like to encrypt this info. A few questions:
1.http://drupalmodules.com/node/2461 -- This is the client-side encryption module -- is this the right module for that type of issue?
2. Anyone actually use/try this? Will this type of thing stop your average hacker?
3. Any other suggestions?
Thanks all, see you next week for Drupal 7 Euphoria. Sorry not be to going to SF Drupalcon on the magic bus...but let's meet for drinks!
Susan
GBM Loves Drupal
Comments
Dangerous stuff
I don't have experience with this in Drupal, but have followed server-side storage of sensitive info for many years. There are a couple of basic issues which will never change:
- no technology is completely safe, crackers will develop ways to circumvent it, it's just a matter of time
- security through obscurity does not exist
- the client PC is never safe at all (zombies, key loggers, etc.)
Once you store sensitive information on the server, you are responsible for same. So it is imperative that as little as possible is collected and stored, regardless of what cool technology is used to protect it. For example, SSN should never be stored unless absolutely, unavoidably necessary. Use a unique number for each user instead, and use the SSN for one-time authentication and then discard it, if at all. Put policies in place regarding system security and make sure people adhere to them. Audit, audit, audit.
As a corollary to being responsible for stored data, this could come back to bite GBM. Be sure you cover your backside.
Insurance info might potentially be regulated by HIPAA (http://www.hhs.gov/ocr/privacy/) if health insurance details are included. That's a whole 'nother can of worms.
Back to Drupal: The cse module has a fairly low number of downloads, see http://drupal.org/project/usage/cse. Without a competent security person vetting the code, I personally would not put it into service. Nice idea, though.
--
Christoph Weber
Great Feedback
Hey Christoph, thanks for the great feedback. This makes me nervous for sure. But that's a nice idea to have a one-time submission that ISN'T stored for the SSN. A release from client is a good thought. Invaluable help as always, thanks much.
Susan | Better modules through revenue-share: Crafted, Curated, Contributed
More to Think About
Susan,
Christoph got the ball rolling with valid concerns. There's more to allowing personal data on a site. The part you've already asking about is typically called "data at rest". There are standards for credit card type data, PCI DSS and there's HIPAA, both have way different requirements. PCI isn't a federal standard (yet) but some states have implemented laws similar to it, and there's a huge push in the industry to make it a federal requirement. Some of the requirements are related not just to protecting this private data, but how to handle if the data has been compromised with regards to user notification too.
It's not simply data that's stored on the server, but within backups, etc. One of the main issues here is outside access to your server storing this data. I don't mean someone breaking in, that is one issue, but who would have access within your hosting company. Unless you've bought your own server and are simply renting rack space and network access, there are other people that would have legitimate access to the data stored on your server. If backups are made of your server, do you know how secure they are stored? Would you know where? Are those facilities also "compliant"? Even if you bought your own server, there's still the issue with physical access to your server too that needs to be considered. Checking with your hosting provider will help answer these questions. If you happen to be working on a copy of the site on your local development server, you'll have to safeguard the data just like it was out on your hosted server.
The other part of this deals with data "in-flight". Most of us are very familiar with secure web browser access using https, but there are other ways to transmit data to your server that doesn't encrypt the data in-flight. You'll need to pay attention to all ingress/egress of data so it meets all the requirements for "in-flight" security too.
In looking at the module you referenced, this one can't be used for HIPAA because it only supports 128 bit AES encryption. HIPAA requires 256 bit. 128 bit maybe enough for an ecommerce site, I don't know for sure.
Anyway, hope this was helpful!
Mark Schoonover
http://www.thetajoin.com
High Performance Drupal Hosting & IT Services
My experience regarding the physical plane
While working for a public company, we were obligated to adhere to Sarbanes-Oxley policies. Secure backup, as with other accounting practices, is a balancing act of control. Too much control/security can be unwieldy and cumbersome with sharply diminishing returns, but (of course) not enough is ripe for failure.
Note: we maintained data for a manufacturing company, so that did not include such sensitive data as SSNs and the like.
We contracted with Iron Mountain for several years and, while we never suffered loss, we looked secure on paper. I count my blessings, though, as it only takes a single failure to cause extreme loss and hardship.
IIRC, our procedure was daily/weekly/quarterly backups on multiple tapes. Our server room was physically secured with secure keys and a single point of entry. It was also located in close proximity to my office (next door) and or within a well viewed area. We had weekly pickup and delivery from Iron Mountain with designated primary and secondary contacts. There were passwords as needed for access all along the way. Aside from IT contacts, the company President was the next authorized person for account access. We were audited by Ernst & Young after prepping policy with KPMG.
I can't comment on Iron Mountain's performance beyond that, and my tenure at the company ended in late 2006. Ask security vendors for references of clients with situations comparable to yours. Perhaps you can get a security consultant or accounting firm to audit your policies, both planned on paper and after implementation, to get sign off that you were responsible enough.
HTH,
Project Management: http://www.sagetree.net
Coaching Services: http://burtlo.info
Thanks for Sharing
Hey All:
Thanks for sharing and giving enough info to say "no" to the client on this one. It's a big relief and great advice and comments, thanks.
Susan | Better modules through revenue-share: Crafted, Curated, Contributed
encrypting user profiles
i would like to give you tips that how you can achieve this, i mean encrypting user profile fields.
PART - 1
1- Install and enable encrypt module http://drupal.org/project/encrypt
2- Your server should have php mcrypt installed
3- Configure and store secret key on the server, however i would suggest you to keep outside web root
PART - 2
1- I am assuming that you are using drupal core profile module and you created profile information like firstname, last name, ssn, and other fields
2- Go to modules/profile/profile.module
3- Load the encrypt using module_load_include('inc', 'encrypt', 'encrypt.encrypt');
4- Encryption: find profile_save_profile function and just before saving to the database encrypt the values of profile by using encrypt()
5- Decryption: find profile_load_profile function and just before loading apply decrypt() function
6- That's it, this is what i did for one of my client to encrypt and decrypt user profile data.
Similarly you can apply encryption on core user module through user_save() and user_load()
Good news! you can apply encryption on CCK fields tooo by using node_save() and node_load()
But you need to write lines of php code
Please correct me if i am wrong!