Best encyption methods? - Page 3

[cwarn23]

i dont tink they wil fix it i made a forum post they said its a error that is rare and that the unhasing seemed like nothing to do with it whne i red the posts they made. then i heard that its caused by stuff that i know i didnt do. so it must be the dehasing they are liars. i think they want to incriminate anyone for dehashing when they dont~ i dont dehash i am not a cirminal

A person who dehashes info isn't always a criminal. Sometimes people will need to retrieve personal data etc that has been hashed and that is where a dehasher comes in. Recently I have made another dehasher that can dehash any 3 digits with Java in about 40 seconds. So say your were to store all your numbers as hashes and needed to find the original number, a dehasher could be handy there.

[SKANK!!!!!]

well i think byethost is punishing me for not using a dehasher

[Atli]

A person who dehashes info isn't always a criminal.

De-hashing is never illegal.
The only illegal things about dehashing classified info would be the way they obtained to original hashes, or the way they used the info once dehashed.
The act of dehashing the info itself is not illegal at all.

well i think byethost is punishing me for not using a dehasher

I don't follow... Why would anybody punish you for not using dehasher; a program that uses massive resources to reverse hashes.

Or are we talking about two different things?

[ShawnCplus]

OK, I gotta throw my 2 cents in here. There is no such thing as a de-hasher. A hash is ONE WAY. The only thing that can be done is to produce every possible string against the salt using the same algorithm to produce the same hash. It's not possible to reverse a hash, that's why it's a hash.

[SKANK!!!!!]

well byethost is screwey i mean i think they are just doing it to bug me. like i have the decentcy not to crack codes, "dehash" or whatever the guy abive me put it as. and they just want to mess with me. ive abou had it up to my nose with the zero sized reply. its hard enough as it is to find a decent free host until i get my site real large to need a paid hosting... hashing these dang passwords i cant even check it really because i cant log into my site i cant use any forms. i need to "hash" my passwords but i dont understand how. i get lost.

[cwarn23]

OK, I gotta throw my 2 cents in here. There is no such thing as a de-hasher. A hash is ONE WAY. The only thing that can be done is to produce every possible string against the salt using the same algorithm to produce the same hash. It's not possible to reverse a hash, that's why it's a hash.

Hash one way, your thinking in terms of 1998 technology. Today we have supercomputers with millions of cpus with petaflops whatever that means. So when the performance of the average computer increasing every month it makes it possible for the computer to hash every combination until there is a matching hash. And with today's average home pc, it is possible to crack a hash where the original string was ONLY 3 digits long and that takes about 40 seconds. However with a supercomputer perhaps something like 7 digits could be cracked in that time. Keep up with the technology dude.

[chaines51]

I've always used a hash similar to the following:

function HASHITBAY_BE($toHash)
{
   $maxLength = 42; //maximum length of the salt
   $hashMethod = 'whirlpool' //encryption method...
   $saltLength = strlen($toHash)*3;
   if($saltLength > $maxLength)
      $saltLength = $maxLength;
   if($saltLength < 10)
      $saltLength = 10;
   $salt = saltGen($saltLength);
   $hash = hash($hashMethod, $toHash . $salt);
   $hash = substr($hash, $saltLength-10);
   $hash = $salt . $hash;
   return $hash;
}

The cool thing about using this method is that, even if the hacker gets access to your database, AND your source code, it's nearly impossible for him to retrieve your original data, as he'd have to already know the length of the password (or whatever the data is), in order to retrieve the salt. If the hacker gets access to the database but not your source code, he will be extremely confused by the length of the hash. I like this method a lot. note that saltGen can be any function you want, simple or complex, that generates a random string. Just ensure that it won't generate characters that cannot appear in the hash.

To check if a password can meet this hash, the following method works:

function CheckHash($pass, $hash)
{
   $maxLength = 42; //maximum length of the salt
   $hashMethod = 'whirlpool' //encryption method...
   $saltLength = strlen($toHash)*3;
   if($saltLength > $maxLength)
      $saltLength = $maxLength;
   if($saltLength < 10)
      $saltLength = 10;
   $real_hash = substr($hash, $saltLength);
   $salt = substr($hash, 0, $saltLength);
   $passHashed = hash($hashMethod, $pass);
   if(substr($passHashed,$saltLength-10) == $real_hash)
      return true;
   return false;
}

