Salts, randomness and difficulty - Printable Version +- hashcat Forum (https://hashcat.net/forum) +-- Forum: Misc (https://hashcat.net/forum/forum-15.html) +--- Forum: General Talk (https://hashcat.net/forum/forum-33.html) +--- Thread: Salts, randomness and difficulty (/thread-5736.html)

Salts, randomness and difficulty - StuUK - 08-10-2016 Hello, I'm writing a paper on hashing incorporating the major topics of salting, slow algorithms, common attacks etc. I understand that salting a value (for hashing) is primarily to prevent the use of pre-computed hash comparisons (rainbow tables) and have read many times that this is the only thing you get by salting. However from the research I've done I don't see that this can be true - assuming it's done correctly salting adds randomness to a  value, which also should make brute forcing more complex - the same for dictionary attacks because random characters have now been added to what would be found in a dictionary. For example: If the cleartext of my hash is : "Password" This should be easily solved by bruteforce and dictionary attacks. But if the cleartext is "Password+SomeLargeSalt" This is more characters, includes (pseudo)randomness and won't be found in a dictionary. And so is much harder to guess this value, and therefore more computationally expensive to crack it. Am I missing something? Thanks. RE: Salts, randomness and difficulty - Xanadrel - 08-10-2016 You're surprisingly missing some stuff. "salting prevent the use of rainbowtables" Yes except when the salt is the same for a bunch of hashes (in that case you could generate rainbowtables for this specific salt), also with the power of GPUs we tend to use rainbowtables quite less. "salting makes cracking harder/more expensive" Kind of, but not really the way you describe it. Usually the salt is linked to the hash, so when you crack you provide it to hashcat (have you even used hashcat ? noticed there is a ton of modes handling salts ?), so it doesn't make attacks harder at all except for 2 cases : if there are multiple salts and you're targeting more than a single hash, your speed will be divided by the number of salts if there is a unique salt that you don't know, you would indeed need to find it, but in case it's found, there is a single salt, so almost no speed drop compared to the first case The general advice is to indeed salt the hashes, with a per user/hash salt, that is something that can easily be done with algorithms like bcrypt for example. RE: Salts, randomness and difficulty - StuUK - 08-15-2016 Hi Xanadrel, thanks for the reply. I have used hashcat very briefly, but my purpose here is to write some security guidance rather than to learn Hashcat itself. I do have one more query: I have seen several people advocate the use of a 'pepper' or secret salt (some also define it as a MAC) - and others say this is a bad idea. I can understand that your secret may not stay secret due to various human reasons which is bad enough. Technically though even if you have a hash and a known salt I would expect that an (unknown) pepper would make computing a hash take longer - simply because there are more characters to compute. I have seen mention that you can somehow isolate a pepper and crack it alone but I don't see how this is possible.. Does hashcat have some particular function or capability in this regard?