[eluser]n0xie[/eluser]
[quote author="JanDoToDo" date="1262847907"]Eitherway the salt is introduced - it must be coded somewhere, and your point about the script being compromised would be equally true for my salting method and a different salting method as it will be coded somewhere how the salt is added. However, my point was that if the script isnt compromised then the salt isnt known[/quote]
The whole point of a salt is that it's useless garbage data. I can give you a whole list of salts from one of my databases accompanied with the password hashes associated with it and it would be useless to you. The salt is only valid for 1 row, so for 1 password.
An example:
id hash salt
1 ABC 123
2 DEF 456
Let's say the password for id 1 is 'codeigniter' and the password for id 2 is 'rocks'. You would add the salt making the password 'codeigniter123' for id 1 and that generates the hash 'ABC'. Now let's assume the you found out the password and want to make a rainbowtable: you would add the salt to every word in the english dictionary and see if the hashes match. So your rainbow tables consists of the word 'rocks', and then it would add the salt 123, making the password 'rocks123', which would NOT generate the hash 'DEF', because that one is generated by 'rocks456'. This will be true for every password in the database as long as the salt is unique.
So you see it doens't matter if the salt is known: the idea is to make rainbowtables unusable by making the time it takes to generate/compare every possible combination to the dataset 'very' long.