[cwarn23]

However theoratically if you hacked 6 of the worlds fastest computers to calculate every possible combination hash then there is nothing stopping you from retrieving the original string. And Basically what you do is you loop through the char() function to get the character and use a loop to piece together strings all in alphabetical order then hash the 255^100 strings and see what hashes match the original hash. Then if the computer hashes a string and the resulting hash is the same as the one found in your database then bingo they have your original string.

[chaines51]

I'm not denying that for a second. But, if you've got access to six of the worlds fastest computers, You've got bigger fish to fry than my websites.

And, the same applies for ANY hashing function. You cannot create a "future proof" hashing/encryption function.

So how about you quit pointing out the obvious, and get back on topic?

[ShawnCplus]

Hash one way, your thinking in terms of 1998 technology. Today we have supercomputers with millions of cpus with petaflops whatever that means. So when the performance of the average computer increasing every month it makes it possible for the computer to hash every combination until there is a matching hash. And with today's average home pc, it is possible to crack a hash where the original string was ONLY 3 digits long and that takes about 40 seconds. However with a supercomputer perhaps something like 7 digits could be cracked in that time. Keep up with the technology dude.

It doesn't matter what year you're talking about a hash is by definition impossible to reverse. A hash is ONE WAY. You may be able to use a supercomputer to calculate hash collisions which result in the source string but you can't reverse a hash. Yes, an average home computer can do it, hell I have a set of rainbow tables myself, but this doesn't change the fact that a hash is ONE WAY and a hash can't be reversed. You might have noticed I was repeating myself there because it was necessary. I'm not saying that a hash cannot be resolved to the eventual string, I'm saying that it isn't done the way encryption is done. There are decryptors, there are no dehashers, only lookup tables which, as mentioned before, you provide a hash and it does a lookup by hashing every possible string and comparing that hash to the one you have, if they match then you have a string.

[nav33n]

Maybe the root cause for all this confusion is the word dehasher. ;) Its not exactly a dehasher, but a hash-matcher ! :icon_cool:

[digital-ether]

Hash one way, your thinking in terms of 1998 technology. Today we have supercomputers with millions of cpus with petaflops whatever that means. So when the performance of the average computer increasing every month it makes it possible for the computer to hash every combination until there is a matching hash. And with today's average home pc, it is possible to crack a hash where the original string was ONLY 3 digits long and that takes about 40 seconds. However with a supercomputer perhaps something like 7 digits could be cracked in that time. Keep up with the technology dude.

Maybe the root cause for all this confusion is the word dehasher. ;) Its not exactly a dehasher, but a hash-matcher ! :icon_cool:

The word to use is: guess

[cwarn23]

I'm not denying that for a second. But, if you've got access to six of the worlds fastest computers, You've got bigger fish to fry than my websites.

And, the same applies for ANY hashing function. You cannot create a "future proof" hashing/encryption function.

So how about you quit pointing out the obvious, and get back on topic?

The future comes fast. Have you read this article? Yea, would like one of those in 10 years and everybody will have one of those on their desk in 10 years. So the fact is if the government who buys these super computers can dehash or hash-match then hackers can take over those computers to do the dehashing/hash-matching. This is only in about 2 years. Untill then all the hackers will need to do is take over more computers. Example, perhaps Googles mainframe. Imagine a hacker in controll of googles mainframe doing just dehashing/hash-matching and Googles mainframe processes over 5% of the internet including google apis. So one simple system that can be hacked where 5% of the worlds cpu can be use for any single job. That has already happened twice in the past year for about 52 hours. Of course google tries to cover it all up.

[chaines51]

Once more, it's not possible to create a "Future Proof" hashing mechanism. Anything that is generated by a set algorithm CAN be reversed. (Don't argue semantics over the word 'reverse.' I understand the concepts.)

So once more: What is your point?

[SKANK!!!!!]

im expecting that dehashers can be criminalized for the sake of humanity. i wouldnt like someone using them to free up some space on my web account just to gain acess to my info. im not relatively keen on encryption methods when it comes to flavor. i tend to add a few salts but my mthod is more of a keep your eyes off my sites database contents and all will be fine. no need for a n deep encryption as long as the leverage it takes to wiegh in doesnt get to hard to handle meaning me and my databas stay away from criminalized prostitutes

