Nice loop and good information!
Ok I think I have everything now to start my encryption, wait i mean hashing :p
Any helpful additional information would be much appreciated :)
Thankyou everyone for your helpful input, Regards X
PS: cwarn23 I now have a better understanding of your function and it looks great, thanks again.
Maybe we could have a competition of the most secure and fastest hash mechinism.
Unless we have an extremely talented hacker who can decypher hashes in minutes (or hours), we wont be able to know which is the most secure hashing mechanism. IMO, All these above posted functions are secure :)
the thing with hashes, is that they SHOULD NOT be able to be reversed. If the intention was to reverse it then it would be encryption.
Generally when i read about weak hashes being cracked its because of a design flaw in the algorithm, which contains math way above my head. Or someone has created a lookup table of common dictionary words, which is where salting the hashed string comes into play because even common words and combinations are no longer common.
I'd also be curious to see some comparative benchmarks regarding hashing a string once using a randomly generated salt as i provided, where the cpu intensity will be in the salt generation vs using a static salt(s) and then double hashing the string or any of the other methods cwarn provided.
If someone posts their test code and results, i'd be happy to run them on a handful of drastically different servers and post those results as well.
Very informative :)
I will remember this one for future reference. Rep+ for you all :)
I have just done a quick test on some of the different types of hash methods used in the article and the script is as follows:
<?
function truehash_a($hashzzz) {
return hash('crc32b',hash('whirlpool',$hashzzz));
}
function salthash_a($hashzzz) {
return hash('crc32b',hash('whirlpool','asdf'.$hashzzz.'jklh'));
}
function salthash_b($hashzzz) {
return hash('crc32b',hash('whirlpool',hash('crc32b',$hashzzz).$hashzzz.'jklh'));
}
function salthash_c($hashzzz) {
return hash('crc32b',hash('whirlpool',strlen($hashzzz).'18'.$hashzzz.'jklh'));
}
function salthash_d($hashzzz) {
$varzzz=4*strlen($hashzzz);
return hash('crc32b',hash('whirlpool','6'.$varzzz.'18'.$hashzzz.'jklh'));
}
function salthash_e($hashzzz) {
$sPossible = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!@#$%^&*()-+=[]{}|';
$iPossibleCount = strlen( $sPossible );
$sSalt = '';
for( $i=0; $i<$iLength; $i++ )
{
$sSalt .= $sPossible[mt_rand(0, $iPossibleCount)];
}
$sHash = hash('whirlpool', $hashzzz . $sSalt);
}
//=======================
$time_start = microtime(true);
truehash_a('absdefghijklmnopqrstuvwxyz');
$time_end = microtime(true);
$time = $time_end - $time_start;
$time=$time*1000;
$time=preg_replace('/([0-9]+)\./','0.00$1',$time);
echo "truehash_a() takes $time seconds to execute.<br>\n";
unset($time_start);
unset($time_end);
unset($time);
//- - - - - - - - - - - -
$time_start = microtime(true);
salthash_a('absdefghijklmnopqrstuvwxyz');
$time_end = microtime(true);
$time = $time_end - $time_start;
$time=$time*1000;
$time=preg_replace('/([0-9]+)\./','0.00$1',$time);
echo "salthash_a() takes $time seconds to execute.<br>\n";
unset($time_start);
unset($time_end);
unset($time);
//- - - - - - - - - - - -
$time_start = microtime(true);
salthash_b('absdefghijklmnopqrstuvwxyz');
$time_end = microtime(true);
$time = $time_end - $time_start;
$time=$time*1000;
$time=preg_replace('/([0-9]+)\./','0.00$1',$time);
echo "salthash_b() takes $time seconds to execute.<br>\n";
unset($time_start);
unset($time_end);
unset($time);
//- - - - - - - - - - - -
$time_start = microtime(true);
salthash_c('absdefghijklmnopqrstuvwxyz');
$time_end = microtime(true);
$time = $time_end - $time_start;
$time=$time*1000;
$time=preg_replace('/([0-9]+)\./','0.00$1',$time);
echo "salthash_c() takes $time seconds to execute.<br>\n";
unset($time_start);
unset($time_end);
unset($time);
//- - - - - - - - - - - -
$time_start = microtime(true);
salthash_d('absdefghijklmnopqrstuvwxyz');
$time_end = microtime(true);
$time = $time_end - $time_start;
$time=$time*1000;
$time=preg_replace('/([0-9]+)\./','0.00$1',$time);
echo "salthash_d() takes $time seconds to execute.<br>\n";
unset($time_start);
unset($time_end);
unset($time);
//- - - - - - - - - - - -
$time_start = microtime(true);
salthash_e('absdefghijklmnopqrstuvwxyz');
$time_end = microtime(true);
$time = $time_end - $time_start;
$time=$time*1000;
$time=preg_replace('/([0-9]+)\./','0.00$1',$time);
echo "salthash_e() takes $time seconds to execute. (mschroeder's hasher)\n";
unset($time_start);
unset($time_end);
unset($time);
?>The above code outputs something simular to the following:
truehash_a() takes 0.0000791549682617 seconds to execute.
salthash_a() takes 0.0000507831573486 seconds to execute.
salthash_b() takes 0.0000548362731934 seconds to execute.
salthash_c() takes 0.0000519752502441 seconds to execute.
salthash_d() takes 0.0000441074371338 seconds to execute.
salthash_e() takes 0.0000419616699219 seconds to execute. (mschroeder's hasher)And it turns out that if you add a fixed salt before and after the script it will speed up the script. So below is an example of a faster version of my truehash() function
function truehash($hashzzz) {
return hash('crc32b',hash('whirlpool','asdf'.$hashzzz.'jklh'));
}
//the above function in the results is salthash_a()Don't know why it speeds up but it just does. Also, you can check the comparison of the various speeds with the various examples and looks like the least secure hash (IMO) that relied on a salt is the fastest. Also another way to make sure that the hash cannot be dehashed (as I call it) by those mainframe computers (1.7TB cpu - 2001 worlds fastest computer), you could just remove half the characters from the hash with the substr() function. I hear a new IBM computer that can handle 100,000,000,000,000,000 floating point operations per second (Also known as Peta-flops) is comming out in 2011. It probably won't need a database to crack a hash as it would have enough cpu to keep on doing random hashes untill it gets the right one. And that I am guessing would only take maybe an hour per group of hashes.
just did a quick run of these on my local machine:
truehash_a() takes 0.00002598762512207 seconds to execute.
salthash_a() takes 0.000015020370483398 seconds to execute.
salthash_b() takes 0.000015974044799805 seconds to execute.
salthash_c() takes 0.000015974044799805 seconds to execute.
salthash_d() takes 0.000015974044799805 seconds to execute.
salthash_e() takes 0.00002598762512207 seconds to execute. (mschroeder's hasher)
**** These results are from php 5.3.0 the rest of the results will be from 5.2.8 installs
I did have to make one small change though:
function salthash_e($hashzzz) {
$sPossible = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!@#$%^&*()-+=[]{}|';
$iPossibleCount = strlen( $sPossible );
$sSalt = '';
for( $i=0; $i<10; $i++ )
{
$sSalt .= $sPossible[mt_rand(0, $iPossibleCount)];
}
$sHash = hash('whirlpool', $hashzzz . $sSalt);
}the for loop wasn't getting a length to check against so i just hardcoded it to 10.
However I get the same results with the speedup when adding static salts. That is very unexpected. I'll post additional test results from other machines tomorrow.
Sounds good keep up the work!
But if they are getting quicker, the more hashing/variables you introduced - it dosent make quite sense?
But if they are getting quicker, the more hashing/variables you introduced - it dosent make quite sense?
Well what I have pointed out is that with the php interperator, if you just input a variable then it will be slower than inputing a variable and string on each side. Below is an example
hash('whirlpool', 'asdf'.$hashzzz.'jklh');
//above will be faster than below
hash('whirlpool', $hashzzz);I do not know why that is but it makes a big difference for some odd reason.
Sorry for resurrecting an old thread. But it was referenced recently and I thought I'd add to it.
crc32b should not be used with passwords as it is an insecure hash function.
http://en.wikipedia.org/wiki/Cyclic_redundancy_check
It also generates hashes that are only 8 hexadecimal (base 16) digits long. Thus you have less then 16^8 possible hashes. (or less then 10 digits decimal)
A simple brute force such as:
$hash = hash('crc32b', hash('whirlpool', 'some password ^#d@C~'));
while($hash != hash('crc32b', $n)) { $n++; }
echo $n;will produce a collision for any crc32b hash within an hour on an average PC. Using crc32b basically makes the original hashing function (whirlpool in this example) useless.
Whirlpool produces a 128 digit hexadecimal. Thus you should keep the whole hash in order to preserve its effectiveness against attacks. Rehashing a whirlpool hash with another hash that produces a shorter hash probably isn't a good idea. If you're doing it to save space, there are better alternatives.
http://www.bucabay.com/php/base-conversion-in-php-radix-255/
You should also always salt passwords before hashing to make rainbow tables (and other precomputation attacks) unfeasible.
http://en.wikipedia.org/wiki/Rainbow_table
A rainbow table, is just a list of possible passwords, and their corresponding hashes. So it can be thought of as a simple database table with one column for the password, and the other for its hash. However, generating all the possible passwords for longer passwords, and more characters, requires a lot of space. So rainbow tables use a time-space trade off to save space. This however makes the generation of these tables computationally expensive. So if you salt a password, you effectively make it long enough that it would be infeasible to generate a rainbow table for it.
You should use a salt that makes precomputation attacks infeasible.
Currently rainbow tables with up to 14 characters length are common so more then 14 characters at minimum for a salt. There is no reason not to use a salt say 128 characters long with a password hashed with whirlpool.
Wordpress API generates some good salts: http://api.wordpress.org/secret-key/1.1/
Lastly, you need to make sure brute force is infeasible. A salt only works against precomputation attacks. With brute force, a known salt, does not hinder the attack at all.
Example:
For simplicity lets say only digits can be used for passwords:
$password = '123456789';
$salt = 'some really long random salt';
$hash = hash('whirlpool', $password.$salt );Now, even though the password is salted before hashing, we still have the problem that we can't rely on hiding the salt, so we have to consider it known. We also can't rely on the password being more then 10 digits, since most people do not remember such long passwords.
Thus a simple brute force on a single machine will still crack the password within an hour or two.
$salt = 'some really long random salt';
while($hash != hash('whirlpool', $n.$salt )) { $n++; }The only difference between a password of just digits in this example, and one of actual characters is that characters have a larger base, but it doesn't really change much considering most passwords will be a smaller set of the 26 alphabetic characters.
There are a few ways to thwart this. One is key stretching.
http://en.wikipedia.org/wiki/Key_strengthening
This is to hash the password and seed over and over in order to make a brute force N times slower, where in is the number of repeated hashing.
eg:
$password = '123456789';
$salt = 'some really long random salt';
$i = 1000;
while($i--) {
$password = hash('whirlpool', $password.$salt );
}
$hash = $password;This makes a brute force at least 1000 time slower.
What to note is that the slower your login is, the better. You can afford to wait a few milliseconds or seconds longer, but an attacker cannot.
The other solution is to use a computationally intensive hashing function such as bcrypt. http://www.usenix.org/events/usenix99/provos/provos_html/node1.html
Sources:
http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html
http://www.freerainbowtables.com/
http://www.codinghorror.com/blog/archives/000949.html
http://en.wikipedia.org/wiki/Cyclic_redundancy_check
http://en.wikipedia.org/wiki/Cryptographic_hash_function
code will produce a collision for any crc32b hash within an hour on an average PC.
That is true with any hashing function and that is what makes crc32 so good. It stores a large amount of data in minimum space with minimum recourses still with the concept. If however you are after uniqueness then all of the hash functions are no good and the following code will need to be used.
<?php
function hash_string($string,$extrachars='',$mixsault=true) {
$str=array();
if (strlen($string)>3) {
$len=floor(strlen($string)/2);
if ($mixsault==false) {
$long=str_split(substr($string,0,$len).$extrachars.substr($string,$len),1);
} else {
$string=substr($string,0,$len).$extrachars.substr($string,$len);
$long=str_split($string,1);
}
} else {
$long=str_split($string.$extrachars,1);
}
for ($i=0;isset($long[$i]);$i++) {
if (!isset($charconvert[$long[$i]])) {
$charconvert[$long[$i]]=true;
}
}
if ($mixsault==false) {
ksort($charconvert);
}
$i=2;
foreach ($charconvert AS $key=>$val) {
$charconvert[$key]=$i++;
}
$amount=count($charconvert);
unset($long);
$arr=str_split($string,2);
while (!empty($arr[0]) || $arr[0]===0) {
for ($i=0;isset($arr[$i]);$i++) {
$char=str_split($arr[$i],1);
$arr[$i]='';
if (empty($charconvert[$char[1]])) {
$tmp=1; } else {
$tmp=$charconvert[$char[1]];
}
$v=(($charconvert[$char[0]]*$tmp)+32+($amount-$tmp));
if ($v<256) {
$str[]=chr($v);
} else {
$str[]=$char[0];
$arr[$i]=$char[1];
$arr=implode('',$arr);
unset($arr);
$arr=str_split($arr,2);
unset($arrs);
}
unset($v,$tmp);
}
}
unset($arr,$char,$charconvert);
return implode('',$str);
}
echo hash_string('This is to be hashed','this is like a sault',false); //outputs: >–7FÊ3:JŽR
echo hash_string('This is to be hashed','this is like a sault',false); //outputs: >–7FÊ3:JŽR
echo hash_string('This is to be hashed','this is like a sault',true); //outputs: 1=BF^@=BFN‘jG½ftjF:Ä
echo hash_string('This is to be hashed','this is like a sault',true); //outputs: 1=BF^@=BFN‘jG½ftjF:Ä
echo hash_string('This is to be hashed'); //outputs: .:?C[XaA7—
echo hash_string('This is to be hashed'); //outputs: .:?C[XaA7—
echo hash_string('This is to be hashed','',false); //outputs: ;ƒ4?™07G{O
echo hash_string('This is to be hashed','',false); //outputs: ;ƒ4?™07G{O
?>So truly a custom hash function is the ONLY way to prevent collisions and to have better security.
That is true with any hashing function and that is what makes crc32 so good. It stores a large amount of data in minimum space with minimum recourses still with the concept. If however you are after uniqueness then all of the hash functions are no good and the following code will need to be used.
....
So truly a custom hash function is the ONLY way to prevent collisions and to have better security.
CRC32b is not designed to be a secure hash: http://en.wikipedia.org/wiki/Cyclic_redundancy_check
There is nothing wrong with SHA256, Whirlpool etc. are designed to be secure thus they should be used to hash passwords.
It would be very hard to develop a secure hashing algorithm. You'd have to be contributing a lot to security in order to develop a hashing algorithm that is better then the current ones.
As far as collisions go, it is impossible not to have but in practice they do not occur for a sufficiently large hash like those generated with whirlpool.
There is nothing wrong with SHA256, Whirlpool etc. are designed to be secure thus they should be used to hash passwords.
Are you kidding, no hash is secure unless you hash the hash. If you type in "dehasher" in google my website comes up on the first page "global programming syntax" and with my website, sha1, crc23 and crc23b will have a reverse lookup to at least 4 digits. My database is being populated each day with millions of results and will upload the database late November. So currently the database is not publicly viewable but will be soon and I have plans to expand it to a monster database as I have made the database structure efficient for mysql query lookup. So with plans like mine, no hash is secure as long as it follows a standard format. That's why you hash the hash or use a custom hashing function.
Are you kidding, no hash is secure unless you hash the hash. If you type in "dehasher" in google my website comes up on the first page "global programming syntax" and with my website, sha1, crc23 and crc23b will have a reverse lookup to at least 4 digits. My database is being populated each day with millions of results and will upload the database late November. So currently the database is not publicly viewable but will be soon and I have plans to expand it to a monster database as I have made the database structure efficient for mysql query lookup. So with plans like mine, no hash is secure as long as it follows a standard format. That's why you hash the hash or use a custom hashing function.
SHA256 are Whirlpool are definitely secure. For most applications sha1 and md5 are also secure, though many will recommend using SHA2 and up. http://en.wikipedia.org/wiki/SHA_hash_functions
You cannot save all the hashes from SHA256 or Whirlpool in a database, or even SHA1.
If you take SHA1 for example, which generates a 160 bit hash, then to store all the possible hashes would require about:
(2^160)*160*2 ~= 10^50or in PHP:
$bits = pow(2, 160)*160*2; // ~4.68E+50(multiplied by 2 since the inputs will take up as much space as the hashes)
You can take away 7 decimal points (8*10^6) in order to get the number of gigs which is around 10^43 Gigs. (10 with 43 zeros)
So it isn't possible to save that amount in a MySQL database. Thus the need for rainbow tables.
If you do the same thing for SHA256 which produces a 256 bit hash like the name suggests then you have to save ~10^72 Gigs.
To add to the problem of storage, you cannot compute all the possible hashes on a single PC due to physical constraints. See: http://en.wikipedia.org/wiki/Brute_force_attack
under "Theoretical Limits".
Essentially computing all the possible hashes, is a brute force. (Even though you're saving to DB and doing lookups later, the generation of the DB is through brute force). Any hash function that produces more then 128bit hashes will require a considerable amount of parallelized computing to computing even part of the possible hashes. This is why rainbow tables only cover certain characters and not the full ASCII table. Usually a-zA-Z0-9 and a few special characters.
As an example.
The amount of time required to break a 128-bit key is also daunting. Each of the 2128 (340,282,366,920,938,463,463,374,607,431,768,211,456) possibilities must be checked. A device that could check a billion billion keys (1018) per second would still require about 1013 years to exhaust the key space. This is a thousand times longer than the age of the universe, which is about 13,000,000,000 (1.3×1010) years.
AES permits the use of 256-bit keys. Breaking a symmetric 256-bit key by brute force requires 2128 times more computational power than a 128-bit key. A device that could check a billion billion (1018) AES keys per second would require about 3×1051 years to exhaust the 256-bit key space.
http://en.wikipedia.org/wiki/Brute_force_attack
SHA256 is produces 256 bit hashes. So you can compare it to trying to brute force a 256 bit cipher key, which is not possible.
The attacks on hashes are based on problems with the way they are generated. For example, not using a salt, makes the input (the password) a very small range. Thus it will lie within the range covered by a rainbow table.
If a salt is used, but the salt is known to the attacker, then they can create a brute force attack, for which the running time will depend only on the complexity of the password, which is normally not complex.
So the main concern is how to hash passwords securely. I've already cited a few links to resources on the topic in my first post in the thread.
Sure it may not be possible to store every combination as there are infinit possible hashes due to an infinit length that can be hashed (eg. pi). However, it is still possible to hash at least the first 5 digits and every word from the dictionary. I have a vps for all of this and I have encrypted the hashing data so that it only takes up half the space. I know you may say this is not possible but I am all about doing the impossible and usually I succeed. Also could you give me a reference about rainbow tables as they sound colorful and needed. Currently the technique I'm using is by having 3330 tables each storing a proportion of the data but discovered more would be needed.
Sure it may not be possible to store every combination as there are infinit possible hashes due to an infinit length that can be hashed (eg. pi). However, it is still possible to hash at least the first 5 digits and every word from the dictionary. I have a vps for all of this and I have encrypted the hashing data so that it only takes up half the space. I know you may say this is not possible but I am all about doing the impossible and usually I succeed. Also could you give me a reference about rainbow tables as they sound colorful and needed. Currently the technique I'm using is by having 3330 tables each storing a proportion of the data but discovered more would be needed.
There is a finite set of possible hashes, since hashes are of a finite length.
You're right, you don't need to store all the hashes, such as what rainbow tables do
http://en.wikipedia.org/wiki/Rainbow_table
Or special hash indexes probably similar to your approach:
http://www.sha1-lookup.com/
http://tools.benramsey.com/md5/
http://gdataonline.com/seekhash.php
etc.
None of these (precomputation attacks) will work on a salted password as I mentioned before.
one time i made a password encryption with pure php it went like this:
$password = sha1($password);
$password = md5($password);
$password = ENCRYPTED!
one time i made a password encryption with pure php it went like this:
$password = sha1($password);
$password = md5($password);
$password = ENCRYPTED!
That's the kind of stuff I was talking about except I would recommend using the md5 or md4 algorithms as I have read reports that they don't always produce the same md4/md5 hash every time. It is a bug in the algorithm and therefore the md4 and md5 algorithms should be ignored.;) But other than that, great way of explaining what I was talking about earlier on.
im pretty sure that is ok o use just sha1 being its a forty char long encryption.
An awesome thread :) Some amazing bits of advise here.
I guess it depends on the application. For basic login systems which don't protect sensitive data, something like a double-hashed randomly salted string (with sha1()) will work fine.
i dont understand how to do randomly salted.
i dont understand how to do randomly salted.
You could, for example, have:
$hash = substr( sha1(rand()), rand(1,30), 10);As the random salt - i.e., a 10 character long string, from the sha1() sum of a random number.
Then do:
$encPass = sha1( sha1($origPass) . $hash );or something like that. Then store both variables in a database for when it comes to checking the login.
That's the basic idea, anywhoo.
im pretty sure that is ok o use just sha1 being its a forty char long encryption.
I wonder what the world will be like in a few years time when that 4TB cd comes out where TB's of diskspace can be stored on just a few disks. So it would be possible to make to have a cd collection containing compressed dehashing data to the 7 digits. That's only the near future as in a few years. In maybe 15 years we may be able to store 15 digits on server farms during the time when a cd holds 23PB (petabytes) and each harddrive in the server farm contains 256EB (ExaBytes = 1024^6 bytes). What is your advice on preventing serverfarms dehashing where a single computer can hold 256EB and there could be hundreds of computers on a hackers personal server farm. Well Google will need somewhere to store all of those youtube videos in the future. That is when the world goes into crises which I am already thinking about preventing today. So my advice, don't wait till the year 10,000 for the millennium bug. Fix it right away.
I wonder what the world will be like in a few years time when that 4TB cd comes out where TB's of diskspace can be stored on just a few disks. So it would be possible to make to have a cd collection containing compressed dehashing data to the 7 digits. That's only the near future as in a few years. In maybe 15 years we may be able to store 15 digits on server farms during the time when a cd holds 23PB (petabytes) and each harddrive in the server farm contains 256EB (ExaBytes = 1024^6 bytes). What is your advice on preventing serverfarms dehashing where a single computer can hold 256EB and there could be hundreds of computers on a hackers personal server farm. Well Google will need somewhere to store all of those youtube videos in the future. That is when the world goes into crises which I am already thinking about preventing today. So my advice, don't wait till the year 10,000 for the millennium bug. Fix it right away.
no im not sure i follow this very well. i dont think that its too hard to hack right now. but its illegal and people shouldnt do it just because. theyh could go to jeal etc..
no im not sure i follow this very well. i dont think that its too hard to hack right now. but its illegal and people shouldnt do it just because. theyh could go to jeal etc..
It isn't illegal to dehash a hash unless you intend to use the crack for stealing passwords etc. So if for example you wanted to encode data and decode it using hashes that is not illegal. It is only illegal once you start stealing peoples passwords and one day a hash function on it's own will be very useless unless additional heavy security measures are taken.
It isn't illegal to dehash a hash unless you intend to use the crack for stealing passwords etc. So if for example you wanted to encode data and decode it using hashes that is not illegal. It is only illegal once you start stealing peoples passwords and one day a hash function on it's own will be very useless unless additional heavy security measures are taken.
oh well i only "hash" passwords. theres nothing else o my site that needs encrypting
oh well i only "hash" passwords. theres nothing else o my site that needs encrypting
I was meaning that in the future todays hash functions will eventually be used as encryption functions as they would in the future easily be decrypted. But the technology is till to come in many many years so most people don't worry about that part of future security unlike myself who secures every piece by future standards.
@CWARN23 i got to change my hashing technique just because of you though it a nice piece of ingenuity you get going with your site and these definitely is an interesting thread big up.shalom shalom
well i tried to log into m site today i get zero sized error. i think it has to do with the host. because i dont dehash my passwords they want to make my site unusable? awful.
well i tried to log into m site today i get zero sized error. i think it has to do with the host. because i dont dehash my passwords they want to make my site unusable? awful.
That's nothing to do with encrypting/decrypting, just means that something went wrong on your host's end with (most probably) Apache.
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
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.