If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Enjoy an ad free experience by logging in. Not a member yet? Register.

Asymmetric Encryption Method for Data Stored in DB

I've been doing quite a lot of reading up on data encryption, specifically the storage of sensitive data into the database, in such a way that the user is the only one to be able to decrypt the data.

The setup I have thus far is as follows:
1. When a new user is "created" a public/private key pair is generated using the openssl.
2. The private key is encrypted using a symmetric encryption, using the clear text users password as the key.
3. The encrypted private key and "clear text" public key are stored into the user table, along with the hashed users password.
4. The user then logs in using their username and password.
5. The users clear text password is used to decrypt the private key, which is then stored into the session, along with the public key.
6. When data is added to the database, the system uses the public key associated with the user to encrypt the data.
7. When the user views data from the database, the system uses the private key in the user's session, to decrypt the data.

From what I've read this seems to be one of the better ways of providing a secure encryption of the data. Admittedly I have to review the security of the session data, but in general, from my understanding it's a pretty good start.

My problem, and the main reason for this post is this: if the user forgets their password is there a way to generate a new password for the user whilst still making it possible to access the data that is already saved into the database?

From what I can work out, this is not possible, due to the symmetric encryption used on the private key; therefore forgetting the password makes the decryption of the private key impossible and thus the decryption of the stored data impossible.

Since I think the answer is "no this is not possible", can you suggest an alternative method that would provide an asymmetric encryption of the sensitive data, whilst not requiring the storage of the decryption key in clear text or using a specific key, hard coded into the system?

I appreciate any guidance or advice you can provide.

Many thanks in advance,

Rich

"An expert is a person who has made all the mistakes that can be made in a very narrow field."

I don't see the value of using public key encryption when you're storing both halves of the key on the same server, and one symmetric password will crack it. Maybe I'm missing some secret security solution here, but how is this better than using a symmetric algorithm?

Not that it solves your question about how to recover the data if the password is lost, I just think you're jumping through a lot of useless steps with your solution.

If your method of encryption is any good at all, it won't be easy to crack! So just use the method that many sites use, have a backup method to access the key in case the user loses it, and keep it in another DB perhaps. Some sort of keyword to access the lost keyword, grandmothers maiden name, that sort of thing.

Thanks Dave and DrDOS for your responses. I hadn't really considered the fact that the symmetric encryption is all that needs to be cracked to access the data. The problem I'm struggling with is the idea that I want the data to be encrypted so that only the user will have access to it, I want to make it impossible for even me to access it.

From what I've read thus far public key encryption provides the best security but in an ideal world the private key is stored on the users machine, not in the database with the public key.

I'm going to look into this further, but if you or anyone else has any thoughts on improving the above method, then please let me know.

many thanks again,

Rich

"An expert is a person who has made all the mistakes that can be made in a very narrow field."