[Atli]

It doesn't matter what year you're talking about a hash is by definition impossible to reverse. A hash is ONE WAY.

A hash is meant to be one way. There is no way to actually guarantee it. True one-way functions are only theoretical at this point.

Not that I don't agree with you; that hashes should be considered one-way. Just pointing out that it is not an absolute truth, but rather a practical truth. We could very well see some of the more popular hashing algorithms being "broken" in the future.

[digital-ether]

function HASHITBAY_BE($toHash)
{
   $maxLength = 42; //maximum length of the salt
   $hashMethod = 'whirlpool' //encryption method...
   $saltLength = strlen($toHash)*3;
   if($saltLength > $maxLength)
      $saltLength = $maxLength;
   if($saltLength < 10)
      $saltLength = 10;
   $salt = saltGen($saltLength);
   $hash = hash($hashMethod, $toHash . $salt);
   $hash = substr($hash, $saltLength-10);
   $hash = $salt . $hash;
   return $hash;
}

The cool thing about using this method is that, even if the hacker gets access to your database, AND your source code, it's nearly impossible for him to retrieve your original data, as he'd have to already know the length of the password (or whatever the data is), in order to retrieve the salt.

@chaines51 not to be nitpicky but I would not rely on someone not being able to guess the length of the password as a way to increase security. It is even easier to guess the length of a password, then just one char in a password. The idea itself is great, however, I think the practical implication is not that useful.

Based on the max and min length of the salt, it can only be 32 different lengths. But knowing that most passwords are around 6-8 chars, you are only left with about 2 or 3 lengths to guess on average, making it negligible.

I'd also make sure the salt is at least 20 chars. The rainbow tables of 14 chars are common (lookup for an input of combined length of 14 chars is possible). So I'd stay on the safe side and go for 20 which I don't see being generated in the near future.

Another good measure is to hash multiple times. I already posted this, but I thought I'd add a few example numbers.

On my machine, not impressive, it can do around 200.000 whirlpool hashes a second. Assume a user supplies a password of '4ac3xsdf' which is about the length of the average password. Since the password is made up of a-z0-9 then there are only 36 different characters. The number of combinations of these is 36^8.

If a pc can do 20.000 guesses per second, then it would take:

echo pow(36, 8)/(60*60*24*200000); // ~163 days

which is 163 days.

For a password of 6 chars, it takes just 3 hours. So I think one of the main things is to force your users to use 8 character or longer passwords.

If you just hash the password and salt together 1.000 times, you make an 8 char password unfeasible to brute force since it now takes 163.000 days to crack on 1 pc. If you make it 10.000 times, then you're sure it is infeasible for just about anyone.

I've posted this class before, but here is the updated version:

/**
 * Generate cryptographic Hashes for passwords
 *
 * Features:
 * 	Harderned against precomputation attacks like rainbow tables (using unique salts)
 * 	Harderned against brute force and dictionary attacks (using key stretching and optional secret key)
 *
 *  http://en.wikipedia.org/wiki/Password_cracking
 *
 *  Note: for PHP4 and lower, just remove the "public static" before function declaration
 *
 * @author [e-mail]
 * @link http://www.fijiwebdesign.com/
 * @version $Id$
 */
class Password_Hash
{

	/**
	 * Generate the Hash
	 * @return String
	 * @param $password String
	 * @param $salt String[optional]
	 * @param $iterations Int[optional]
	 * @param $secret String[optional]
	 */
	public static function generate($password, $salt = null, $iterations = 10000, $hash_function = 'sha1', $secret = '')
	{
		$salt or $salt = self::generateToken();
		$hashes = array();
		$hash = $password;
		// hash a sequence of hashes, each hash depends on the last one, so any implementation must hash each one individually
		$i = $iterations;
		while(--$i)
		{
			$hash = $hash_function($hash.$salt.$secret);
		}
		return implode(':', array($hash, $iterations, $hash_function, $salt));
	}

