8

What is "salt" when relating to MYSQL sha1? I have no idea what salt is when relating to sha1 password encryptions? Can someone please explain what it is?

Noah R
  • 5,287
  • 21
  • 56
  • 75

3 Answers3

14

A salt is a value that is added to a password (or other secret) which you want to hash one way. This means it could be before, after, or somewhere inside the password, as long as its position and value is consistent for a given supplied password.

What this does is it mitigates dictionary attacks - basically dictionaries of common passwords pre-hashed with no salt - from being used to "guess" a one way password as long as the attacker does not know the hash. If every password has a different hash then it makes it very difficult for an attacker to create a dictionary optimized for cracking your passwords (they would need a dictionary for each separate salt and they would also need to know where the salt was placed in each password).

Of course for all of this to be applicable an attacker must have the hashes of your passwords in the first place. This has nothing to do with attacking passwords by guessing them through some input prompt.

Regarding MySQL specifically if you provide a salt when hashing a password, make sure you record what that salt was somewhere. Then when a user attempts authentication you combine that recorded salt value with the password (during the call to crypt for example) and if the resulting hash matches then they have entered the correct password. (Note that at no time is the hashing of a password reversed; thus one way.)

Borealid
  • 95,191
  • 9
  • 106
  • 122
cfeduke
  • 23,100
  • 10
  • 61
  • 65
9

salt is nothing but an string you attach to the password, either as a constant or through a algorithm

which makes it harder for anyone who breached your security and gain access to your stored password, which in return makes in next to impossible for him to use rainbow dictionaries to unlock what the real password is, which in a hacker point of view can be usefull since alot of people use the same password in alot of diffrent sites

$salt = "this is a salt";
$password = 'this is an password';
$hash = sha1($salt.$password);

That's how you basically could salt a password

hypercrypt
  • 15,389
  • 6
  • 48
  • 59
Breezer
  • 10,410
  • 6
  • 29
  • 50
  • So what would be the salt for:sha1$0e7eb$f2353e34dd1811c3ce4af5c2b0f5cb43a04a16ce – Noah R Dec 04 '10 at 03:11
  • you cant tell, it's a part of the password – Breezer Dec 04 '10 at 03:13
  • 2
    @Breezer: Incorrect; you can't extract it from the hash. It is stored separately though, along with the algorithm used and resultant hash. – Ignacio Vazquez-Abrams Dec 04 '10 at 03:14
  • Alright, well... I'm trying to hack my own database for my lost password... I'm using Cain and Abel for this... and it's asks for the "salt" to hash it. Now... if you need to decode it to find the salt then why would Cain and Abel ask for the salt? – Noah R Dec 04 '10 at 03:17
  • now when i think of it sha generates a 40 char hash so these could be it $0e7eb$ – Breezer Dec 04 '10 at 03:18
  • It says invalid salt length when I try "$0E7EB$" and then place A the rest of the hash "f2353e34dd1811c3ce4af5c2b0f5cb43a04a16ce" into Cain and Abel. Any ideas why? – Noah R Dec 04 '10 at 03:20
  • The format for authdb password entries is commonly " `$` `$` ". The `$`s are only delimiters. – Ignacio Vazquez-Abrams Dec 04 '10 at 03:26
  • So I won't be able to retrieve the password? – Noah R Dec 04 '10 at 03:28
  • what he's saying if i understood correctly is that 0e7eb is the salt – Breezer Dec 04 '10 at 03:32
  • 2
    a salt must always be random. if you use a constant, it is a key instead of a salt. – Jacco Dec 27 '10 at 09:11
  • 1
    @Jacco: Not necessarily random, just not constant. :) – Sasha Chedygov Dec 27 '10 at 10:19
  • @musicfreak it must of sufficient entropy, non-predictable and distinct for each hashed password on across all systems and for each instance. The easiest (only?) way to achieve this is by choosing a random salt. also read: http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190 – Jacco Dec 27 '10 at 11:57
  • @Jacco: Right, but couldn't you use, for example, the timestamp of the time at which the user registered (or changed his password)? That's not randomly generated, but still useful. – Sasha Chedygov Dec 28 '10 at 10:12
  • @musicfreak a timestamp has only a limited range, and therefore becomes predictable. If I knew a website was operating for 1 year, than would be 31,556,926 seconds (but these are non-evenly distributed values). Provided the system did not leak any information such as 'member since', this would be better than nothing, but far less entropy than a random 32bit salt (=4,294,967,296 options). The problem is however, that at this same second, multiple users could have subscribed, this is even more likely if your software is run on more than one machine. I would say, why risk it? – Jacco Dec 28 '10 at 10:48
  • @Jacco: Hmm, interesting, thanks for the insight! I myself used a random salt on the last web app that I worked on, but I always thought a timestamp was fairly secure. – Sasha Chedygov Dec 28 '10 at 20:51
5

A salt is appended to the plaintext (or vice versa) before hashing in order to make dictionary lookups more expensive.

Ignacio Vazquez-Abrams
  • 776,304
  • 153
  • 1,341
  • 1,358
  • COuld you give me an example? – Noah R Dec 04 '10 at 03:08
  • 1
    +1 - right. For example, it means that an attacker who has access to a bunch of hashed passwords can't just SHA1-hash a dictionary once and compare it against all the passwords in bulk; because of the salt, the hashing has to be re-done (with correct salt) for each password. – David Gelhar Dec 04 '10 at 03:12