views:

117

answers:

4

I'm in a bit of a strange dilema. Please bear with me as I try to explain it!

I'm using forms authentication and am storing additional user information in another table (referenced UserID from Forms Auth, encrypted SSN, Salt value). When users register to the site, I ask SSN, DOB and LName and verify against our system before they create an account. I want to determine if that SSN has an account associated with it in forms authentication. Since the SSN is encrypted with a salt value, I can't do a lookup without looking at each row.

I only want 1 user account per SSN. Using a salt value disrupts this.

The way I see it, the only way around this is to use a common encryption algorithm for the SSN. When the user types it in, I apply the same encrypt algorythm and see if there is a value match in the user extended properties table.

Is this secure enough?

A: 

I think its secured enough, attacker would have problem doing that without deep knowlage of the system.

01
A: 

Use the same salt every time. Then you can compare the encrypted values.

recursive
+1  A: 

Rather than use the same salt value, generate the salt based on the other user information so that it can be reconstructed. Thus, you can regenerate the salt once the user applies, and you can generate the expected hash and get the job done in a single query.

Zachery Delafosse
Are you saying to use the salt from FBA's account info? If so, I can't use that as I don't know which user it is. In order to decrypt the SSN, I need the salt value but I don't know which User it is to get the salt to create a salted encrypted version of the ssn to compare against.
asp316
Re-reading the topic, It seems pointless to store the encrypted SSN, and its key (though you call it the salt) in the same table.My suggestion, though, was when the user enters DoB and LName, generate the salt based on that. This would let you apply the salt to the SSN, so you can look it up.
Zachery Delafosse
+1  A: 

If you wish to encrypt (not hash) the SSN value, it is not a good practice to store the key in the same table as Natso has pointed out. This is fraught with danger, since keys are not to be stored with the data they protect - if an attacker manages to obtain a dump of your database, he would be able to decrypt the encrypted contents, since the key is stored along-side.

The application should obtain the key from a secure key store which could then be used to encrypt/decrypt the information. This way, you could continue to store sensitive information in the database thereby protecting your information, and apply a different mechanism (usually file-system security) to protect your key store.

This is of course, assuming that your requirement is to store data in a secure manner in the database, and recover the same at a later point time. However, if you do not the data to be recoverable once it has passed through an algorithm, you should explore the use of hashes.

Vineet Reynolds