Page 1 of 1
Simple Hashing (MD5, SHA1)
Posted: Tue Jul 10, 2007 9:44 am
by GameMusic
I'm aware, thanks to this forum for quite a bit of it, that MD5 and SHA1 have issues and that it's recommended that we use SHA256 (or is there a better one now? SHA512?).
However, I would like to know more about these issues since I may use either for file-checking, speed, or low security requirement situations.
Have they been cracked or simply heavily dictionaried? Some MD5 dictionaries are online but I couldn't find any particular crack to invert MD5.
Why is it said that you shouldn't double-hash passwords and does it apply to SHA256?
Is SHA256 really vastly more secure, or is it simply a longer hash and more obscure?
Would md5(md5(random uid salt) + password) (or sha1) be stronger than SHA256?
Posted: Tue Jul 10, 2007 10:07 am
by TheMoose
"Why is it said that you shouldn't double-hash passwords and does it apply to SHA256?"
MD5(MD5(string))
All the hashing algorithms return a finite limit string (let's take MD5 in this case, 32 character hex string). There is a limit to how many variations of the 32 character string you can return. It's easier to brute force MD5 when you know you have a set limit of MD5 hashes to make a hash of. IE: if I take MD5('TheMoose'), I get a 32 character string. If I MD5('TheMoose1') I get a different string. Take all the variations of that 32 character string, which is 16^32 (32 characters each of which can hold 16 different characters), and you can see why it's a bad idea to double hash something. A single hash is way more secure because they have to brute force the actual string being hashed, and not the hash itself.
Posted: Tue Jul 10, 2007 10:16 am
by superdezign
You can never be too secure. Advancements in security techniques aren't made to be ignored.
Posted: Tue Jul 10, 2007 3:04 pm
by feyd
Double hashing deals with reducing entropy. Reduced entropy makes for easier cracks to exploit. Doubling the hash (regardless of algorithm) is less secure. This includes variants that use two differing hash algorithms.
Now, "md5(md5(random uid salt) + password)" is a little different than a double hash. It still isn't more secure than SHA256 -- at best, it's somewhat even, but not really --, it just makes for a convoluted solution scheme. Your idea is similar to HMAC. It's not intended to secure the data, but only authenticate it.
Larger order (higher bit count) hashes are more secure, typically, than lower order (fewer bit count) hashes. Salts shift the category, but the comparison of size stands (provided the same scheme is used.)
Yes, there are higher order hashes than SHA256. SHA384, SHA512, SHA768 and SHA1024 are all higher order, for hopefully obvious reasons.
Posted: Tue Jul 10, 2007 3:12 pm
by Ollie Saunders
Salts and peppers are your best bets for increasing security of hashes. Mordred posted a
very informative article. I guess there's a final version of that somewhere.
Posted: Tue Jul 10, 2007 3:53 pm
by TheMoose
ole wrote:Salts and peppers are your best bets for increasing security of hashes. Mordred posted a
very informative article. I guess there's a final version of that somewhere.
Not to try to sound like I'm a paid spokesperson, but that article is probably the best one I've read regarding password security. It is so easy to follow to even a person with no programming knowledge. One of the things I liked most was the almost introductory tone it has, still while conveying advanced techniques of password security.
Posted: Tue Jul 10, 2007 6:08 pm
by Ollie Saunders
Yeah it should probably be a sticky.