1
votes

If I hash passwords before storing them in my database , is it enough to prevent them from being recovered by someone?

I'm just talking about directly from database recovery, and not any other type of attack , such as brute force in the application login page, keylogger on the client and rubberhose cryptanalysis. Any form of hash will not prevent these attacks.

I'm worried aboult making difficult or even impossible to obtain the original password if BD is committed. How to increase security assurance in this regard ?

What additional concerns would prevent access to passwords ? Are there better ways to make this hash ?

1
depends on your hash. if you use a cerealbox decoder ring, then your security is essentialy zero. If you use a modern crytographically secure hash, then you're fine until the underlying hash function is proven mathematically vulnerable, or computers get powerful enough that they can blow through the entire key space in a useful amount of time.Marc B
I'm voting to close this question as off-topic because this is a cross-site duplicate of How to securely hash passwords?Artjom B.
What do you mean with if BD is committed, the database? What you can do is to encrypt the hashes, so an attacker cannot start brute-forcing without the key. In this case the attacker needs privileges on the server too, to get the key, not only read access to the database. Tried to explain this at the end of my tutorial about safely storing passwords.martinstoeckli

1 Answers

2
votes

Please use PBKDF2 with 10000+ iterations. That is now also recommended by NIST (albeit not for password hashing, but it's very suitable for that too).

PBKDF2, along with a password policy to require relatively strong passwords would make it very difficult for an attacker to recover passwords, even when having the hashes.