Other Software > Developer's Corner

Random Question (About Hash Keys)

<< < (3/3)

db90h:
I'm glad you asked this question, as it has made me check into the latest on the security of common digests (or secure hashes -- see how easier it is to say 'digest'? ;p).

MD5 == at least somewhat broken, hacked with practical implications due to the speed at which it can be hacked. Still, it suffices for MANY purposes just fine.
SHA1 == theoretically broken, feasibility of attack increasing, but still not feasible YET
SHA2 == current best thing to use if you trust the NSA, otherwise maybe ripemd320+ or whirlpool
SHA3 == under development

Remember, as I posted in my first rambling explanation, salting your digest will help further in cases where it can be done (e.g. on a web server storing password digests in a database, and if only the database were compromised so that the salt value was unknown). After all, a simple XOR of any data set by a key of equal size that is not zero-filled is essentially an unbreakable encryption method (assuming the data set size is reasonably large or original value not known or guessable when right, and the key not known).

So, intent, intent, intent... ;p.

Compare a digest, for instance, to a hash used to lookup things in a hash map/table - two different worlds. For information on hash tables, where use of short hashes that are *expected to produce collisions* is here: http://en.wikipedia.org/wiki/Hash_table

db90h:
http://bitsum.com/md5.php updated to show all hash/digest algorithms supported by the current version of PHP I have installed on the web server.

db90h:
I actually think I'm going to go with Whirlpool-T as my recommendation for the digest to use .. as I just don't know how far I trust the NSA ;p. It's got a huge bitspace of 512 bits, should be good. No known theoretical or practical breaches, though the original version of the algorithm did have some lessening to its security via a mistake, but none that were exploitable by any means.

mouser:
The following thread links to some articles on the importance of not using cryptographic hashes for password hashing, and is quite relevant for this discussion: https://www.donationcoder.com/forum/index.php?topic=31289

db90h:
Interesting thread. I actually am currently using something like (not precisely, as I don't want to be too precise):
SALT^SHA2-512(SALT^SHA1(password))

Why? Because I needed to upgrade the hash algorithm, and for an unbreached database, the easiest way is to double hash, as opposed to waiting for people to login again and update their stored password hashes at that time.

Navigation

[0] Message Index

[*] Previous page