3 ms·

> Only if you are using a weak hash like MD5. The primary point of hashing a user's password is to make so that it cannot be easily cracked in the event of a DB

> Only if you are using a weak hash like MD5. The primary point of hashing a user's password is to make so that it cannot be easily cracked in the event of a DB breach/leak. Stronger hashes require much more time, energy and computing power to crack...far more than what is realistically available today. I'm not suggesting that they'd be able to trivially crack the password (nor am I arguing that password hashing shouldn't be a thing - it certainly should be). I'm saying that it's likely that if they can access the database that contains the user's account details, they're able to access other information that's held in the system anyway (that's what I meant by "game-over"). > Depends. You would need to know what hashing algos/processes, initialization vectors, etc that are in place to create the DB hashes. For example, if they are "salting" the passwords, you would also need to have the salt token on hand. I bet in a lot of cases (not all, would require open-signup etc), you could sign up for an account on the service using a known password, dump the hash of the known password, and swap out the hash of the privileged user. That way you wouldn't need to know the details of the hashing implementation.

nkassis 11y ago
Hopefully the important data is also not stored on the system in clear text and the key to decrypt it is stored on a different server only held in a secure area of memory while the process is working. Password have value beyond one system they can be used to impersonate the user and often they are reused on other sites like email accounts (which can be used with reset password almost everywhere to gain access to those sites). "you could sign up for an account on the service using a known password, dump the hash of the known password, and swap out the hash of the privileged user. That way you wouldn't need to know the details of the hashing implementation." The hash should also have a salt included (which hopefully is also not stored on the same server as the database) so hashing is salt + password =hashingfunction> hash. The salt can also be a supplemented by a user specific info (unique account id) so that hashes for one user wont' work for another
mtberatwork 11y ago
Perhaps, but it would then depend on user privileges set in the database. If the application is accessing the DB as root or as a user with full admin privileges, then yes, I would say that would be a "game over" situation. On the other hand, if the DB user that is being used in the injection attack has read access to a limited set of tables, the damage may be much less severe. > and swap out the hash of the privileged user. True, if the initialization vectors of the hash are the same for admin and regular user accounts (for example, using the same salt for admin and normal users). You would also need write access to the DB via your injection attack.

nkassis 11y ago

Hopefully the important data is also not stored on the system in clear text and the key to decrypt it is stored on a different server only held in a secure area of memory while the process is working. Password have value beyond one system they can be used to impersonate the user and often they are reused on other sites like email accounts (which can be used with reset password almost everywhere to gain access to those sites). "you could sign up for an account on the service using a known password, dump the hash of the known password, and swap out the hash of the privileged user. That way you wouldn't need to know the details of the hashing implementation." The hash should also have a salt included (which hopefully is also not stored on the same server as the database) so hashing is salt + password =hashingfunction> hash. The salt can also be a supplemented by a user specific info (unique account id) so that hashes for one user wont' work for another

mtberatwork 11y ago

Perhaps, but it would then depend on user privileges set in the database. If the application is accessing the DB as root or as a user with full admin privileges, then yes, I would say that would be a "game over" situation. On the other hand, if the DB user that is being used in the injection attack has read access to a limited set of tables, the damage may be much less severe. > and swap out the hash of the privileged user. True, if the initialization vectors of the hash are the same for admin and regular user accounts (for example, using the same salt for admin and normal users). You would also need write access to the DB via your injection attack.