Calculating a lookup table for that function is no harder than for a straight md5.
But in conjunction would be nearly a millionfold more time consuming.
Yes, I used the word millionfold. Beat that 
It's a real word too :p
Best encoding function?
Absolutely true, Mark, and I wouldn't advocate this approach for extremely sensitive information (or for an open-source app). But a cracker would have to gain access to the PHP code that generates the hash before they'd know what the algorithm was. This certainly isn't out of the realm of possibility, but it's another hurdle to be overcome - so it's more secure than the first function, where the algorithm can be deduced simply from looking at the hash.
I was curious to know how long it would take to generate a hash table for this function, so I slapped together some code. I was expecting it to take eons, and I was surprised to find that my aging 1.0GHz machine can compute a million hashes in under two minutes. (My code doesn't store them, though.) And, of course, this would be much faster in a compiled language. (Finding enough hard drive space to store all 3.4E+38 hashes and the corresponding strings, though, is another story.)
Here's the source, if you're curious - I'm sure it could be optimized:
<?php
set_time_limit(0);
$chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890";
$number_of_chars = strlen( $chars );
// generate hashes for a million randomly generated passwords
$start_time = microtime(true);
for ( $x=1; $x<=1000000; $x++ ) {
$password = "";
// assemble a random password, 8-12 chars
$length = rand( 8, 12 );
for ( $y=1; $y<=$length; $y++ ) {
$charpos = rand( 0, $number_of_chars-1 );
$password .= substr( $chars, $charpos, 1 );
}
$hash = md5(sha1($password).sha1($password));
// if we were true hax0rs, we would store the values
// of $password and $hash at this point
}
$end_time = microtime(true);
$elapsed_time = $end_time - $start_time;
echo 'Execution took ' . $elapsed_time . ' seconds.';
?>I find it strange to call these methods 'encoding' as there is no way of decoding them, because they are all based on hashing. There is no way to determine the original value of a hashed value.
Theoritically, is an unlimited number of values that correspond to a certain hashed value.
md5 is not totally secure either.......
It's possible to have two different strings produce the same hashed value
And SHA-1 is flawed too
mjax -
You're correct.
ClarkF1 -
You're also correct. For serious security, you'd want to use something other than the hashing functions built into PHP. But if you're just trying to protect a message board account or something similar, these functions (or a combination of them, as notset has proposed) are sufficient.
If the account being protected has access to credit card numbers, corporate secrets, or plans for an orbital death ray, you'd want to use something stronger.
Incidentally, though computing a complete hash table for md5 is conceivable, storing it is not. To generate a hash table that provided a matching string for every possible hash value, you'd need (at my rough guesstimate) at very least 100 octillion GB of storage space, and probably much more.
Practically speaking, you'd be better off limiting your table to hashes of English words and permutations thereof. It wouldn't crack every password, but it would be a lot more manageable.
Which doesn't mean that md5 is secure, but it's interesting to consider 
greenie2600 wrote:Incidentally, though computing a complete hash table for md5 is conceivable, storing it is not. To generate a hash table that provided a matching string for every possible hash value, you'd need (at my rough guesstimate) at very least 100 octillion GB of storage space, and probably much more.
Practically speaking, you'd be better off limiting your table to hashes of English words and permutations thereof. It wouldn't crack every password, but it would be a lot more manageable.
Which doesn't mean that md5 is secure, but it's interesting to consider
Yes md5(); is cool... try it once...
Thank you,
Admin
http://TopLancers.com
As I already mentioned, I've tried it over a million times.
Thank's for comments.
I made conclusion, that hash using sha512 (PHP 5 or higher) is the best choise. md5 in the function below is used to make the hash length shorter and, of course, to add additional security.
function encode($value) {
return md5(hash('sha512', $value));
}What do you think about exactly this variant?
Using MD5 on top of SHA512 does not improve security; if it does anything, it weakens it by reducing the search space of possible MD5 hashes (instead of being an MD5 of any possible string, the hash could only be that of an SHA1 hash). Ditto for those other MD5(SHA1(....)) combos.
If you must make it shorter, do it without destroying bits and so increasing the chances of a collision being found. Something like base64_encode(hash('sha512', $value, true)). If you want fewer bits in your hash you'd be better off using a hash that generates fewer bits in the first place.
Of course, using SHA512 to hash something that isn't 512 bits long to begin with is questionable: if people are going to pick stupid passwords that contain only 50 bits' worth of entropy to begin with then no amount of hashing is going to create more than 50 bits' worth of hash.
madwormer2 wrote:But in conjunction would be nearly a millionfold more time consuming.
No; brute-forcing SHA1(MD5()) would only be twice as time-consuming as brute-forcing MD5() - and not even that if you use a pre-existing hash lookup table for the MD5s.
That's a speed difference so negligible it can be beaten by waiting a few months and buying a new computer.
greenie2600 wrote:But a cracker would have to gain access to the PHP code that generates the hash before they'd know what the algorithm was.
But we're already assuming that they've got ahold of the hash somehow....
After all, md5 hashes are hexadecimal,
No, they're 128 bits; hexadecimal is just their most common representation because it's friendlier to text-based protocols.
People who cobble together things like in the original post in the expectation that such activities make the things more secure remind me of people who look at their prescription from the doctor and reason "if 50mL three times a day is good, then 100mL three times a day must be better..."
Weedpacket, so what do you suggest? You want to say, that the best way is to use just simple md5() or sha1(), because is impossible to do anything more secure?
SHA512 unless you don't like having a 512-bit hash. If you want something shorter, use something shorter.
notset wrote:impossible to do anything more secure?
Let's put it this way: no cryptographic algorithm (whether encryption or hashing) is known to be secure. There are only algorithms that are known to be insecure and algorithms that are not known to be insecure. And even those that are not known to be insecure often have known weak points that you have to be aware of when developing any protocol that employs them.
It takes literally years of research and attack before an algorithm can be used with any confidence (though if the NSA endorses it it's a good early sign): cobbling something together and sticking it in a forum asking "is this secure?" doesn't count (Ron Rivest didn't just pull MD5 out of his butt one day - for a start he had to come up with MD1, MD2, MD3, and MD4 as well - and SHA was on probation for nearly a decade before being considered good enough for sensitive unclassified documents). So on those grounds alone (and they're not the only ones) none of your suggestions are "more secure".
Yes, there are engineered-collision attacks that can be made on MD5 and SHA1 - but those are irrelevant for password storage. And if MD5 and SHA1 are weak, then no amount of MD5(SHA1()SHA1()) yada is going to fix them. As MarkR suggested, if you don't know what you're doing then don't bother. Save your energies for something more productive.
Plus, it means the hashes can be used by other applications in other languages without you having to write equivalent cobbled code for them first.