Salted Hashing for password storing?

Nuno

Level 2
Thread author
Verified
Feb 26, 2016
98
Hey! I was doing a report on SHA256 and a doubt occurred to me.
Does anybody know if salted hashing is still the most viable way of storing passwords, of today?
And how is the salt computed? I've heard taking it from the username is not the best practice, as it should be completely random. But a completely random salt would have to be stored separately somewhere else, right?
Can anybody clarify it for me?
Thank you! :)
 

Winter Soldier

Level 25
Verified
Top Poster
Well-known
Feb 13, 2017
1,486
Nice question

Yes to complicate the life of any cybercriminal you can use the "salting", adding a grain of salt.... to the password.

In this way you can continue using the hashing encryption, but it is not applied to the initial password, but to the password plus a few random characters: indeed “salt”. In this way, the hash would not be the same.

In practice, the system writes the "salt" in the password itself.

Let's make a practical example: your password is "Nuno" and is associated with the salt "xy", where the two characters were chosen randomly. First it calculates the crypto-hash not more of "Nuno", but of "Nunoxy": suppose that the result is "yklh24sefsd". At this point in the password file will be saved the string "yklh24sefsd". When you will try to connect, the system will take the last two characters of the encrypted password, it will attack them in the password that you provided, it will compute the hash, and join the two final characters, and will check if everything coincides.

But the important thing is that the salt is not very useful to strengthen the password, in my opinion.
Its purpose is only to make different encodings of identical passwords, but it is necessary that the salt be actually different.
 

Nuno

Level 2
Thread author
Verified
Feb 26, 2016
98
Nice question

Yes to complicate the life of any cybercriminal you can use the "salting", adding a grain of salt.... to the password.

In this way you can continue using the hashing encryption, but it is not applied to the initial password, but to the password plus a few random characters: indeed “salt”. In this way, the hash would not be the same.

In practice, the system writes the "salt" in the password itself.

Let's make a practical example: your password is "Nuno" and is associated with the salt "xy", where the two characters were chosen randomly. First it calculates the crypto-hash not more of "Nuno", but of "Nunoxy": suppose that the result is "yklh24sefsd". At this point in the password file will be saved the string "yklh24sefsd". When you will try to connect, the system will take the last two characters of the encrypted password, it will attack them in the password that you provided, it will compute the hash, and join the two final characters, and will check if everything coincides.

But the important thing is that the salt is not very useful to strengthen the password, in my opinion.
Its purpose is only to make different encodings of identical passwords, but it is necessary that the salt be actually different.

Thank you for the reply!
In that case, how would you store the salt? Because suppose I'm logging in. To compare my password to the stored hash, the system has to know exactly the salt that was added to the hash. But well... if you store the salt in your db as a string, it's basically the same as not salting it. And you can't hash it or you won't be able to recover it.

What went through my mind was having some sort of algorithm that pulled the salt from the username and did some computations. Sort of like a hashing algorithm. You'd take the name, for example "Nuno". And you could, for example, invert it, change the letters to the next one in the alphabet, etc, etc., ending up with for example povO. And you could use that as salt. And in this way, it would be simple to find out what the used salt was just by the username.

However, I've heard that taking the salt from usernames can be a bad idea, and instead, the salt should be completely random and long enough. Then how would you know what the salt is? I thought about encrypting the salt table, that's the only approach I can remember. But that seems weirdly complicated (where would you store the encryption key?), and in my head, it doesn't sound as good as scrambling the username to get the salt.

Am I missing something? Do you know how that would work?

Thank you so much!
Nuno
 
  • Like
Reactions: frogboy

Winter Soldier

Level 25
Verified
Top Poster
Well-known
Feb 13, 2017
1,486
Thank you for the reply!
In that case, how would you store the salt? Because suppose I'm logging in. To compare my password to the stored hash, the system has to know exactly the salt that was added to the hash. But well... if you store the salt in your db as a string, it's basically the same as not salting it. And you can't hash it or you won't be able to recover it.
Well, we're talking about very technical topics, and especially theoretical.
Lets say that at the mathematical level, what I can I say is only a small part of the concept.

Yes indeed, because the function for a cryptographic hash is a one-way compression function, it is not a one-way trapdoor function. One-way trapdoor function is instead used in public encryption.
A one-way trapdoor function is something that becomes easy to invert if you have an extra knowledge. An hash encryption function is defined one way and "compression" (obviously lossy, indeed, a fundamental characteristic is to map the space of strings of any length to strings of a given length). Nothing prevents you to ask for that is also one-way trapdoor (of course that does not allow for a true reversal, in view of the poor injectivity of a hash function), but this is done only for very specific applications (e.g. reducing the time of the online computation for RSA signatures) and none of the standard hash functions has a trapdoor (or at least I hope).

However, I've heard that taking the salt from usernames can be a bad idea, and instead, the salt should be completely random and long enough. Then how would you know what the salt is? I thought about encrypting the salt table, that's the only approach I can remember. But that seems weirdly complicated (where would you store the encryption key?), and in my head, it doesn't sound as good as scrambling the username to get the salt.

Am I missing something? Do you know how that would work?

The fact is that the "password+salt" system is assigned forcibly. It may not be a function of the password, because otherwise it would be part of the same hash.
You consider that there are many precomputed hash database (rainbow table), and so it is not too difficult to find out what is the hidden password with the MD5 hash. Salt makes the creation of rainbow tables more difficult.
You try to imagine: you want to do all the hashes of all the passwords of only 8 characters, with an alphabet of 26 characters, you have to calculate 26^8 possibilities, each of which requires 8 bytes + 16 bytes for a hash 128 bits: in total, a database from 10^13 bytes, about 4 Tera.
Adding even just 2 bytes of salt, however, the same calculation leads to a DB of 3081 Tera!
 

Nuno

Level 2
Thread author
Verified
Feb 26, 2016
98

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top