Best encyption methods? - Page 4

how is anyone to know cwarn?

What do you mean. How is anyone to know weather I'm correct? Could you expand that question as it has little detail.

no. how is anyone to know in a year

digital-ether:

so crc32b should not be used at all?
ive read what you wrote, you put the final output as crc32b if you change the final output to a different hash, you could still use crc32b?

I read that short paragraph on salting and it just states on how encryption works in conjunction with salts based on certain algorithms. It also states salts are used to customize the output for the required hash, so with that the length of a salt will not matter as it just used to customize the output?

Also with rainbow tables and so forth.
Do they contain a list of WORDS / SALTS / HASHES or ALL?

Thanks, Regards X

so crc32b should not be used at all?
ive read what you wrote, you put the final output as crc32b if you change the final output to a different hash, you could still use crc32b?

CRC is a non-secure hashing algorithm, used to verify data integrity. It has no place in security algorithms.

Even if you re-hash the output of crc32 using a stronger hashing algorithm, you aren't making it any more secure. The output of any hash only has a finite amount of possible values, which the final output of the hash will reflect. If the input for a 512bit hash can only be 32bits long, then you can crack the 512bit hash just by testing all the 32bit values for the input.
The output of crc32 is tiny when compared to something like Whirpool or SHA512. There is just no point in bothering to use it.

There are stronger, better algorithms available. It's best to just forget CRC, and the other small algorithms. (MD4/5, SHA1, etc...)

so with that the length of a salt will not matter as it just used to customize the output?

Keep in mind that attacks like these aren't actually breaking the hash, they just guess the password a few billion times until they find a match. The more complex your password is, the harder it is to guess.

Salts are used to make it harder to guess the phrase that created the hash. The more complex the salt is, the wider the range the "brute-force" attack will have to cover.

Rainbow-tables have precomputed hash values for dictionary words, some including salts up to a certain length. To protect yourself from such tables, your salts much exceed that length. The longer your salts, the larger the rainbow-table has to be to have a change to match your hash. And note, that that size increases exponentially, so each extra char you add to your salt increases the size of the rainbow-table needed by 16. So using a 32 char salt rather than a 4 char salt makes a massive difference.

im pretty sure that thse attacks are harsh

I gather what you are saying " Atli ", but if your rehashing a hash from crc32b it is still valid, like as you stated your still making an xxx hashing not shorten the length of a hash but like you stated it would be absurd to use crc32b as your only means of protection.

Salt I can understand, I guess it just comes down to personal taste, depends how much junk you want to add to the end of the string I guess to make it that unique?

At this rate why not quadriple whirlpool and salt a hash, I guess it comes down to the point of meaningful and meaningless code dependent on the coders opinion... lol

Keith once wrote a login System. I'm basing my code on that (even borrowed some stuffs as they are). So guys, can you rate the security of it? Also what About IP attacks. I heard the term but don't know how it applies to security/password.

Not to hijack the thread though ;)

I gather what you are saying " Atli ", but if your rehashing a hash from crc32b it is still valid, like as you stated your still making an xxx hashing not shorten the length of a hash but like you stated it would be absurd to use crc32b as your only means of protection.

Salt I can understand, I guess it just comes down to personal taste, depends how much junk you want to add to the end of the string I guess to make it that unique?

At this rate why not quadriple whirlpool and salt a hash, I guess it comes down to the point of meaningful and meaningless code dependent on the coders opinion... lol

CRC32 should NOT be used at all. Not as the last hash output, or before you hash it again with a secure hash. Just not at all.

Even if you take a crc32 hash and rehash it with sha256. It doesn't strengthen the crc32 hash.
The number of different hashes CRC32 can produce is only 2^32 = 16^8 = 4.294.967.296.

So you're basically reducing the number of different hashes someone needs to check, down to 4.294.967.296. This only takes a few minutes on an average PC. If you used a precomputed table of CRC32 hashes, it would take only a few seconds.

The reason they only have to check that number, is that CRC32 thus only produces a subset of the sha256 hashes (4.294.967.296 unique SHA1 hashes). If you had not used CRC32, the password would lie in more or less a random distribution among the sha256 hashes.

Salt I can understand, I guess it just comes down to personal taste, depends how much junk you want to add to the end of the string I guess to make it that unique?

It is not personal taste. If you do not use a salt that is longer then 14 characters, then it will take mere seconds to retrieve the password and salt from a rainbow table. You need to use a salt that is longer then what is in rainbow tables, or other precomputed data.

At this rate why not quadriple whirlpool and salt a hash, I guess it comes down to the point of meaningful and meaningless code dependent on the coders opinion... lol

You should rehash a lot more then 4 times. Rehash it 1000 times at least. None of this is meaningless code depending on coder opinion. You'll have to read the whole thread as I cannot keep reposting the sources.

As a start read: http://en.wikipedia.org/wiki/Password_cracking

The number of iterations of key strengthening, and the length of the salt are not mere coder opinion, they are required. The same techniques mentioned here are used in production systems today to strengthen hashes. I've already posted these references also, please see older posts in the thread.

Keith once wrote a login System. I'm basing my code on that (even borrowed some stuffs as they are). So guys, can you rate the security of it? Also what About IP attacks. I heard the term but don't know how it applies to security/password.

Not to hijack the thread though ;)

Whoops! I didn't provide a link; Here it is
http://www.daniweb.com/forums/post951182.html#post951182

Hijack as you please, I just might shoot ya :D

Thanks digital, alot of intresting information contributed to this topic.

If anyone else has anything to add dont be afarid to share or ask!

Else speak to you all soon!

Note: There are 3 hashing methods with 8 characters adler32/crc32/crc32b I am assuming none of these should be used? That begs the question but why were they created in the first place?
I gather any other hashing methods are fine as the next shortest one is 32 characters!

