Hash and encryption? What is a hash value

Hashing and encryption

There is a common misconception that hashing and encryption are the same thing. They're not. Hash is irreversible. Take the following example:

$ echo -n Password123 | md5sum
42f749ade7f9e195bf475f37a44cafcb -

We pass the string "Password123" to the MD5 algorithm (algo), which does the math and returns the generated hex-encoded hash. The only way to get the same hash output value is to input the algo raw. There is a conflict, but we can discuss it later.

Most hash algorithms output a hexadecimal-encoded, fixed-length binary string. Others, such as this example, use base64-encoded strings as output. Note that the length is always the same:

{SHA} uNF8eZRJ8jmr8WTjyocRJPVpe7w=
{SHA}lqdu/Zr6o2dgIER8Up1/7lcUtgw=
{SHA}qYUOwLMlDEuukA5HCT4LR1kQzco=
{SHA}MXZBCpyWJ7TTs1w2kgGJslwNwTg=
{SHA}2sAPLaUh9Mz0bI+XxKEg7qyABe8=

TL; Dr.

Encryption is reversible, hashes are not

I don't want to talk too much about encryption (because those things are for books), but it's important to be able to distinguish between hash strings and encrypted strings. Encryption typically fills a string that meets a specific length before encryption occurs. It also requires a key (or password) to decrypt. If you are using an encrypted password, the string will vary depending on the length entered. If you see a bunch of ciphertext passwords that vary in length, you're probably dealing with encryption rather than a hash. AES-256-CBC Example Encrypted string and associated plaintext (key "ASDF"):

foobar             | U2FsdGVkX19G+KtytNHdj6yH2AVvX26pEmtunS/PRnU= 
foobarfoobar       | U2FsdGVkX18sPpIvN6nVh68lOUCcb3gR2fKbCCnBxog= 
foobarfoobarfoobar | U2FsdGVkX1/EOnUt57TCW4Rh0EdNnWX+lDatuQv2xEXXeAeowW0XG/EXJUe9aSUz 

$ cat encrypted_passwords 
U2FsdGVkX19G+KtytNHdj6yH2AVvX26pEmtunS/PRnU= 
U2FsdGVkX18sPpIvN6nVh68lOUCcb3gR2fKbCCnBxog= 
U2FsdGVkX1/EOnUt57TCW4Rh0EdNnWX+lDatuQv2xEXXeAeowW0XG/EXJUe9aSUz 

$ for i in `cat encrypted_passwords`;  do echo $i | openssl enc -base64 -d -aes-256-cbc -pass pass:asdf;  echo; done. 
foobar 
foobarfoobar 
foobarfoobarfoobar

Now you might be thinking: You might be right. However, the critical material must be accessible to the system, meaning that essentially a plain text master password is located somewhere—whether as an RSA key, a password, or a password in a file, embedded in a database, hard-coded in an application, or somewhere in memory. pfft, no one's going to use asdf as the key to encrypt their users' passwords

Same string using MD5:

foobar             | 3858f62230ac3c915f300c664312c63f 
foobarfoobar       | 59faa421729e846dd800dce59943bfc0 
foobarfoobarfoobar | 1352aadab322d1a033c27964be0965db

Hash passwords are far from perfect, in fact they are kind of bad, but they are worse than encryption because of what they are trying to achieve. Users select the absolute minimum requirement more frequently than not, and it can also be used on multiple sites. Many "hacks" are actually just credential reuse attacks. If the initial compromise was to use encryption, then the only effort an attacker would have to make is to find the key to decrypt all the passwords. For hashes, they at least need to make an effort to crack them. When used with modern algorithms such as sha512crypt, bcrypt, scrypt, or argon2, hash values can require significant effort to crack.

Marinating

Salting is adding a string to the password before the hash. The salt of each hash should be unique, usually chosen randomly, because the key is to make the same plaintext "password" hash value different every time. This makes life difficult for password crackers, because in order to check the Word "password" for each of the 1,000 users, each user has a unique SALT, and they must do this 1,000 times - once per user/SALT. This also means that they cannot effectively use precompiled dictionaries or rainbow tables (usually...) because they require a custom per salt.

The website sometimes messes this up and uses universal salt for all users; This defeats the purpose.

The following are the salted SHA1 hash values:

b353977827f67a4ae0318f3a9447fae1c13d9d90:b8d18ca 
|___________________________________________| 
                  hash                  |  salt 
                                        | 
                                    separator

