Hello,
I would love some feedback / discussion regarding security and the submission of online forms using sensitive data. I work for a small college and our website is hosting in a shared environment. There has been discussion about making the college application form, application for residence form and a few others available online. What tips / concerns can you provide to securely get the information from the user in an encrypted fashion?
My primary concerns are storage of private information on a shared server and emailing of private information in an unencrypted fashion.
How do you manage the security about collecting private information via forms?
Links to other resources, web posts, etc would be appreciated.
Thanks.
Comments
HTTPS to start
Big step number one is to get an security cert for your server (or at least for the pages that are using that form). Maybe you could also have form based data all be stored in 1 Drupal site so that it's easier to manage the privacy / security policies in terms of permissions that you want. Shared server as long as it's internal to your college probably isn't a huge deal. Just make sure only people a b and c have access to the Drupal site hosting webforms. It would be pretty hard to break through and get that data back out about people.
SSN data (if stored in a CCK field) won't be encrypted in the database so you might need to find a way of doing that. I'd also try and stay away from gathering that info all together (never a big fan). Probably can automate a lot of stuff minus SSN and then have some alternate method of getting SSN that would be safer.
This lil thread might help as well http://drupal.org/node/82440
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
FASHION
NICE BLOG FASHION INFORMATION
europefashiondress.blogspot.com
Thanks for the comments. We
Thanks for the comments.
We have already purchases the SSL cert. The shared hosting is with a 3rd party, just down the street from us actually (not that it matters!). If the host was in our data centre I wouldn't worry about it nearly as much. We host email, network drives and intranet only. We used to host the website, maybe it's time to rethink that.
SSL, complex password requirements, dedicated hosting
All the steps above are good basic steps for any web app. If you need to continue hosting externally, at least move to a 'dedicated virtual' server so that you're the only one (outside the hosting company) with access. Don't email forms - email a notification that brings them back to log in and retrieve it in some way (exporting a record or printing). If you have a well-patched and smartly set up system then the information is relatively easy to secure between the user's browser, server and your staff. A dedicated server is a good step; inside your own hosting environment is better, but not without cost in resources and time.
One of the most difficult aspects to ensure is the database itself. The database files are fairly easily portable, so file system access is a big concern. You need to to store sensitive information in order to accept applications, so one step to take is to break up the most important blocks: name, address, SSN. I've designed similar schemes in the past for breaking apart CC info and then encrypting the key that ties the parts of the records together. Similar to how Ubercart utilizes a folder outside the web root with an encryption key, you could have several different keys used to encrypt the ID's that tie the separate tables (or content type nodes) together.
Once you think you have a good solution in place, the best thing to do is pay a service to test/probe your setup and see if it's sound. It's a big liability, but people do it. Common sense good precautions will take you most of the way.
Hope that helps!
Jason
Jason Pamental
[ @jpamental ]
vps?
If the main concern is the other users on the shared host (which is definitely an important one) consider a VPS. For a little more money than shared hsoting and much less than a dedicated server, Virtual Private Servers provide some greater separation of your data from everyone else's and therefore a bit more secure.
I would simply try not to store private information that truly must be kept private. Things like social security numbers and credit cards are hard to store properly so just avoid requesting them if you can. Name, address, birthday are usually available elsewhere on the internet and are not as private as many people think they are. If you take reasonable efforts to protect that information you are probably ok.
knaddison blog | Morris Animal Foundation
Regulatory Concerns
Previous commenters have made some very good points on data security. Since you are working with educational/student records, I encourage you to also check that you are in compliance with regulatory requirements. FERPA may be a concern (http://www2.ed.gov/policy/gen/guid/fpco/ferpa/index.html) for instance.
We are located in Canada so
We are located in Canada so FERPA doesn't apply but PIPEDA does (I am sure they are pretty much that same though)
Does anyone know if webform
Does anyone know if webform module can be setup to email a notification ("A form was submitted click here to read it" kind of thing) ? I did a quick search but couldn't find anything
Webform does that
It includes an option to email results to one or more recipients (under 'Webform mail settings), and the form component view allows you to checkbox-select the form elements you want to be included in the email (to avoid sensitive stuff getting thrown around the ether willy-nilly).
Jason
Jason Pamental
[ @jpamental ]
oh, so that is what that
oh, so that is what that email checkbox does. Thanks Jason
Consider Data retention as well
I am currently building an online job application system for my employer and we are encountering some similar problems and solutions. I would Suggest that you look into a data retention/destruction policy. The district retains applications for one year but we will not leave a year's worth of data sitting in the data base. Once a job is closed the data will only be kept locally.