	/**
	 * Verify a password meets a hash
	 * @return Bool
	 * @param $password String
	 * @param $hash String
	 * @param $secret String[optional]
	 */
	public static function verify($password, $hash, $secret = '')
	{
		list($_hash, $iterations, $hash_function, $salt) = explode(':', $hash);
		return ($hash == self::generate($password, $salt, $iterations, $hash_function, $secret));
	}

	/**
	 * Generate a random hex based token
	 * @return String
	 * @param $length Int[optional]
	 */
	public static function generateToken($length = 40)
	{
		$token = array();
		for( $i = 0; $i < $length; ++$i )
		{
			$token[] =	dechex( mt_rand(0, 15) );
		}
		return implode('', $token);
	}

}

Here is a bit more on the topic, and a some examples of using the class.
http://www.bucabay.com/web-development/secure-password-hashing-storage-ph/

Please let me now if there is anything I can improve with that class.

[digital-ether]

A hash is meant to be one way. There is no way to actually guarantee it. True one-way functions are only theoretical at this point.

Not that I don't agree with you; that hashes should be considered one-way. Just pointing out that it is not an absolute truth, but rather a practical truth. We could very well see some of the more popular hashing algorithms being "broken" in the future.

Wouldn't you just love to prove it?
http://en.wikipedia.org/wiki/Millennium_Prize_Problems
I think I'll try and solve it tonight. Or maybe just buy a lottery ticket, better chance of winning that.

[Atli]

Yea, I actually solved P versus NP last weekend. Wasn't anything good on TV and my PC was busy compiling...
But I can't find my notebook now. Think my dogs got it.

O, well. What'cha gona do :P

[OmniX]

Sorry people I have been living under a rock the last 6 months.
Long live my thread! HA

Anyways what I gathered from 'digital-ether' alone crc32 is faulty but if used in conjunciton with another hashing algorithm, it is fine?

Also I liked the method mentioned:

function HASHITBAY_BE($toHash)
{
   $maxLength = 42; //maximum length of the salt
   $hashMethod = 'whirlpool' //encryption method...
   $saltLength = strlen($toHash)*3;
   if($saltLength > $maxLength)
      $saltLength = $maxLength;
   if($saltLength < 10)
      $saltLength = 10;
   $salt = saltGen($saltLength);
   $hash = hash($hashMethod, $toHash . $salt);
   $hash = substr($hash, $saltLength-10);
   $hash = $salt . $hash;
   return $hash;
}

I like this but why make a max string length at 42 why not make it 255 or something even longer!
The salt is being randomly generated based on the length of the requested hash string? and if its below 10 it is made equal to 10 else if its below 42 then stays and if its above 42 gets change to 42.
what is the code for the saltGen? (some random string creation I gather)
Using those variables hence why the salt is randomly generated and varies in size, hence why it be harder to guess the salt and therefore the hash? If I am correct I like it!

With the hashing class can you specify exactly what it is doing and when it would be called? like creating a random 6 character string each time a user creates an account, etc. Thanks.

