Privacy & Security in user database [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reop开发者_如何学编程ened, visit the help center. Closed 11 years ago.

I'm currently working on some user databse with lots of confidential information (addresses, phone numbers etc).

What would be the best method to store it in a database? Just plain text? Encrypted with some kind of hash so a hacker cant decrypt it easily?

How is this regulated in the law? (Webserver in germany, .com domain at Netfirms, i'm currently in the Netherlands)

Wat about password security?, i know there are some md5 bruteforcers around there (cracked some hashes for me in the past in only seconds...)

Are there any free SSL certificates wich are "trusted" so users don't get popups?, else were to buy cheap one's for .com domains?

Im sorry to polarize my questions so much but all the questions are less or more on the same subject.

---

You need to get legal advice to assemble the list of legal requirements that apply for the data you are processing. This is not a technical question at all.

Then you need to get in compliance, and finally get that compliance reviewed by whatever system is applical for your legal requirements. Again, this is not a technical question at all.

The technical implementation addressing the legal issues is a minor detail, that with the problem statement given by you cannot even roughly sketched in any meaningful way.

---

First of all, there are free SSL certificates. One is from StartSSl and other is from CACert. StartSSL certificates are accepted in most browsers and platforms. SO I recommend it. But you cannot have *.domainname.com (isn't a big trade off anyway.) (These are not trial certificates, they are Free as in Free Beer.)

For saving passwords in database, ALWAYS hash them. Use a proper, long salt and your hash will be very strong.

If you need to encrypt/secure other stored information, you can use any encryption schemes like AES, which offer very strong protection. But since the decryption key is stored in your server, the data in the database is only as secure as your server. Also consider about the overhead of encrypting and decrypting before each database requests and decide if it is worth it.

---

In the UK the Data Protection Act requires you to use "appropriate" security. If the data was compromised, the Information Commissioner could fine you up to £1Million for not protecting it.

In Germany, privacy regulations are stronger than the UK - apologies I don't have the relevant legislation to hand.

For sensitive information like this, encryption would definitely seem to be the right thing.

---

Encrypt data that needs to be viewed at some point (decrypted), and hash data that only needs to be checked.

Example: credit card numbers should be encrypted (there is legalities involved), and passwords hashed.

I recently set up a system for a local newspaper that stores credit card numbers excluding the last 4 numbers. I encrypt them with php generic_encrypt and then base_64encode() the number. The missing 4 numbers are sent via email to the employee handling new subscribers.

So to review: Retrievable data -> encrypt -> encode -> decode -> decrypt Matchable data -> hash -> input -> hash input -> compare hashed input with stored hash.