Page 1 of 1
did I go to far?
Posted: Sat Nov 21, 2009 10:26 pm
by yacahuma
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
Re: did I go to far?
Posted: Sun Nov 22, 2009 3:48 am
by kaisellgren
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).
Re: did I go to far?
Posted: Sun Nov 22, 2009 5:53 am
by iankent
yacahuma wrote:and the users password, so not even me can look at the data
Yes, I think you went too far :p
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?
Posted: Sun Nov 22, 2009 6:05 am
by yacahuma
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
Re: did I go to far?
Posted: Sun Nov 22, 2009 6:08 am
by kaisellgren
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:
yacahuma wrote:The actual key will be date of bitrh + social security + myownkey.
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.
Re: did I go to far?
Posted: Mon Nov 30, 2009 7:02 am
by Sephern
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.