I recently talked to a potential customer who wants to build up a database which contains fairly sensitive data. One of her key requirements is, that the data storeed will be encrypted in a way that only the user will be able to access it. Even if there are certainly some disadvantages I thought about how I could achieve this and I came up with the following approach:
When a user is created I am creating a public/private key pair for him. The private key will be encrypted symmetrically with the users password. All data that is stored in the database (most likely except the timestamp - and of course the id) is encrypted beforehands with the public key. When the user logs in the password will be used to decrypt the private key, which can in turn be used to decrypt the data from the database when reading it. All en- and decryption may happen transparently in the data access layer.
There are some major drawbacks to be addressed here:
- We'll have to de- and encrypt the private key when the user wants to change her password
- If the user loses her password we won't be able to reconstruct the data
- Either the private key or the users password has to be stored in plain text temporarily
- Whenever we suspect that a private key has been corrupted (in the sense of stolen) we'll have to reencrypt all of the users data
and of course some more that did not come up to me, yet.
The first issue is inconvenient for us, but may happen transparently to the user, hence no big issue.
The second one is a bit more intricate. We do not want the user to lose her data, but we'll have to assume that the user will loose her password (storing and/or using a fixed password are no options for obvious reasons - never). A possible solution would be to create a very strong passphrase (30+ characters) which will be used to encrypt a backup of the private key. This might be sent to the user via snail mail or the like. The user may use this to restore her data if she forgot her password.
I have a bad feeling about no. 3, but I have no better idea at the moment.
The fourth issue again is inconvenient for us and may take a while, but should be no big issue. The only problem is the human factor here. We'd need the user to log in to perform the re-encryption and would not be able to do this automatically.
Are there any serious flaws about this, especially concerning the data security? Is this a good idea anyway?