-1

I have spent the past hour reading up on salting and still don't understand how it is achieved. Forgive me if im wrong, but the way I am thinking of salting is, storing an ArrayList of random strings for example 100 strings. Now when a user registers, a method gets a random string from the array list and retrieves the index of the string within the array to insert into my DB, it then applies this random string to the password the user entered and then hashes the whole string and stores into the DB.

Now when the user logs in it will retrieve the index for the ArrayList of random strings, then applies it to the entered password to then hash the whole string and compare the 2 passwords.

Is this a good way of salting? Is this classed as salting?

mogorilla
  • 195
  • 2
  • 13
  • 3
    don't try to invent your own. look up an existing algorithm. – DLeh Jul 10 '15 at 20:51
  • @DLeh Whats the downfall of inventing my own? – mogorilla Jul 10 '15 at 20:52
  • 3
    why do you think there are entire professions that design security measures? If you are having trouble understanding it, what do you think the chances are that you'll implement it perfectly with no security leaks? Security engineers do it for a living and still mess it up a lot. – DLeh Jul 10 '15 at 20:52
  • heck, there's even a StackExchange site just for security: http://security.stackexchange.com/ – DLeh Jul 10 '15 at 20:54
  • 1
    @mogorilla When you write your own, the risk that someone with enough dedication would be able to crack it is extremely high. This is because the process offers multiple opportunities to make an exploitable mistake. – Sergey Kalinichenko Jul 10 '15 at 20:54
  • @DLeh The fact that I have the mindset of salting being just an added string to the password to make the password in the DB less findable and hackable is why I thought of my own salt. After all, salting is just to make a common password uncommon... – mogorilla Jul 10 '15 at 20:58
  • So you want to support a dictionary attack that allows 100 dictionaries to attack _all_ of your accounts? If nothing else, using the username as salt is likely to produce more variety. As previously noted, don't try this at home, use something provided by the (so-called) experts. – HABO Jul 10 '15 at 20:59
  • salting is a random number of bytes (20+) that sit next to the hashed password, to create the hash you need to use something like the build-in sha256 of .net and you have to do something like sha256(password+salt) before saving it in the database and when you want to compare you just need to get the saved salt and rerun the sha256(password+salt) and compare it to the saved password. Salt should be unique to each password. – Fredou Jul 10 '15 at 20:59
  • @dasblinkenlight I still don't understand.. surely the algorithms that already exist would be more common than the one i created? – mogorilla Jul 10 '15 at 20:59
  • mogorilla, I think what @dasblinkenlight is suggesting is that an expert-created algorithm is less susceptible to failure than your custom non-expert algorithm. You don't have a career devoted to it, therefore it will be far inferior. Don't re-invent the wheel. – Broots Waymb Jul 10 '15 at 21:07
  • @DangerZone No problem. Am I correct to think that the salt is stored in the DB along with the password itself which is md5(salt+password) then when logging in, the salt is retrieved and then the same process md5(salt+password) to check if it matches? – mogorilla Jul 10 '15 at 21:09
  • @mogorilla That's exactly right! This means that more people got a chance to review its code, break it, fix it, and eventually bring it to a state when it's hard to break. Your version may be more obscure, but "security by obscurity" will protect you only from "scriptie kids". A person with sufficient amount of dedication and experience would figure out how to break a homegrown scheme. – Sergey Kalinichenko Jul 10 '15 at 21:10
  • @dasblinkenlight Thanks for the information and taking your time to help me understand, do you have any recommended algorithms for salting I can have a peek at? – mogorilla Jul 10 '15 at 21:18
  • @mogorilla This [Q&A](http://stackoverflow.com/q/549/335858) is a good place to start. The accepted answer has several important links, too. – Sergey Kalinichenko Jul 10 '15 at 21:34
  • These guys are misleading a bit. You never want to roll your own ENCRYPTION algorithm, but you have more flexibility when it comes to an approach for salt. You basically just want to make sure the the salt is unique for each user (the 100 string array isn't ideal for that reason). I'll elaborate in a formal answer. – Colin Jul 10 '15 at 21:35

1 Answers1

1

It's better to have unique salts for each user/password hash instead of reusing a limited set of 100 salts.

The reason is because of the way hackers attempt to compromise a database full of passwords once they get a hold of it, in particular using rainbow tables to find known values shared between multiple users.

For example (pseudo-code):

This is bad because once a hacker cracks the first password hash, both users are compromised.

 //BAD WAY
 var nonUniqueSalt = "some salt value";
 var userPass1 = "P@ssword!";
 var userPass2 = "P@ssword!";

 //Bad! This will be true!
 var isSame = (DoHash(userPass1 + nonUniqueSalt) == DoHash(userPass2 + nonUniqueSalt)); 

This way is better, because the salts are different even if the passwords are the same, so the hacker can't use rainbow tables and is forced to compromise each user's password individually.

 //BETTER WAY
 var uniqueSalt1 = "unique salt 1";
 var userPass1 = "P@ssword!";
 var uniqueSalt2 = "unique salt 2";
 var userPass2 = "P@ssword!";

 //Better! This will be false.
 var isSame = (DoHash(userPass1 + uniqueSalt1) == DoHash(userPass2 + uniqueSalt2)); 

As far as the salting "algorithm" some users mentioned in comments, you don't REALLY need to worry about it too much aside from trying to make the salt unique to each user (because of the reasons described above).

In practice, whatever salt you use will need to be stored in the DB alongside the password hash, so once a hacker has the database, he'll have the value you used for a salt no matter how you go about deriving it.

As such, using a salt based on something like Guid.NewGuid().ToString() is sufficient for simply having unique values for each login.

Colin
  • 4,025
  • 21
  • 40