Prolly just overwhelmed after reading pages and pages of code and topics :( Sorry! HA

[cwarn23]

If you wont listen then I shall show you the hard way. Attached to this post is a live dehasher written in Java which will check every combination hash to the specified digits to find the original string. Currently it will only dehash to 3 digits and any more it will freeze your computer. However with a mainframe it would be possible to do all 6 digits and very possibly more. Also the "exit dehashing" button doesn't work btw just so you know. Have fun dehashing.

[chaines51]

Once more, as everyone has tried to tell you, You are NOT dehashing. You're guessing at what the original string is. And nobody denied that you could do that. We denied that, at the moment, the ability to guess longer strings is rendered impossible in practice due to limitations on the computational power of modern machines.

Also, since you claimed earlier that you always code for the future, show me YOUR hashing/encryption script that is not 'dehashable'?

[cwarn23]

However if a person made a virus which took over the users cpu and lets say there were 500,000 copies of that virus sent out and the average computer could do 10,000 hashes per second then 500,000 x 10,000 = 5,000,000,000 strings could be hashed per second. That is an incredible amount of cpu not to mention the possibility of taking over googles mainframe in which case trillions more hashes per second could be done. So with the combination of taking over googles mainframe and planting a virus on every computer it would be possible to dehash at least a dozen digits if processing long enough. You see that's the thing. Hackers have access to unlimited cpu, unlimited ram etc so they can dehash whatever they want providing they can write a good virus. So with todays technology it is possible but if you still don't believe me then we will see who gets their hashes hacked. An example of this is the crc32 hash - it has already been hacked and it's only time until somebody scratches their head to crack the other hashes.

[OmniX]

Can you guys refer to people and not 'you' I assumed you guys were talking to me at first since I was the last both, didnt realize you had an argument between each other :D

[cwarn23]

Can you guys refer to people and not 'you' I assumed you guys were talking to me at first since I was the last both, didnt realize you had an argument between each other :D

Well when I say the word "you" I refer to the reader. Sorry if it was a bit confusing as many things in this topic are confusing to the untrained eye.

[OmniX]

I was reading up on salts and the consenses is that as long as they are used to stop precomputation attacks (aka rainbow tables, etc) the length required is meaningless only the value of the salt, which should be randomly constructed.

This statement correct?

PS: now dont be trival and start if my salt is only 1,2,3 charcters salt should be 5+ randomly constructed and stored in a database for retrieval.

[leviathan185]

I was reading up on salts and the consenses is that as long as they are used to stop precomputation attacks (aka rainbow tables, etc) the length required is meaningless only the value of the salt, which should be randomly constructed.

This statement correct?

PS: now dont be trival and start if my salt is only 1,2,3 charcters salt should be 5+ randomly constructed and stored in a database for retrieval.

why not just use the username or one of the existing data base fields as a salt? that way it will be unique for each password.

[digital-ether]

why not just use the username or one of the existing data base fields as a salt? that way it will be unique for each password.

I was reading up on salts and the consenses is that as long as they are used to stop precomputation attacks (aka rainbow tables, etc) the length required is meaningless only the value of the salt, which should be randomly constructed.

This statement correct?

PS: now dont be trival and start if my salt is only 1,2,3 charcters salt should be 5+ randomly constructed and stored in a database for retrieval.

@OmniX The length of the salt does matter. The salt should be random, yes, but it should also be long enough to make the precomputation attack infeasible.

I've also read those statements that the salt length does not matter, and this is incorrect. See http://en.wikipedia.org/wiki/Password_cracking#Salting

It states that the 12 bit salts used in earlier unix is not long enough to prevent precomputation. BCrypt for example uses a 128 bit salt. A comparatively complex salt in ASCII characters A-Za-z0-9 is about 23 chars.

There are many 14 character long rainbow tables available. So if a salt is not 14 characters, it is open to precomputation attacks by anyone wanting to do so.

@leviathan185 the username is not random enough and also too short.

Anyways what I gathered from 'digital-ether' alone crc32 is faulty but if used in conjunciton with another hashing algorithm, it is fine?

CRC should not be used at all, not even with a secure hash.

However if a person made a virus which took over the users cpu and lets say there were 500,000 copies of that virus sent out and the average computer could do 10,000 hashes per second then 500,000 x 10,000 = 5,000,000,000 strings could be hashed per second. That is an incredible amount of cpu not to mention the possibility of taking over googles mainframe in which case trillions more hashes per second could be done. So with the combination of taking over googles mainframe and planting a virus on every computer it would be possible to dehash at least a dozen digits if processing long enough. You see that's the thing. Hackers have access to unlimited cpu, unlimited ram etc so they can dehash whatever they want providing they can write a good virus. So with todays technology it is possible but if you still don't believe me then we will see who gets their hashes hacked. An example of this is the crc32 hash - it has already been hacked and it's only time until somebody scratches their head to crack the other hashes.

Even 500.000 PCs, brute forcing a single 8 character password hashed with whirlpool and using key stretching with 10.000 iterations would take about 3 years. No one would want to run 500.000 PCs for that long just for one password.

I've tried to make this point over and over. If you hash a password properly, it is infeasible to crack. Both in terms of time, and money. Anyone with 500.000 PCs has better things to do, then try to brute force a single password, whether legitimate or not.

[cwarn23]

I've already made my point and don't see any point in explaining it any further but I will say in the coming years we will see who makes the worlds best hash cracker.

[SKANK!!!!!]

how is anyone to know cwarn?