Menu
Hi i have a question regarding MD5 Hash / Salting.
I read a lot about hashing and salting recently and i understand that i should use a different salt for every single password and that i should not use something like username, because the salt should ideally be completely unique. But what i don't understand is why it is recommended to store this salt alongside the password in the database?
Isn't it bad if the attacker gets hash AND salt? I understand that its harder for the attacker, because the unique salts ensure that he can't check a single calculated-hash against all passwords. But still, wouldn't it be better to keep a part of the salt hidden?
I was thinkin about splitting the salt in 2 parts. The first part is stored in the database as usual, the second (smaller) part is hardcoded in my application. It would be nearly impossible for an attacker to get the complete salt, as he would have to infiltrate both applicationserver and database.
Is this a good solution? The salt would still be unique, but all salts would end with the same sequence.
484
Attempt Four – salt and hash The easiest way is to put the salt in front of the password and hash the combined text string. The salt is not an encryption key, so it can be stored in the password database along with the username – it serves merely to prevent two users with the same password getting the same hash.
There is no need to store them separately - the point is to use a random salt for each password so that a single rainbow table can't be used against your entire set of password hashes.
Typically, the salt and the password (or its version after key stretching) are concatenated and fed to a cryptographic hash function, and the output hash value (but not the original password) is stored with the salt in a database.
A cryptographic salt is made up of random bits added to each password instance before its hashing. Salts create unique passwords even in the instance of two users choosing the same passwords. Salts help us mitigate hash table attacks by forcing attackers to re-compute them using the salts for each user.
An attacker is "allowed" to know the salt - your security must be designed in a way that even with the knowledge of the salt it is still secure.
What does the salt do ?
Salt aids in defending against brute-force attacks using pre-computed "rainbow-tables".
Salt makes brute-force much more expensive (in time/memory terms) for the attacker.
Calculating such a table is expensive and usually only done when it can be used for more than one attack/password.
IF you use the same salt for all password an attacker could pre-compute such a table and then brute-force your passwords into cleartext...
As long as you generate a new (best cryptogrpahically strong) random salt for every password you want to store the hash of there is no problem.
Depending on how you use MD5 it is a weakness since MD5 is no longer seen as "cryptogtaphically secure"
IF you want to strengthen the security further
You could calculate the hash several times over (hash the hash etc.) - this doesn't cost you much but it makes a brute-force attack / calculating "rainbow-tables" even more expensive... please don't invent yourself - there are proven standard methods to do so, see for example http://en.wikipedia.org/wiki/PBKDF2 and http://www.itnewb.com/tutorial/Encrypting-Passwords-with-PHP-for-Storage-Using-the-RSA-PBKDF2-Standard and http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx
Using such a mechanism is these days mandatory since "CPU/GPU time" (usable for attacks like rainbow tables/brute force etc.) is getting more and more widely available (see for example the fact that Amazon's Cloud service is among the top 50 of fastest supercomuters worldwide and can be used by anyone for a comparatively small amount)!
Splitting the salt into 2 pieces, one hardcoded/constant and one unique part is NOT recommended!
Depending on the algorithm used this can be a weakness helping an attacker to break your security. I would highly recommend NOT doing this unless you can prove mathematically that it does not weaken your security (which is very hard to do IMHO).
There is NO problem at all for an attacker to know your complete salt if you implement the security correctly...
UPDATE (as per comment):
RFC 2898 is an important reference on PBKDF2. In section 4.1 it talks about adding a part to the salt
the salt should contain data that explicitly distinguishes between different operations and different key lengths
This has IMHO no relation to what the OP is asking. The RFC talks about information on key lengths etc. being incorporated as an additional part along with the random salt. This is very similar to having a file format containing a header section describing specific aspects of the data it contains. This does not weaken security and is possibly very usefel in a scenario where interoperability between different systems is needed.
In contrast what the OP is asking is basically storing only a part of the salt in the DB while keeping the other (smaller) part hardcoded in the application which means that the salt in the DB is not complete... doing this means losing entropy of the salt (i.e. a 64-bit salt with 8 bits being constant is actually only as secure as a 56-bit salt) which in turn leads to weakening the security the salt provides (at least for any algorithm I can think off right now)... this contradicts what the OP intends (increasing security).
UPDATE 2 (as per discussion with owlstead):
You can add some "secret" (which can be hardcoded in your application) to the plaintext BEFORE hashing with PBKDF2 using a unique and random salt which is completely stored in the DB... that could help a bit although it accounts for security by obscurity IMO.
78
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
