# Would hashing a password twice prevent naive attacks?

A common way of using MD5 or any other hashing algorithms to store passwords is to hash the password with a salt $$\text{hash}(\text{password} \mathbin\| \text{salt}).$$ This way, if an attacker wants to brute force the passwords, they have to do this for each password since each password has a different salt. With this setup, a determined attacker could still brute force a password since they have the salt and they know the hashed password was generated with $$\text{hash}(\text{password} \mathbin\| \text{salt}).$$

Would storing the hashed password as $$\text{hash}(\text{hash}(\text{password} \mathbin\| \text{salt}))$$ be a way of deterring the attacker? The idea with this approach is that the attacker doesn't know the password is being hashed twice. This means that if they try to brute force the password with the assumption that the hashed password is of the form $$\text{hash}(\text{password} \mathbin\| \text{salt})$$, they will never be able to crack it.

• "The idea with this approach is that the attacker doesn't know the password is being hashed twice" - archetypal violation of Kerckhoffs's Principle. May 16, 2021 at 6:23
• Is there any application where only "naive attacks" need to be considered? May 16, 2021 at 8:03
• I've changed the plus to $\mathbin\|$ notation (string concatenation), that is way correct. $+$ mostly used as an addition in crypto as opposed to programming. May 16, 2021 at 21:14

We don't approach our security through obscurity, we live in a world that Kerckhoffs's Principles rules! We assume that everything is known by the attackers except the key/password is secret. Your modification only hardens the search a little; just one more hash!

Password hashing has gone a longs way and in modern password hashing, we want them

• memory-hard so that massive GPU/ASIC searches are almost prohibited.
• Non-Parallelizable so that the attacker cannot parallel even a single search due to the requirement of multiple threads for a single password hashing.
• Many Iterations so that the attacker must need huge time for the calculation of a single password hash.

All of the above parameters can be adjustable ( depend on the password hashing algorithm) so that the system designers can fit them into their system, too. For example, having a huge iteration that takes longer than 1 second is not good from the user's perspective. 250K or 1M may be good depending on the server.

Don't fall into Schneier's Law on Security

• Any person can invent a security system so clever that she or he can't think of how to break it.

Instead of designing your own, first understand the standard ones like Scrypt, PBKDF2, and the winner of the 2015's Password Hashing Competition; Argon2.

• The reason I asked this question was to make sure I was understanding hashes properly. I agree that in practice this is pretty weak security-wise and other methods should be used instead. I'm trying to learn more about cryptography so those links at the end were really helpful! May 16, 2021 at 20:41
• @grenmester Information Security has lots of questions about passwords hashing then Cryptography. You can see by sorting the votes. And, it is nice to read the Argon2 paper May 16, 2021 at 21:09

It depends on what "naive" means. In general that is not a good idea. You assume that the attacker does not know that you hash the password twice. If this really is the case, than yes, it would help. But then you could also assume that the attacker does not know what hashing algorithm you use, so there would be additional security just because the attacker has to try different common hashing algorithms. Hashing twice could be seen a another algorithm they have to try. But without that knowledge it would be also safe and most secure to use a own unique algorithm. And we probably all agree that that is a really bad idea.

Basically there are two ways an attacker can get the hashed password. First they might only have access to the database, in this case it could help. Second, they have access to the whole system and therefore they know the trick, here it is totally useless. You should always assume that an attacker knows the exact algorithms you use!

Additionally you should be aware, that hashing multiple times can weaken the algorithm (probably more a theoretical problem).