They were created for the purpose of data integrity. If you can hash two files and get the same result, you can reasonably assume that they're the same. (Of course, it'd be better to do with whirlpool, etc, as they'll generate *more* unique hashes, to better guarantee equality).

I gather any other hashing methods are fine as the next shortest one is 32 characters!

I will appreciate to see your conclusion on the matter before thread marked solved!

They're not really safe. I mean, with 32 character hashes, you're a lot more secure than the 8 character hash, but a whirlpool, sha512, etc hash is even more secure, and should be used whenever possible.

Im waiting for digital response to adler32 being useless, as I gather the logic behind crc32 being useless will be of equal response.

Yes, the logic behind not using adler32 is the same as not using crc32, and any other hashing algorithm that produces such a small hash.

no. how is anyone to know in a year

It will be posted on the internet and possibly on daniweb. I'm not sure what else you were thinking about?

Anyways, I have made a dehasher that can dehash up to 6 digits depending on what characters are to be dehashed and time allowed. You can grab a copy of the SHA1 dehasher from the attachment on this post to see how insecure SHA1 is IMO. Enjoy dehashing the >=6 digit hashes.:)

you said 6digits depending on characters?

You mean 6 characters depending on wether they are of alpha or numeric value?

So in other words, it goes through all the possible 6 character combinations of sha1?

Sounds neat, how long does it take to do 6? 7? 8? etc?

So in other words, it goes through all the possible 6 character combinations of sha1?

Sounds neat, how long does it take to do 6? 7? 8? etc?

Well I have made a set of tickboxes for if you think the original string contained upper case letters, lower case letters, numbers, or symbols. So those are four options and the more that are selected the longer it will take because there will obviously be more hashes to check when including more types of characters. With all 4 tickboxes ticked it can do 2 digits in 50 seconds or 1 digit in less than 1 second. However with some tickboxes disabled it will be faster and you can choose how far in to stop processing.

Just a note: on the previous attachment you will need to select the combo box before anything else otherwise it becomes impossible to select a different number of characters. Have now fixed that in my latest version.

Note: There are 3 hashing methods with 8 characters adler32/crc32/crc32b I am assuming none of these should be used? That begs the question but why were they created in the first place?
I gather any other hashing methods are fine as the next shortest one is 32 characters!

adler32 and crc32 were developed for a different purpose then security. They are used more for verifying data integrity or error detection.

They do not provide means to secure against intentional data modification, since this wasn't the design goal.

Wikipedia explains all this:
http://en.wikipedia.org/wiki/Adler-32
http://en.wikipedia.org/wiki/Cyclic_redundancy_check

As also mentioned, the hashes produced are short enough that all possible hashes can be computed by a single computer in minutes.

Notice that the hashes used today are much longer then those used in the past. We have to keep using longer and longer hashes because computers are becoming more efficient.

The only reason adler and crc is used for data integrity instead of larger hashes is because they are faster, yet do the job of error detection very well.

Anyways, I have made a dehasher that can dehash up to 6 digits depending on what characters are to be dehashed and time allowed. You can grab a copy of the SHA1 dehasher from the attachment on this post to see how insecure SHA1 is IMO. Enjoy dehashing the >=6 digit hashes.

You might be interested in the list of top password crackers published by Insecure.org: http://sectools.org/crackers.html
They basically do what you are doing with compiled languages, making it much faster then PHP. They also make use of weaknesses in the hash algorithms as well as precomputed data from dictionaries and optionally rainbow tables. It makes them very efficient in cracking non-salted short passwords. But even these tool are useless when you hash passwords the way already shown in earlier posts in the thread (eg: salt, key stretch).

btw: if you're after 6 character passwords, then probably the fastest methods is just posting the hash into google search. Again showing the need for salting passwords.

The hash function is a function that allows you to utilize numerous kinds of algorithms. if you run print_r(hash_algos()); it will give you an array of the hash algorithms available on your system. Whirlpool is just one type of hash, like MD5, SHA1 and CRN32

A salt is basically adding a random string(s) to whatever you are encrypting or hashing:

<?php

$sSalt = '8*S&AsEc4qUs';
$sHash = hash( 'whirlpool', $sString . $sSalt );

echo $sHash;

so if the user decided to make their password "password" the hashed password would actually be for the value of "password8*S&AsEc4qUs" which would prevent someone from using a hash lookup database as it ensures that the users password has some form of complexity to it. This is assuming that someone was looking at the actual hash stored in the database and not trying to forge logins from a from.

I *believe* phpBB3 uses the random salt for every password option i mentioned in my previous post. It would be something like this:

<?php

function getSalt( $iLength = 10 )
{
	$sPossible = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!@#$%^&*()-+=[]{}|';
	$iPossibleCount = strlen( $sPossible );
	
	$sSalt = '';
	for( $i=0; $i<$iLength; $i++ )
	{
		$sSalt .= $sPossible[mt_rand(0, $iPossibleCount)];
	}
	
	return $sSalt;
}

$sPassword  = 'password';
$sSalt = getSalt();

$sHash = hash('whirlpool', $sPassword . $sSalt );

//Store  $sHash and $sSalt in the database.

Although I imagine when you get into generating random salts, you are going to be just as comparable to double hashing the same string, in terms of cpu usage and at some point you start to cross the line of security by obscurity.

how to decrypt this encrypt? :yawn:

Good thing you resurrected a 2 year old thread...

To simply answer your question, the idea of a hash is to be a one way algorithm. The only way you could "decrypt" a hash would be to generate hashes until your found a match.

If you want to encrypt and decrypt then you want to use encryption, not hashing.

In the future please don't revive a thread this old.

Don't bring up old thread, start a new one!