Return to Answer

Databases generally store hashed passwords (as they should), but some store it plaintext (just remember this!). If someone were to find a hash collision that matched the stored, unsalted, and hashed password, then yes, they would be able to use that collision to login, because the client would send the password to the server, the server would calculate the hash and compare it to the one in the database. Since the two match (different input, same hashed value), login would succeed. However, I might like to add, it's more computationally feasible that one would bruteforce the password as opposed to finding a collision, especially with the generally small size of a password.

Databases generally store hashed passwords (as they should), but some store it plaintext. If someone were to find a hash collision that matched the stored, unsalted, and hashed password, then yes, they would be able to use that collision to login, because the client would send the password to the server, the server would calculate the hash and compare it to the one in the database. Since the two match (different input, same hashed value), login would succeed. However, I might like to add, it's more computationally feasible that one would bruteforce the password as opposed to finding a collision, especially with the generally small size of a password.

Databases generally store hashed passwords (as they should), but some store it plaintext. If the password is salted, it would make collision much more difficult without knowledge of the salt. If someone were to find a hash collision that matched the stored, unsalted, but hashed password, then yes, they would be able to use that collision to login, because the client would send the password to the server, the server would calculate the hash and compare it to the one in the database. Since the two match (different input, same hashed value), login would succeed. However, I might like to add, it's more computationally feasible that one would bruteforce the password as opposed to finding a collision, especially with the generally small size of a password.

Databases generally store hashed passwords (as they should), but some store it plaintext (just remember this!). If someone were to find a hash collision that matched the stored, unsalted, and hashed password, then yes, they would be able to use that collision to login, because the client would send the password to the server, the server would calculate the hash and compare it to the one in the database. Since the two match (different input, same hashed value), login would succeed. However, I might like to add, it's more computationally feasible that one would bruteforce the password as opposed to finding a collision, especially with the generally small size of a password.

Databases generally store hashed passwords (as they should), but some store it plaintext. If the password is salted, hash collision is (nearly) impossible and would not be a practical attack (unless the attacker knew the salt). If someone were to find a hash collision that matched the stored, unsalted, but hashed password, then yes, they would be able to use that collision to login, because the client would send the password to the server, the server would calculate the hash and compare it to the one in the database. Since the two match (different input, same hashed value), login would succeed. However, I might like to add, it's more computationally likely that one would bruteforce the password as opposed to finding a collision, especially with the generally small size of a password.

Databases generally store hashed passwords (as they should), but some store it plaintext. If the password is salted, it would make collision much more difficult without knowledge of the salt. If someone were to find a hash collision that matched the stored, unsalted, but hashed password, then yes, they would be able to use that collision to login, because the client would send the password to the server, the server would calculate the hash and compare it to the one in the database. Since the two match (different input, same hashed value), login would succeed. However, I might like to add, it's more computationally feasible that one would bruteforce the password as opposed to finding a collision, especially with the generally small size of a password.