CSLA and EnterpriseLibrary.Security.Cryptography

Phlar posted on Tuesday, June 10, 2008

I am just wondering if anyone has attempted utilizing Microsoft Enterprise library and the Cryptography application block.  I have two ideas (one more efficient than the other) but am having trouble decrypting the RijundaelManaged in SQL Server.  The two options are as follows:

Option 1:

Use the Login in PTPrincipal to retrieve the encrypted password and decrypted it within the BO.  If it's a match then retreive/populate the PTIdentity class.  The problem with this is that it requires two calls to the database.

Option 2:

Use the Login in PTPrincipal as per normal operation and decrypt the password directly within SQL Server. 

Any direction would help.

 

SomeGuy replied on Wednesday, June 11, 2008

I needed to retrieve the user data to get the password hash and the password salt. So I created custom Pricipal and Identity BO's  and check the retrieved password (hash) in the Fetch for the Identity. I then set _isAuthenticated and Roles appropriately.

 

JoeFallon1 replied on Wednesday, June 11, 2008

Option 3

Hash the DB password so it can never be decrypted. Store the hashed pwd.

When a user logs in, they input the clear text pwd - hash that using the same algorithm and then compare the 2 hashes. If they match, then they used the right password.

This keeps the pwd more secure in the DB. You should also then implement a password re-set procedure - since no one can recover a forgotten password.

Joe

 

Phlar replied on Thursday, June 12, 2008

In the end I did utilize option 3 (for now).  We have scenarios in which we must reproduce a particular error the user is encountering.  In order to facilitate this, we usually log in as the user and follow the exact steps they've mentioned to recreate the error.  I guess with Option #3, we now have 2 choices.

Ask the user for their password

or

Reset the password so that we may log in.

Thanks,

 

JoeFallon1:

Option 3

Hash the DB password so it can never be decrypted. Store the hashed pwd.

When a user logs in, they input the clear text pwd - hash that using the same algorithm and then compare the 2 hashes. If they match, then they used the right password.

This keeps the pwd more secure in the DB. You should also then implement a password re-set procedure - since no one can recover a forgotten password.

Joe

 

tetranz replied on Thursday, June 12, 2008

The way I handle this sometimes is to save the user's hashed password somewhere and then change it to something else. After I'm done pretending to be them I copy their hash value back. I don't know what a security expert would think of all that but it's workable and probably better than the alternatives.

Phlar:

In the end I did utilize option 3 (for now).  We have scenarios in which we must reproduce a particular error the user is encountering.  In order to facilitate this, we usually log in as the user and follow the exact steps they've mentioned to recreate the error.  I guess with Option #3, we now have 2 choices.

Ask the user for their password

or

Reset the password so that we may log in.

webjedi replied on Thursday, June 12, 2008

I use a different pattern...I impersonate the users profile rather than changing anything on their account.  After logging in as the administrator I have a function that requires the account to be in the Admin role which swaps out my identity with theirs...this of course is a one way trip.  About the only thing I can't test this way is the actual logging in process.  When I need to do that I do what tetranz does, copy the password to another field and then copy it back.