A simple method of MD5 and salt encryption (to prevent rainbow table collision)

MD5 encryption (or digest algorithm) Everyone is familiar with it, and it doesn't explain.

Now a lot of database design like to use one-way encryption to save the password, verify that the password is encrypted once again to do a ciphertext comparison

        <summary> using MD5 to encrypt///        </summary>/        <param name= "Input" > Encrypted string </param>//        <remarks>2015.08.26</remarks> public        static Guid ToMD5 (string input)        {            using (var Md5provider = new MD5CryptoServiceProvider ())            {                var bytes = Encoding.UTF8.GetBytes (input);                var hash = md5provider.computehash (bytes);                var count = hash. Length;                Hash[0] = (byte) (Hash[3] + (hash[3] = hash[0]) * 0); Exchange 0,3 value                hash[1] = (byte) (hash[2] + (hash[2] = hash[1]) * 0);//Interchange value                hash[5] = (byte) (Hash[4] + (hash[4] = h ASH[5]) * 0); Exchange 4,5 value                hash[7] = (byte) (Hash[6] + (hash[6] = hash[7]) * 0);//Exchange 6,7 value                return new Guid (hash);}        }

　　

This design was originally designed to prevent hackers from being Bauku directly to the user's password, since it is one-way encryption, so even if you know the encryption algorithm does not get the user's actual password

But the so-called however persuasive outsmart, after the appearance of the Rainbow table, simple MD5 is not safe

The following excerpt from Baidu Encyclopedia:

A rainbow table is a pre-computed table used to encrypt the inverse of a hash function, often used to crack encrypted cryptographic hashes. The general mainstream of the rainbow table is above 100G. A lookup table is often used for encryption that contains a fixed-length, plain-text password with limited characters. This is a typical practice of space-for-time, with less computing power and more storage space for every brute-force hack attempted, but less storage space and more computational performance than a single hash table for each input. Using the salt-added KDF function makes this attack difficult to implement.

In a nutshell, an attacker would encrypt a simple password (123456,111111,888888, etc.) in advance MD5 encryption to obtain ciphertext (such as 123456->e10adc3949ba59abbe56e057f20f883e), And then use the data from this table to compare the ciphertext of the database that was being violently

This simple MD5 is easy to get.

So then there were 2 times md5 ... N times MD5, of course this is also the egg ...

So later there was added salt encryption,

Simply put: For example, the login name is BLQW, password 123456, then the database ciphertext is MD5 (123456+BLQW), this can ensure that even if the user's password is the same, but the cipher is different, so the rainbow table on the rest of the dish

There are many ways to add salt, one is MD5 (password + login name), this way is possible in most cases

But when the login name is modified, the ciphertext will also be modified, but this time you do not know what the original password is .... (Although the general login name can not be modified, but the product Wang's idea who knows it ...)

Or someone chooses to build a field to store the obfuscation code, but it's still a hassle.

All right, so much for the following talk about today's theme, a relatively simple way to add salt

        public static Guid ToRandomMD5 (string input) {using (var Md5provider = new Md5cryptoserviceprov Ider ()) {//Gets a random number within 256 to serve as a "salt" var salt = (byte) math.abs (new object).                GetHashCode ()% 256);                Input + = salt;                var bytes = Encoding.UTF8.GetBytes (input);                var hash = md5provider.computehash (bytes);                Hash[0] = salt;            return new Guid (hash); }} public static bool EqualsRandomMD5 (string input, Guid rmd5) {var arr = rmd5.            Tobytearray ();            Take the salt out of var salt = arr[0];                using (var md5provider = new MD5CryptoServiceProvider ()) {input + = salt;                var bytes = Encoding.UTF8.GetBytes (input);                var hash = md5provider.computehash (bytes);      for (int i = 1; i < i++) {if (Hash[i]! = Arr[i])              {return false;            }} return true; }        }

　　

The simple thing is to put the salt in the cipher. MD5 hash is completed after a 16-length byte and byte can save 0~255 integer, so in the example, the random salt is 0~255 number

Then MD5 (clear text + salt) and then save the salt to the byte[0] position

So each hash after the ciphertext are different but still can be directly ciphertext comparison, here is a point, think 255 not enough can add a

Of course, it can be placed directly on the 1~15 index.

Of course, you can take the index 15 byte to 15 and then get 0~14 and then put it in ....

A simple method of MD5 and salt encryption (to prevent rainbow table collision)