The plaintext of this hash is "password". It has a salt value of "b8d18ca" and uses SHA1 ($salt.$pass) in the API. This means that the algorithm takes the plaintext of the password, generates salt, and adds it before the plaintext. When a website or application attempts to verify your password in the future, it takes your plaintext password as input, reads the salt value from the stored Hash, adds it before the password you chose, and compares the generated Hash value to the stored Hash value. Cracking If it is not known that part of it is salt, the hash will produce the following plain text:

b8d18capassword

Because the algorithm takes plain text input, salt and the generated hash value can remain transparent to the user. When cracking, if the algorithm is salty, we need to know the salt so that we can provide it when generating the candidate plaintext.

If implemented properly, salting can make cracking more time-consuming. With a random salt, you force the Cracker to waste time trying to crack the hash value of the salt that does not match. This roughly completes the effort required for device_speed/number_of_salts, as we need to generate a candidate for each salt. If the salt is static, then the math is the same... speed_of_device / 1. Another way to look at it:

Our GTX 980 cracks SHA1($salt.$pass) at 3576.8 MH/s or 3.5 billion candidates per second 
Our hashlist contains 1000 unique salts 

3,500,000,000 / 1000 = 3,500,000 candidates per second

This is three orders of magnitude slower, losing 99.9%. When using static salt, it looks like this:

Our GTX 980 cracks SHA1($salt.$pass) at 3576.8 MH/s or 3.5 billion candidates per second 
Our hashlist contains 1 unique salt 
               
3,500,000,000 / 1 = 3,500,000,000 candidates per second

If this doesn't make sense, keep reading, we'll have a nice chart later...

Iteration

Another common improvement compared to simply "hash this plaintext," is that "hash this plaintext, then hash that result, then hash that result" is repeated thousands of times. this allows the password cracker to perform thousands of operations when trying a single candidate password. this is called iteration, loop, or variable cost. Some password hashing algorithms use hard-coded iteration rounds; Other Git. Make it configurable as part of the Hash itself. For example, md5crypt() uses MD5, including salt, and loops exactly 1000 times. sha512crypt() uses sha512, includes a salt, and loops a configurable number of times (5,000 by default).

Iteration primarily affects the computational cycle cost of the hash algorithm, not its memory footprint or other factors. These are also important attacks when designs are optimized to resist certain types of hash types, but that's too weedy to discuss here.

The impact of hash type on cracking speed

Let's look at some examples to demonstrate the impact of hash algorithm selection, whether it's salted, using multiple iterations, etc. Suppose an attacker collects the hash values of 1,000 users from an infected website, and they only want to conduct a simple attack to test the hash value of each password—143 million candidate passwords.

The type of hash used by an infected website will have a huge impact on the time it takes for an attacker to pass the attack. This is a chart (relatively, approximately) showing how many seconds it takes to complete the attack, depending on the hash type used. Standard graphics card:

Well, that doesn't work! The strongest hash type is much slower, but faster. The type is simply flattened to nothing. Let's try the same data size again using logarithmic x-axis time. As the bars move from left to right, they will increase to the power of 10:

So some points: When you want to crack some password hashes, single rounds are easier than multiple rounds and unsalted than salted. Conversely, when certain companies or websites announce a data breach containing user data, a) the password should ideally be hashed, not just plain text; b) They should preferably be salted, not just hashed; c) They'd better have been using a powerful multi-round salted hash, not just a single round.

Identify the hash type

Before attempting to crack a given cryptographic hash, it is up to the cracker to figure out which hash algorithm is used to implement it. Identifying the hash type is usually simple, but not always. Crackers typically make educated guesses based on clues such as hash length and format. Ultimately, the only way to be sure if the hash type guess is correct is if the hash has been cracked.

There are some excellent resources for this task here and here, all of which show what common hashes look like.

The hash-identifier package (available here) is available in Kali Linux to help identify unknown hash types.

Collision

A collision occurs when two different inputs result in the same hash output. This sucks (obviously). For passwords, this probably means that I may not have cracked your actual password, but since I found an input that produces the same hash value, I can use plain text values to trick the system into thinking the password is legitimate.

Microsoft Office has used an algorithm in its document protection that has been prone to conflict for years. It is not uncommon to find multiple conflicts with a single hash, all of which unlock the document.

Once a conflict is discovered, the algorithm is actually broken. If it happens once, it is statistically likely to happen again. The only thing holding us back is time and processing power. As algorithms become more robust, it takes more power and time to generate candidate algorithms and compare hash outputs to search for them. As a result, designers are becoming increasingly adept at creating algorithms that are less prone to conflict.