Should I encrypt data on my server as an extra layer of protection?

Question

I'm going to create a client-server application that stores a user's sensitive financial information on the server. I would like to encrypt this data so that even if a hacker gets access to the server he/she cannot read the user's financial information. The data would be decrypted by the client with the user's password.

For extra difficulty, one user can be granted access to another user's data.

Is this feasible? If so, is there an online guide which provides an example of the types of cryptography to use?

For example, I'm thinking that each user should have a private key derived from his/her password, and a corresponding public key which is used to encrypt his/her data on the server. This public key is also stored on the server, so that if Alice wanted to give Bob access to her data, she would unencrypt her data using her private key, then encrypt it again using both her and Bob's public key. One problem with this approach is that if a hacker gets access to the encrypted data he/she could use 'brute force' by trying every combination of, say, 8 characters as passwords to see if that combination unencrypts the data. I therefore want to make the unencryption process so slow that it is not practical to use brute force. Is there such a public-private key algorithm?

Edit: Ok, after a bit of research have found that there are plenty of hash algorithms (such as PBKDF2) that are designed to be slow because they take an iteration parameter that can be as large as you like.

Answer 1

I see a lot of flaws here:

• If one account is comprimised, every person's details who are secured against their private key are revealed. This puts users' security in the hands of other users, which is possibly the worst situation to be in.
• Users choose terrible passwords, which no password derivation function can save them from. Even if you're using a work factor in PBKDF2 or bcrypt that ensures an attacker can't compute more than one hash per second, they'll guess weak passwords like "letmein1" and "a1b2c3" after less than a minute.
• You can't encrypt arbitrary length data with RSA (public/private key), so you need to encrypt the data with a block cipher, using a randomly generated surrogate key, then encrypt that key with the public keys of the users.
• Your protocol provides no authenticity information. An attacker could use the public key of a user to encrypt a set of false financial information, then insert it back into the database. You'd need to combat this by signing the data with the user's private key, which adds extra complexities when you're allowing other users to access the data too.
• You're encrypting and decrypting the data a lot, so you make yourself more susceptible to side-channel attacks like DPA and timing attacks. You'll need to account for these and take countermeasures.
• Since the information is financial, you're going to have to host your server in a facility with some serious physical security.
• You're going to need to use strong transport security. You can't just use any old SSL certificate - you're probably going to need something like an EV cert running 256-bit AES.
• It is generally bad practice to store financial information in a database of any kind. A more suitable solution is a HSM.
• I'm not sure of the legal situation in your country, but you may be forced to adhere to PCI-DSS, the Data Protection Act, or any other number of regulations. Most of these require audits, which aren't cheap and aren't easy to pass.

In all honesty, this entire scheme sounds like an accident waiting to happen, especially since you're a beginner with crypto. My advice is don't store sensitive financial information unless you are a payment processor or a bank, and have strong experience in security. Rule #1 of security is "security is hard". Getting it wrong puts your customers in danger, and sets you up for a series of expensive lawsuits. If you're a company looking to sell things, or provide a paid service, use a payment processor company who already adheres to strong security procedures and standards.