# Is there any defense against this kind of attacks? (key comparison attack, or something)

is there any defense against this kind of attack?

https://youtu.be/7U-RbOKanYs?t=974

I know someone who uses a password encryption hashing that generates the same length of keys as in this video and it makes me worried that those keys are equally vulnerable? (I don't know what kind of encryption hashing is used, nor do I want to know)

*Does it help to increase the length of the encrypted hashed keys?*

As I understand the attack:

Then the attacker takes a solved password, mutates the password in all kinds of ways, then encrypts hashes the mutated passwords & simply compare the newly encrypted hashed keys with the encrypted hashed keys in the database, and if the encrypted hashed gibberish is the same then the attacker knows that the newly encrypted hashed key is the same as that entry in the database.

(PS. what's the name of this type of attack?)

First things first: passwords are not (or at least, never should be) encrypted. They are hashed, a one-way transformation that takes an arbitrary input of arbitrary length and produces a constant-length (for any given hash algorithm), deterministic (the same input always produces the same output), and high-entropy (hard to distinguish from random) digest (also simply called a hash). For cryptographically-secure hash functions, there is no way to tell, given a digest, what input string produced it (and of course, there may be an infinite number of possible inputs that would produce it, since there are infinitely many possible inputs but "only" a limited number - such as 2^256, for 256-bit hash functions - possible outputs). In other words, you cannot reverse a hash function. Additionally, any changes to the input of a secure hash function, be they large or just a single bit-flip, generally produce a dramatic change in the digest.

Due to that, the standard attack on password hashing has long been to hash a large set of candidate passwords with the same algorithm, and check if any of the outputs match the digests in the dumped collection. Originally, this could be done with large, pre-computed lookup tables (called "rainbow tables") where a password, if it was present in the rainbow table, could be identified from its hash easily (simply search the table for the same digest). To protect against that, password hashing algorithms began to incorporate a "salt", which is a random string of bytes that are generated uniquely for each user, and are combined with the user's password when hashing. This makes rainbow tables useless unless the attacker already knows the salt of the user they want to crack, and even if they do they can only crack that specific user's password and have to generate an entirely new set of hashes for each other password. It also means to users who use the same password will have different digests, as their salts will be different.

However, even salted passwords can fall prey to a simple brute-force attack, because secure hash functions are generally optimized for performance (many of the places they are used, such as HTTPS traffic, require that they be computationally inexpensive). Chips that are optimized for performing the same operations on many distinct pieces of data in parallel - which is exactly what GPUs (graphics processing units) do - can brute-force an enormous number of hashes in a very short time (high-end GPUs can compute billions of hashes per second, for some of the common hash functions). Very, very few users are going to select a password so rare it's not one of the first few billion attempted, so such an approach can crack most passwords in a few seconds, for the cost of a few hundred dollars of graphics card. To defeat this, people started using slow hash functions for password hashing. The simplest way to make a slow hash is to take a fast hash, feed its output (and the salt) back into itself, and do that a few thousand more times; this is the basis of the PBKDF2 function, and it can slow down password brute-forcing attempts by a few orders of magnitude. Over time, more advanced password hashing algorithms have been developed, which resist not only GPUs but even customized chips (FPGAs or ASICs) designed to do nothing but brute-force passwords as fast as possible. No resistance is perfect, of course - the server still has to be able to hash your password when you log in, which puts a limit on how expensive the hash function can be made - but it can be literally millions of times slower to brute-force passwords protected by a proper password hashing algorithm (such as scrypt or argon2) than by a single-iteration fast hash (such as SHA-256). In other words, trying "the first few billion possible passwords" for each user goes from taking 1 second to taking a few weeks. Getting even a single password becomes expensive; breaking thousands of them becomes nigh-impossible.