CODEWITHSUNDEEP
securityhashcryptographysalt-cryptography
Metalstorm
Metalstorm

Reputation: 3232

Hashing, adding more salt

Ok, so I understand why salting a password prior to hashing is such a good idea. The question is, normally people suggest appending or prepending the salt to the password, why not do both?

My thinking is, so if Mr hacker got hold of the DB and wants to get the password for person x, he thinks to himself, well most people suggest appending or prepending the salt, so lets do that.. He generates a rainbow table with of all the combinations of password + salt, and tries his luck. If that doesn't work he does the same but salt + password.

To make much it more difficult to do the attack why don't developers go the step further and do 'salt + password + salt', or 'reverse(salt) + password + salt', or you could be fancy and start cutting up the password/salt, start putting bits of salt here and there etc.

The only way the hacker would be able to find the password is if he has access to the source code (to know how the salt was weaved into the password prior to hashing)

A further note is, people suggest doing a minimum of 1000 iterations when key-stretching, again why not 1147, 1652, etc :)

A 2nd further note, when looking at a hash string, is it possible to work out the hashing function used?

Upvotes: 1

Views: 323

Answers (2)

Wug
Wug

Reputation: 13196

It's much easier to guess the manner in which the salt is applied than it is to brute for the passwords, especially in the cases in which the attacker has a database of hashed passwords and one known match (his own password). Even if he has no knowledge of it, he can simply use his known password and the known hash to brute force the salt and salting algorithm.

The same goes with the hashing algorithm. There are only a few unbroken hash functions, and the chances are that any competent administrator would be using one of those.

One of the premises of cryptography is that ALL of the information about the algorithms used is assumed to be public. You should not rely on attackers to be unable to break your system because you are using an obscure algorithm to hash things, because compared to the expense of brute forcing passwords on a compromised database like that, brute forcing every hash algorithm is very inexpensive.

If you distribute your program to users, they can figure out exactly how it hashes things by disassembling or debugging it. If it's a server program, they can break in with some other vulnerability, or they can buy/steal/acquire your software, or whatever. I would even go so far as to say that ALL GOOD CRYPTOGRAPHIC SOFTWARE IS OPEN SOURCE: even though the entire world knows how it works, its still not breakable.

What you are trying to rely upon is security by obscurity. Lots of people and companies have used this as a method of securing their products. The last big incident I can remember was when the source code of Symantec's PCAnywhere software was stolen. You might remember how that turned out. Moral of the story is it isn't secure if nobody knows how it works, its secure if EVERYONE knows how it works (and it's cryptographically sound).

Upvotes: 7

Petey B
Petey B

Reputation: 11559

Reverse engineering your code would not be too hard for a determained hacker, once that happens, every one of your passwords is now compromised.

You should use proven hashing techniques. Take, for example, something similar to the bcrypt algorithm. When you want to hash a password, go through the following steps:

  1. Generate a sufficiently strong random salt (16 - 32 bytes)
  2. Set a hash cost (15 - 20) (the larger the cost, the slower and stronger the hash)
  3. Calculate the number of hash rounds you will perform (2^cost)

Do the following:

hash = ""
for(numberOfHashRounds)
{
hash = SHA256(hash + salt + password)
}

Then store the hash along with the salt and cost used. When you need to verify, do the same with the stored salt and cost. As computers get faster, you can up the cost of the algorithm. Try and get it so your hash takes ~500ms to compute, or as long as you are willing to sacrafice.

This is secure because a cracker would have to generate a rainbow table for every salt, and perform the same number of rounds. This will take decades even with a GPU array used to crack.

If you want to add obfuscation on top of that, go ahead, just dont break the security of your algorithm in the process.

Upvotes: 0

Related Questions