I&#39;ve always used a proper per-entry salt string when hashing passwords for database storage. For my needs, storing the salt in the DB next to the hashed password has always worked fine. 

However, some people recommend that the salt be stored separately from the database. Their argument is that if the database is compromised, an attacker can still build a rainbow table taking a particular salt string into account in order to crack one account at a time. If this account has admin privileges, then he may not even need to crack any others.

From a security perspective, is it worth it to store salts in a different place? Consider a web application with the server code and DB on the same machine. If the salts are stored in a flat file on that machine, chances are that if the database is compromised, the salts file will be, too. 

Are there any recommended solutions to this?

Where do you store your salt strings?

I&#39;m having some trouble understanding the purpose of a salt to a password.  It&#39;s my understanding that the primary use is to hamper a rainbow table attack.  However, the methods I&#39;ve seen to implement this don&#39;t seem to really make the problem harder.

I&#39;ve seen many tutorials suggesting that the salt be used as the following:

    $hash =  md5($salt.$password)

The reasoning being that the hash now maps not to the original password, but a combination of the password and the salt.  But say `$salt=foo` and `$password=bar` and `$hash=3858f62230ac3c915f300c664312c63f`.  Now somebody with a rainbow table could reverse the hash and come up with the input &quot;foobar&quot;.  They could then try all combinations of passwords (f, fo, foo, ... oobar, obar, bar, ar, ar).  It might take a few more milliseconds to get the password, but not much else.

The other use I&#39;ve seen is on my linux system.  In the /etc/shadow the hashed passwords are actually stored *with* the salt.  For example, a salt of &quot;foo&quot; and password of &quot;bar&quot; would hash to this: `$1$foo$te5SBM.7C25fFDu6bIRbX1`.  If a hacker somehow were able to get his hands on this file, I don&#39;t see what purpose the salt serves, since the reverse hash of `te5SBM.7C25fFDu6bIRbX` is known to contain &quot;foo&quot;.

Thanks for any light anybody can shed on this.

**EDIT**:  Thanks for the help.  To summarize what I understand, the salt makes the hashed password more complex, thus making it much less likely to exist in a precomputed rainbow table.  What I misunderstood before was that I was assuming a rainbow table existed for ALL hashes.

How does password salt help against a rainbow table attack?

