Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Many countries have data protection legislation:

  • Data Protection Directive in EU
  • Data Protection Act 1998 in UK
  • privacy laws in USA

Web application may have registration form where fields for name, surname, email address, address, phone number exist. What actions should be done by site if it stores such personal information? Should this information be encrypted?

Edit: I ask not about general industry best practices of building sites/protecting passwords. I ask about compliance with personal data protection legislation and standards/best practices in this area. Is presense of document called "Privacy Policy" a must for site that stores personal information? What information should exist in this Privacy Policy?

share|improve this question

4 Answers 4

up vote 4 down vote accepted

A previous answer pointed at ICO’s website, where you can find out about the rules that apply in the United Kingdom (which are essentially the same as those in other EU countries, give or take, since the Data Protection Act is the UK implementation of the EU Directive).

I just wanted to add, though, that as with many other similar things, the data protection legislation is generally used as a stick to beat you with when something has already gone wrong. That is, whatever measures you put in place, if you lose customers’ private information somehow, you’ll be guilty of a breach and you’ll very likely receive (at least) some “advice” on how you should have avoided the breach in question.

Put another way, the Data Protection Act doesn’t so much mandate things like encryption as set out general principles, which you will be held to have broken if you lose private information. At that point, you might be asked to agree to e.g. encrypt data in future (assuming, in the opinion of the probably non-technical-expert enforcement officer, that would have helped).

Finally, since you ask about it, as for encryption of stored data, you should consider

  • How likely it is that the decryption key would be compromised at the same time as an attacker gained access to the data (if both are compromised together, there’s no point — other than satisfying someone’s checkbox mentality, where applicable — encrypting things).
  • How sensitive the data is, and whether there are other requirements that mandate encryption (e.g. PCI-DSS).
  • How often the data is accessed (which affects the performance implications as well as the likelihood that the key can be easily located by an attacker).
  • How you propose to encrypt the data. Disk encryption, for instance, may mitigate some physical security issues, but won’t protect against server compromise.
  • Where the data is stored and how it is accessed. e.g. Encrypting columns in an SQL table may make them hard to query, or it may not (depending on how they are encrypted).
  • Physical security of your server, including, for virtualised set-ups, security of the disk images.
  • Security of your back-ups. It may sometimes be worth encrypting back-ups even when encryption for live data is undesirable...
  • How much you know about encryption. If you are going to encrypt things, you need to do it right. There’s little point adding encryption if it’s easily broken, and if you don’t know what you’re doing, it’s easy to make mistakes that make it much easier to read the data than it should be.

Basically, in order to gain any protection from encrypting data, you need to understand the threat you are trying to protect against, the trade-offs you will make in exchange for the encryption, and how to properly use the encryption primitives you are employing.

On a related note, I would always recommend hashing any password fields, preferably using a modern secure hash function like bcrypt, though at the very least with salted SHA256. Whatever you do, don’t use MD5 or historic UNIX crypt(), and don’t forget to add salt. Not only does this protect against password compromise, it means that users can’t accuse you of logging in to their bank account using the password they stupidly used on both your site and their bank’s.

share|improve this answer

When talking about data protection laws the first thing to note is that they are laws so you should check with a lawyer if in doubt.

However, with things such as the UK laws (which you seem to be asking more specifically about) the guidance the information commissioner has on their website is pretty straightforward and nicely enshrines a lot of the principles that you'll find in other data protection laws in the EU (as the Data Protection Act is the enshrinement in UK statute of the EU Data Protection Directive).

http://www.ico.gov.uk/for_organisations.aspx

For the UK, there are a couple of quick pointers which you should consider (and there's more info on the website I mentioned. Here's the 8 "principles" that are set up by the act, shamelessly copied from the ICO's website.

  1. Personal data shall be processed fairly and lawfully and, in particular, shall not be processed unless –

    • (a) at least one of the conditions in Schedule 2 is met, and
    • (b) in the case of sensitive personal data, at least one of the conditions in Schedule 3 is also met.
  2. Personal data shall be obtained only for one or more specified and lawful purposes, and shall not be further processed in any manner incompatible with that purpose or those purposes.
  3. Personal data shall be adequate, relevant and not excessive in relation to the purpose or purposes for which they are processed.
  4. Personal data shall be accurate and, where necessary, kept up to date.
  5. Personal data processed for any purpose or purposes shall not be kept for longer than is necessary for that purpose or those purposes.
  6. Personal data shall be processed in accordance with the rights of data subjects under this Act.
  7. Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.
  8. Personal data shall not be transferred to a country or territory outside the European Economic Area unless that country or territory ensures an adequate level of protection for > the rights and freedoms of data subjects in relation to the processing of personal data.
share|improve this answer

This is a very deep and broad topic. At minimum, you should consider general best practices like OWASP, and industry-specific requirements like PCI-DSS guidelines, HIPPA, etc. depending on your industry.

It's difficult to answer this question in general terms that apply everywhere, short of the best practices mentioned. The most basic one would be not to store passwords in clear/reversible form (i.e. they should be salted and hashed and stored in hashed form; this protects your users from their passwords being disclosed if your site is compromised), but this is just one example.

share|improve this answer
    
I've updated a question –  Andrey Botalov Apr 4 '12 at 11:22

A lot of the guidance is around appropriate protection (see Principle 7 that @webtoe listed), but isn't very proscriptive around what that should be.

The challenge you will have is defining what lies within each sensitivity level. It is generally accepted that employee pay details are sensitive, and their medical data is highly sensitive, so the usual business practice is to use encryption, access controls, logging, regular audits etc to the level which meets requirements for the data sensitivity levels you hold.

A privacy policy is generally considered essential to this process, as without it you cannot easily mandate controls on data.

Additional mandated requirements come from things like PCI-DSS, which specifically focuses on credit card details, so some organisations build these into their data protection requirements.

share|improve this answer
    
Worth mentioning too that adding a privacy policy may create a legal exposure (in case of breach) even in jurisdictions that don’t have explicit privacy legislation; that may even be true for P3P tags, in fact. –  alastair Apr 4 '12 at 16:16

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.