Data Encryption?

[baden]

What is the best way of storing and validating encrypted data ie Passwords?

In MySQL I used to use an encryption function using my own salt value, so I could retrieve the data for display.

This may be good for phone numbers but not passwords? How do you do this with SQL Server?

What's the recommended encryption technique for passwords? - 1-way MD5 or hash, issuing the user a challenge response to change the pw?

What if the PW needs to be retrieved - this is where the previous method I talked about may be best.

Recommendations please?

 

[NoCoolHandle]

Depending on what you are looking for.. ODBC has an "Encrypt" funciton.. it allows you to easily encrypt data.. I am certain that it is not to complex in how it works.. There is no matching Decrypt. so you need to encrypt the data and then match the encrypted value in the field..

I would tend to use a stronger encryption algo however.. Most of what i do is dotnet based and it supports a number of options.. Encluding hashing with salts.. This then gives you more control and makes decription harder.. Usually I just store them in binary fields.

Also .. asp.net supports a quick a dirty encryption (no decryption) that is quite usefull for passwords.. I.E. Ecrypt and store, then encrypt and compare...

If you work in the dotnet/asp.net arena and want examples post back.

For what it is worth..

Rob

 

[mrdenny]

SQL 2000 doesn't support encryption nativly. You have to install third party dlls to encrypt and decrypt data within your stored procedures.

For data where you don't need to be able to retrieve the data (like a password) use a one way encrypotion as they are typically harder to break.

To compaire you encrypt the user supplied string and check it against the stored encrypted string.

For data you need to decrypt you'll want to find a ballance between the encryption level and the amount of CPU power which will be spent encrypting and decrypting the data.

While SQL 2000 doesn't support native encryption SQL 2005 does. If you are planning on upgrading to SQL 2005 make sure than the encryption that you select is supported by SQL 2005.

Denny
MCSA (2003) / MCDBA (SQL 2000)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com

 

[baden]

Actually, I was just reading some stuff about .Net 2.0 (really like the Membership API).

Anyhow, there is an Asynch. encryption class I'm going to further research when I have time.

For now - any further comments about that: Asynch or Synch?

Also, hashing with salts is also something I've done in the past, where part of the salt value is composed of some part of the user's properties. That way, no salt value is the same from user to user.

Is this something that has been commonly done?

 

[NoCoolHandle]

In dotnet there is a nice quick and dirty encryption feature built in to the configuration settings area..

 FormsAuthentication.HashPasswordForStoringInConfigFile(txtOldPassword.Text, "sha1")

It is designed to encrypt values from the web.config file. (quick and dirty) - I cant remember, but my memory says no decrypt.. you compare entrys in encrypted format.

However I still prefer the idea of using custom salts..

More work, but much better secuirty. I havn't dug too deep into the new encryption features of .net 2. But I would tend to believe that it is easier and better than before. It seems to be a truely good release.

Re Sync or Async.. Man - background worker threads are easier than ever, and if it can be done asyncronously and still look after your business rule requirements, I would go with that.


HTH

Rob