[bCrypt&#39;s javadoc][1] has this code for how to encrypt a password:

    String pw_hash = BCrypt.hashpw(plain_password, BCrypt.gensalt()); 

To check whether a plaintext password matches one that has been hashed previously, use the checkpw method:

    if (BCrypt.checkpw(candidate_password, stored_hash))
        System.out.println(&quot;It matches&quot;);
    else
        System.out.println(&quot;It does not match&quot;);

These code snippets imply to me that the randomly generated salt is thrown away. Is this the case, or is this just a misleading code snippet?


  [1]: http://www.mindrot.org/files/jBCrypt/jBCrypt-0.2-doc/

Do I need to store the salt with bcrypt?

I was just going through one of DavidHayden&#39;s articles on [Hashing User Passwords][1].

Really I can&#39;t get what he is trying to achieve.

Here is his code:

    private static string CreateSalt(int size)
    {
        //Generate a cryptographic random number.
        RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
        byte[] buff = new byte[size];
        rng.GetBytes(buff);

        // Return a Base64 string representation of the random number.
        return Convert.ToBase64String(buff);
    }

    private static string CreatePasswordHash(string pwd, string salt)
    {
        string saltAndPwd = String.Concat(pwd, salt);
        string hashedPwd =
            FormsAuthentication.HashPasswordForStoringInConfigFile(
            saltAndPwd, &quot;sha1&quot;);
        return hashedPwd;
    }


Is there any other C# method for hashing passwords and adding salt to it?

  [1]: http://web.archive.org/web/20120413180026/http://davidhayden.com/blog/dave/archive/2004/02/16/157.aspx



Hash and salt passwords in C#

How much more safe is this than plain [MD5][1]? I&#39;ve just started looking into password security. I&#39;m pretty new to PHP.

    $salt = &#39;csdnfgksdgojnmfnb&#39;;

    $password = md5($salt.$_POST[&#39;password&#39;]);
    $result = mysql_query(&quot;SELECT id FROM users
                           WHERE username = &#39;&quot;.mysql_real_escape_string($_POST[&#39;username&#39;]).&quot;&#39;
                           AND password = &#39;$password&#39;&quot;);

    if (mysql_num_rows($result) &lt; 1) {
        /* Access denied */
        echo &quot;The username or password you entered is incorrect.&quot;;
    } 
    else {
        $_SESSION[&#39;id&#39;] = mysql_result($result, 0, &#39;id&#39;);
        #header(&quot;Location: ./&quot;);
        echo &quot;Hello $_SESSION[id]!&quot;;
    }

  [1]: http://en.wikipedia.org/wiki/MD5


How can I store my users&#39; passwords safely?

I came across a discussion in which I learned that what I&#39;d been doing wasn&#39;t in fact salting passwords but peppering them, and I&#39;ve since begun doing both with a function like:

    hash_function($salt.hash_function($pepper.$password)) [multiple iterations]

Ignoring the chosen hash algorithm (I want this to be a discussion of salts &amp; peppers and not specific algorithms but I&#39;m using a secure one), is this a secure option or should I be doing something different? For those unfamiliar with the terms:

 - A **salt** is a randomly generated value usually stored with the string in the database designed to make it impossible to use hash tables to crack passwords. As each password has its own salt, they must all be brute-forced individually in order to crack them; however, as the salt is stored in the database with the password hash, a database compromise means losing both.

 - A **pepper** is a site-wide static value stored separately from the database (usually hard-coded in the application&#39;s source code) which is intended to be secret. It is used so that a compromise of the database would not cause the entire application&#39;s password table to be brute-forceable.

Is there anything I&#39;m missing and is salting &amp; peppering my passwords the best option to protect my user&#39;s security? Is there any potential security flaw to doing it this way?

*Note: Assume for the purpose of the discussion that the application &amp; database are stored on separate machines, do not share passwords etc. so a breach of the database server does not automatically mean a breach of the application server.*

Best Practices: Salting &amp; peppering passwords?

I&#39;ve always been curious... Which is better when salting a password for hashing: prefix, or postfix? Why? Or does it matter, so long as you salt?

To explain: We all (hopefully) know by now that we should [salt][1] a password before we hash it for storage in the database [**Edit:** So you can avoid things like [what happened to Jeff Atwood recently][2]]. Typically this is done by concatenating the salt with the password before passing it through the hashing algorithm. But the examples vary... Some examples prepend the salt before the password. Some examples add the salt *after* the password. I&#39;ve even seen some that try to put the salt in the middle. 

So which is the better method, and why? Is there a method that decreases the chance of a hash collision? My Googling hasn&#39;t turned up a decent analysis on the subject. 

**Edit:** Great answers folks! I&#39;m sorry I could only pick one answer. :)


  [1]: http://en.wikipedia.org/wiki/Salt_(cryptography)
  [2]: http://blog.codinghorror.com/i-just-logged-in-as-you-how-it-happened/

Salting Your Password: Best Practices?

Any &lt;a href=&quot;http://en.wikipedia.org/wiki/Salt_%28cryptography%29&quot;&gt;salt&lt;/a&gt; at all will obviously help when salting and hashing a user&#39;s password.  Are there any best practices for how long the salt should be?  I&#39;ll be storing the salt in my user table, so I would like the best tradeoff between storage size and security.  Is a random 10 character salt enough? Or do I need something longer?

What is the optimal length for user password salt?

Recently I have been trying to implement my own security on a log in script I stumbled upon on the internet. After struggling of trying to learn how to make my own script to generate a salt for each user, I stumbled upon `password_hash`. 

From what I understand (based off of the reading on [this page](http://php.net/manual/en/faq.passwords.php)), salt is already generated in the row when you use `password_hash`. Is this true? 

Another question I had was, wouldn&#39;t it be smart to have 2 salts? One directly in the file and one in the DB? That way, if someone compromises your salt in the DB, you still have the one directly in the file? I read on here that storing salts is never a smart idea, but it always confused me what people meant by that. 

How to use PHP&#39;s password_hash to hash and verify passwords

This code is supposed to hash a password with a salt.  The salt and hashed password are being saved in the database.  The password itself is not.

Given the sensitive nature of the operation, I wanted to make sure everything was kosher.  

    import hashlib
    import base64
    import uuid
    
    password = &#39;test_password&#39;
    salt     = base64.urlsafe_b64encode(uuid.uuid4().bytes)
    

    t_sha = hashlib.sha512()
    t_sha.update(password+salt)
    hashed_password =  base64.urlsafe_b64encode(t_sha.digest())

Salt and hash a password in Python

**Update: Please note I am not asking what a salt is, what a rainbow table is, what a dictionary attack is, or what the purpose of a salt is. I am querying: If you know the users salt and hash, isn&#39;t it quite easy to calculate their password?**

I understand the process, and implement it myself in some of my projects.

    s =  random salt
    storedPassword = sha1(password + s)

In the database you store:

    username | hashed_password | salt

Every implementation of salting I have seen adds the salt either at the end of the password, or beginning:

    hashed_Password = sha1(s + password )
    hashed_Password = sha1(password + s)

Therfore, a dictionary attack from a hacker who is worth his salt (ha ha) would simply run each keyword against the stored salts in the common combinations listed above.

Surely the implementation described above simply adds another step for the hacker, without actually solving the underlying issue?  What alternatives are there to step around this issue, or am I misunderstanding the problem?

The only thing I can think to do is have a secret blending algorithm that laces the salt and password together in a random pattern, or adds other user fields to the hashing process meaning the hacker would have to have access to the database AND code to lace them for a dictionary attack to prove fruitful. (Update, as pointed out in comments it&#39;s best to assume the hacker has access to all your information so this probably isn&#39;t best).

Let me give an example of how I propose a hacker would hack a user database with a list of passwords and hashes:

Data from our hacked database:

    RawPassword (not stored)  |  Hashed   |     Salt
    --------------------------------------------------------
    letmein                       WEFLS...       WEFOJFOFO...

Common password dictionary:

       Common Password
       --------------
       letmein
       12345
       ...

For each user record, loop the common passwords and hash them:

    for each user in hacked_DB
        
        salt = users_salt
        hashed_pw = users_hashed_password
        
        for each common_password
            
            testhash = sha1(common_password + salt)
            if testhash = hashed_pw then
               //Match!  Users password = common_password
               //Lets visit the webpage and login now.
            end if
        
        next
    
    next

I hope this illustrates my point a lot better.

Given 10,000 common passwords, and 10,000 user records, we would need to calculate 100,000,000 hashes to discover as many user passwords as possible.  It might take a few hours, but it&#39;s not really an issue.

**Update on Cracking Theory**

We will assume we are a corrupt webhost, that has access to a database of SHA1 hashes and salts, along with your algorithm to blend them.  The database has 10,000 user records.

[This site][2] claims to be able to calculate 2,300,000,000 SHA1 hashes per second using the GPU.  (In real world situation probably will be slower, but for now we will use that quoted figure).

&gt; (((95^4)/2300000000)/2)*10000 = 177
&gt; seconds

Given a full range of 95 printable ASCII characters, with a maximum length of 4 characters, divided by the rate of calculation (variable), divided by 2 (assuming the average time to discover password will on average require 50% of permutations) for 10,000 users it would take 177 seconds to work out all users passwords where the length is &lt;= 4.

Let&#39;s adjust it a bit for realism.

&gt; (((36^7)/1000000000)/2)*10000 = 2 days

Assuming non case sensitivity, with a password length &lt;= 7, only alphanumeric chars, it would take 4 days to solve for 10,000 user records, and I&#39;ve halved the speed of the algorithm to reflect overhead and non ideal circumstance.

It is important to recognise that this is a linear brute force attack, all calculations are independant of one another, therfore it&#39;s a perfect task for multiple systems to solve.  (IE easy to set up 2 computers running attack from different ends that would half the exectution time).

Given the case of recursively hashing a password 1,000 times to make this task more computationally expensive:

&gt; (((36^7) / 1 000 000 000) / 2) * 1000
&gt; seconds = 10.8839117 hours

This represents a maximum length of 7 alpha-numeric characters, at a less than half speed execution from quoted figure for *one user*.

Recursively hashing 1,000 times effectively blocks a blanket attack, but targetted attacks on user data are still vulnerable.

  [1]: http://saviourc.wordpress.com/2009/09/26/sha1-speed-differences-php-vs-mysql-part-2/
  [2]: http://www.golubev.com/hashgpu.htm

Why do salts make dictionary attacks &#39;impossible&#39;?

As I understand it, the best practice for generating salts is to use some cryptic formula (or even magic constant) stored in your source code.

I&#39;m working on a project that we plan on releasing as open source, but the problem is that with the source comes the secret formula for generating salts, and therefore the ability to run rainbow table attacks on our site.

I figure that lots of people have contemplated this problem before me, and I&#39;m wondering what the best practice is. It seems to me that there is no point having a salt at all if the code is open source, because salts can be easily reverse-engineered.

Thoughts?

Salt Generation and open source software

I want to use `has_secure_password` to store encrypted passwords in the database. I can&#39;t find on the the internet if `has_secure_password` uses any form of salting. If it uses salting, how does it works? Can anyone clarify this for me?

Thijs

Does has_secure_password use any form of salting?

Is there a significance to the word &quot;salt&quot; for a password salt?

Why is a password salt called a &quot;salt&quot;?

I&#39;m trying to configure Bcrypt for a node app that I&#39;m making and have several questions about salts that I hope someone here can help kindly answer.


- What is a salt &#39;round&#39;? For example, in the github docs (https://github.com/kelektiv/node.bcrypt.js/) it uses a salt round of 10. What does that mean exactly?

- Is the salt generated by Bcrypt always the same? For example, if I am saving user&#39;s hashed passwords to a DB, is the salt that it used to hash the password the same for every password?

- How is the salt stored? Is it secure from potential attacks?



What are Salt Rounds and how are Salts stored in Bcrypt?

I need to hash some passwords with salt on postgresql, and I haven&#39;t been able to find any relevant documentation on how to get that done.  

So how can I hash passwords (with some salts) in postgresql?

How can I hash passwords in postgresql?

I&#39;m looking at some code that I have not written myself. The code tries to hash a password with SHA512 and uses just `time()` as the salt. Is `time()` too simple a salt for this or is this code safe?

Thanks for the answers and comments. I will sum it up here for the new readers:

- salt should be different for each user, so if 2 users register at the same time, their salts won&#39;t be unique. This is a problem, but not a big one. 
- but salt shouldn&#39;t be in any way related to the user, so time() is not a good salt. 
- &quot;*Use a random, evenly distributed, high entropy salt.*&quot; -- That&#39;s a mouthful, so what code could possibly generate a `random, evenly distributed, high entropy` salt?

Ok, so how about I replace time() with a random string 32 char long. The random string could be generated from looping 32 times over a set of alphabet chars. Does that sound good?

Is time() a good salt?

Here is an algorithm in Java:

    public String getHash(String password, String salt) throws Exception {
    	String input = password + salt;
	    MessageDigest md = MessageDigest.getInstance(SHA-512);
	    byte[] out = md.digest(input.getBytes());
	    return HexEncoder.toHex(out);
    }

Assume the salt is known. I want to know the time to brute force for when the password is a dictionary word and also when it is not a dictionary word.


How long to brute force a salted SHA-512 hash? (salt provided)

I want to implement a salt into my login system but am a bit confused on how this is supposed to work. I can&#39;t understand the logic behind it. I understand md5 is a one-way algorithm and all of the functions that I have come across seem to hash everything together. If this is the case, how does one get the password back out for comparison? My biggest question is, how is salting a users&#39; password safer than just hashing the password? If a database was ever to be compromised, the hash along with the salt is in the database. Isn&#39;t this all that a hacker would need?

I also found another post here on SO where another developer said :

&gt; &quot;Ensure your salt and algorithm are
&gt; stored **separately from** the database&quot;

I would like to store the salt in the database. Is this really a problem if I do?

I&#39;m looking for some help on understanding how this works and also what the best practice might be. Any help is greatly appreciated.


----------

EDIT:
I want to thank everyone for their responses and ideas. Even though I may be more confused now, it has certainly been a learning experience for me. Thanks again guys.

How do I implement salt into my login for passwords?

Is there a tutorial out there or does anyone have pointers on how to do the following with Spring-Security?

**Task:**

I need to get the salt from my database for the authenticating username and use it to encrypt the provided password (from the login page) to compare it to the stored encrypted password (a.k.a. authenticate the user).


**additional information:**

I use a custom database structure. A `UserDetails` object is created via a custom `UserDetailsService` which in turn uses a custom DAOProvider to get the information from the database.

my `security.xml` file so far:

	&lt;authentication-manager&gt;
		&lt;authentication-provider user-service-ref=&quot;userDetailsService&quot;&gt;
		&lt;/authentication-provider&gt;
	&lt;/authentication-manager&gt;

now I guess I&#39;ll need 

			&lt;password-encoder hash=&quot;sha&quot; /&gt;

but what else? How do I tell spring security to use the databaseprovided salt in order to encode the password? 

-----------

**edit**:

I found [This SO][1] post to be informatative but not sufficient: If I define a salt source in my xml to be used by the password encoder, like so:

			&lt;password-encoder ref=&quot;passwordEncoder&quot;&gt;                
            	&lt;salt-source ref=&quot;saltSource&quot;/&gt;
            &lt;/password-encoder&gt;

I&#39;ll have to write a custom SaltSource to use my custom salt. But that&#39;s not to be found inside the `UserDetails` object. So...


**Alternative 1:**

Can I use a custom Implementation of UserDetails which might then have the salt property?

    &lt;beans:bean id=&quot;saltSource&quot; class=&quot;path.to.MySaltSource&quot;
        p:userPropertyToUse=&quot;salt&quot;/&gt;

and

    @Service(&quot;userDetailsService&quot;) 
    public class UserDetailsServiceImpl implements UserDetailsService {
    	public UserDetails loadUserByUsername(String username)
    			throws UsernameNotFoundException, DataAccessException {
    
    		// ...
    		return buildUserFromAccount(account);
    	}
    
    	@Transactional(readOnly = true)
    
    	UserDetailsImpl buildUserFromAccount(Account account){
    
    		// ... build User object that contains salt property
    }


custom User Class:

    public class UserDetailsImpl extends User{
    
    	// ...
    	
    	private String salt;
    
    	public String getSalt() { return salt; }
    
    	public void setSalt(String salt) { this.salt = salt; }
    }


security.xml:

	&lt;authentication-manager&gt;
		&lt;authentication-provider user-service-ref=&quot;userDetailsService&quot;&gt;
			&lt;password-encoder hash=&quot;sha&quot;&gt;                
        	&lt;salt-source ref=&quot;saltSource&quot;/&gt;
        &lt;/password-encoder&gt;
		&lt;/authentication-provider&gt;
	&lt;/authentication-manager&gt;
	
	&lt;beans:bean id=&quot;saltSource&quot; class=&quot;org.springframework.security.authentication.dao.ReflectionSaltSource&quot; p:userPropertyToUse=&quot;salt&quot;/&gt;

&lt;br /&gt;

**Alternative 2:**

Otherwise I&#39;d have to inject my accountDAO into the `SaltSource` to extract the salt for a given `userName` from the database. 

BUT: How does Spring Security call the `SaltSource`? Always with `saltSource.getSalt(userDetails)`? 

Then I&#39;d just have to make sure my `SaltSource` uses `userDetails.accountName` on my `accountDAO` to retrieve the salt. 

------------

**Edit2:**

Just learned that my approach is.. legacy.. :( So I guess I&#39;ll just use the `StandardPasswordEncoder` (which I still have to figure out how to use exactly).

BTW: I implemented the first option with a custom UserDetails class extending the User class and just adding a salt property which an then be passed to the SaltSource as a userPropertyToUse just like it has been proposed in the SO post mentioned in Edit 1...



-------------

**EDIT 3:**

Just got the StandardPasswordEncoder working, so I&#39;ll leave some pointers here:

Use the StandardPasswordEncoder for Authentication:

	&lt;beans:bean id=&quot;encoder&quot; 
    	class=&quot;org.springframework.security.crypto.password.StandardPasswordEncoder&quot;&gt;
    &lt;/beans:bean&gt;


	&lt;authentication-manager&gt;
		&lt;authentication-provider user-service-ref=&quot;userDetailsService&quot;&gt;
			&lt;password-encoder ref=&quot;encoder&quot; /&gt;         
		&lt;/authentication-provider&gt;
	&lt;/authentication-manager&gt;


This requires the spring-security-crypto module in version 3.1.0.RC? as far as I know. Couldn&#39;t find any repository that has a 3.0. version (even though somewhere it had the versions listed that included 3.0.6 and so on). Also the documentations talks about spring security 3.1 so I figured, I&#39;ll just go with that. 

When creating a user (for me only an admin can do that), I just use 

			StandardPasswordEncoder encoder = new StandardPasswordEncoder();
			String result = encoder.encode(password);

and I&#39;m done.

Spring security will randomly create a salt and add it to the password string before storing it in the database so **no salt column is needed anymore**.

One can however also provide a global salt as a constructor argument (`new StandardPasswordEncoder(&quot;12345&quot;);`), but I didn&#39;t know how to set up my security configuration to retrieve that value from a bean instead of supplying a static string with `&lt;constructor-arg name=&quot;secret&quot; value &quot;12345&quot; /&gt;`. But I don&#39;t know how much that is needed anyway.


  [1]: https://stackoverflow.com/questions/4968704/spring-security-3-salting-password-issue



All Salt Solutions on Gang of Coders

Total of 20 Salt Solutions