0

I want to know how service salt works. I know how to bcrypt password and give each user an unique salt. But I heard there is also another layer you can add by having a service salt. I am just curious how that works. What is the difference between that and an unique salt generated for the user?

Here's where I saw the term service salt: Web Application - Storing a Password

Community
  • 1
  • 1
  • Possible duplicate of : http://stackoverflow.com/questions/11006895/how-does-salt-work-in-rails-has-secure-password – Ahsan Khurshid Jul 30 '12 at 04:53
  • 3
    No part of the bcrypt process, or any type of password hashing for that matter, is transmitted back to and stored on the "client side". – Kerrek SB Jul 30 '12 at 04:53
  • Q: Where did you hear the term "service salt"? That might help us give you a better answer. Thank you in advance .. PS: Kerreck SB is correct. – paulsm4 Jul 30 '12 at 05:03
  • @paulsm4, I saw it here: http://stackoverflow.com/questions/6464662/web-application-storing-a-password/ –  Jul 30 '12 at 09:47

3 Answers3

1

"The benefit provided by using a salted password is making a lookup table assisted dictionary attack against the stored values impractical, provided the salt is large enough. That is, an attacker would not be able to create a precomputed lookup table (i.e. a rainbow table) of hashed values (password + salt), because it would take too much space. A simple dictionary attack is still very possible, although much slower since it cannot be precomputed."

Source: http://en.wikipedia.org/wiki/Salt_(cryptography)

Brendon McBain
  • 43
  • 7
  • And more specifically, the attacker is assumed to have direct access to the database or the list of hashed passwords. Unfortunately it seems Moore's Law has caught up with salting. http://stackoverflow.com/questions/11322691/can-salt-prevent-dictionary-or-brute-force-attacks – StuartLC Jul 30 '12 at 05:15
1

The "service salt" (described as "a sitewide static salt" in the question you cite, and also sometimes called "pepper" in crypto literature) is simply a secret string which is fed to the password hashing algorithm along with the password and the per-user unique salt.

The point of having a "service salt" like that is that, unlike the per-user salt values, the service salt is not stored in the database but somewhere else (typically in a configuration file, or hard-coded into the application). Thus, it protects the passwords against attacks that only compromise the database but don't allow the attacker to access the app configuration. With modern web apps, such an attack scenario is not as unlikely as it might seem; for example, a simple SQL injection attack would often fit this scenario.

One detail to keep in mind is that, unlike the per-user salt, which just needs to be unique and not too easily predictable, the "pepper" actually has to contain a substantial amount of entropy (say, 128 bits) and must be kept secret for it to be of any use.

In any case, including such a secret constant in the password hash calculation is pretty easy, so there's very little reason not to do it: even if your password hashing algorithm doesn't explicitly support it, you can just, say, append the "pepper" to each password.

Community
  • 1
  • 1
Ilmari Karonen
  • 49,047
  • 9
  • 93
  • 153
0

A salt prevents reverse checks against rainbow tables that are meant to hack passwords easily. The "salt" converts something easily hackable into something more difficult for a hacker to decrypt.

I would highly reccomend that you toy around with this api; http://www.openwall.com/phpass/

It does all that nitty gritty password generation for you without you needing to be a security expert. Additionally, it has fallbacks built into it to work with older/weaker systems.

Raiden
  • 484
  • 2
  • 8