SQL Server 2005

yop

Folks
Have to migrate a table from SQL 2000 to another table in SQL 2005 and the password encryption is in MD5 and the existing table uses SHA1.

I have searched high up and low down but I can't find an answer on the net.

The password was encrypted in .NET using MD5.

I am aiming to DTS the data across from 2000 to 2005 into a temp table and was hoping to decrypt the username into a string, then encrypt using SHA1 to store in the new table structure.

Any pointers?

Thanks

BobsYerAuntie

if I understand correctly, you are attempting to decrypt an MD5 string and store in another table with a different encryption?

However, MD5 encryption is a one way encryption, you cannot decrypt this... so I think your new implementation will need to use interpret your data as MD5 and not SHA1.

NeverSayDie

You should probably take a look here
http://en.wikipedia.org/wiki/Cryptographic_hash_function

seamus

There should be nothing stopping you from storing either type of hash in a binary column.

Whatever application is using the table will need to be modified to use MD5 instead of SHA1. Although you could implement a routine which checked the entered password against both an MD5 and SHA1 hash. If the MD5 one matches, the routine updates the stored hash to SHA1.

yop

Thanks for the follow up, sorry I left out important information until I was reading the above I didn't think was relevant.

The new DB is been used by a CMS called Kentico, it will, going forward (Brian Cowan), be administering the users, it uses ONLY SHA1, we can't change this unfortunately

I think I am fubar on this.

We have about 300 customers, we don't want to have to ask them to enter their passwords again on the new system.

Ronan_

Read the field from old DB in .net, Decrypt it, and write it back to the new DB - shouldn't take long at all

seamus

Ronan_ wrote: »

Read the field from old DB in .net, Decrypt it, and write it back to the new DB - shouldn't take long at all

You can't decrypt it

OK, theoretically you can decrypt it, given the right tools, but decrypting MD5 doesn't guarantee that you will get the correct password when you encrypt it in SHA1 again.

For example, a user's password might be "kittens", which produces a particular hash. MD5 cracking algorithms don't necessarily attempt to find out the exact password, just a string of characters which will produce the same hash. In MD5 cracking, you don't need the exact password to access a system - any text string which produces the same hash will be accepted by the system as a valid password.

So in the above example, your cracking algorithm may find that "%^&JDbsN!" has the same hash as "kittens", but you record the former as the customer's password. When you encrypt this in SHA1 format, the customer finds themselves typing "kittens" and it doesn't work - because in SHA1, "kittens" and "%^&JDbsN!" will not produce the same hash.

yop

Ronan_ wrote: »

Read the field from old DB in .net, Decrypt it, and write it back to the new DB - shouldn't take long at all

Thanks for that, as said, can't decrypt.

seamus wrote: »

You can't decrypt it

OK, theoretically you can decrypt it, given the right tools, but decrypting MD5 doesn't guarantee that you will get the correct password when you encrypt it in SHA1 again.

For example, a user's password might be "kittens", which produces a particular hash. MD5 cracking algorithms don't necessarily attempt to find out the exact password, just a string of characters which will produce the same hash. In MD5 cracking, you don't need the exact password to access a system - any text string which produces the same hash will be accepted by the system as a valid password.

So in the above example, your cracking algorithm may find that "%^&JDbsN!" has the same hash as "kittens", but you record the former as the customer's password. When you encrypt this in SHA1 format, the customer finds themselves typing "kittens" and it doesn't work - because in SHA1, "kittens" and "%^&JDbsN!" will not produce the same hash.

I am snookered. Not to worry lads will have to go back to the client and tell them the options
Option A, or Option A or even Option A

Thanks lads