I have a project that saves social security number + all kind of personal information on the database. My solution was to encrypt the data with my key and the users password, so not even me can look at the data. The problem comes when the user looses his password. There is no way of recovering it.
Even if my key is encoded with a commercial product. I thought that in the case of someone decrypting the key, the still have nothing since the other part is the actual user password.
Did I go to far?
Is it even possible to decrypt encoded files from commercial products?
Thank you
did I go to far?
Moderator: General Moderators
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: did I go to far?
Why can't you recover the password? Two common ways to do it: emailing password reset key, or ask the user to visit the company with a passport that proves his identity (and then the support guy can reset the password).
- iankent
- Forum Contributor
- Posts: 333
- Joined: Mon Nov 16, 2009 4:23 pm
- Location: Wales, United Kingdom
Re: did I go to far?
Yes, I think you went too far :pyacahuma wrote:and the users password, so not even me can look at the data
Kai, the problem is that because the *data* is encrypted using the users password, if the users password is forgotten it can be reset, but the data can't be decrypted any longer
Yacahuma - you should consider generating an encryption key and storing it. While its a nice idea encrypting using the users password, I'd avoid it for exactly the reason you found!
Re: did I go to far?
I think I will do the following, I will tell them to create a key based on date of bitrh + social security. Then use that to encrypt the data. That is something they cannot forget. The actual key will be date of bitrh + social security + myownkey. That way IF somehow my encoded key is decoded, and the database is hacked; each record still encrypted individually.
Thank you
Thank you
- kaisellgren
- DevNet Resident
- Posts: 1675
- Joined: Sat Jan 07, 2006 5:52 am
- Location: Lahti, Finland.
Re: did I go to far?
So you would need to reset all customer details, hope they remember their passwords (create something that they will remember) or not use the password as part of the key.
EDIT:
EDIT:
That works pretty well, you would need to know the date of birth and the social security number in order to get all other information. The question is: are there other information that has more value than the social security number? Try to use the least important details as part of the key.yacahuma wrote:The actual key will be date of bitrh + social security + myownkey.
Re: did I go to far?
Make a salt or whatever from the first 3 letters of the users name, the year they were born, and the last 4 digits in the SSN or something.
Then when it comes to recovering the password, you can validate that it is that user by asking for their name, DOB, and SSN.
Of course, you could use other forms of data, the point is to make a composite key which would be unique to each user based on the data they enter.
Then when it comes to recovering the password, you can validate that it is that user by asking for their name, DOB, and SSN.
Of course, you could use other forms of data, the point is to make a composite key which would be unique to each user based on the data they enter.