Question

I am currently working on a web project requiring user accounts. The application is CodeIgniter on the server side, so I am using Ion Auth as the authentication library.

I have written an authentication system before, where I used 2 salts to secure the passwords. One was a server-wide salt which sat as an environment variable in the .htaccess file, and the other was a randomly generated salt which was created at user signup.

This was the method I used in that authentication system for hashing the password:

    $chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
    //create a random string to be used as the random salt for the password hash
    $size = strlen($chars);
    for($i = 0; $i < 22; $i++) {
        $str .= $chars[rand(0, $size - 1)];
    }

    //create the random salt to be used for the crypt
    $r_blowfish_salt = "$2a$12$" . $str . "$";

    //grab the website salt
    $salt = getenv('WEBSITE_SALT');

    //combine the website salt, and the password
    $password_to_hash = $pwd . $salt;

    //crypt the password string using blowfish
    $password = crypt($password_to_hash, $r_blowfish_salt);

I have no idea whether this has holes in it or not, but regardless, I moved over to Ion Auth for a more complete set of functions to use with CI.

I noticed that Ion only uses a single salt as part of its hashing mechanism (although does recommend that encryption_key is set in order to secure the database session.)

The information that will be stored in my database is things like name, email address, location by country, some notes (which will be recommended that they do not contain sensitive information), and a link to a Facebook, Twitter or Flickr account. Based on this, i'm not convinced it's necessary for me to have an SSL connection on the secure pages of my site.

My question is, is there a particular reason why only 1 salt is being used as part as the Ion Auth library? Is it implied that I write my own additional salting in front of the functionality it provides, or am I missing something?

Furthermore, is it even worth using 2 salts, or once an attacker has the random salt and the hashed password, are all bets off anyway? (I assume not, but worth checking if i'm worrying about nothing...)

Was it helpful?

Solution

It is because Ion_Auth uses bcrypt - so you generally dont need to do much more.

Furthermore - you can configure "random_rounds", which is kind of like a random salting (to a degree) in the config.

edit: you can view this SO thread for more details on bcrypt and other types of encryption

OTHER TIPS

The argument that someone may somehow find a way to inject code, or you mistakenly leave a directory open to view, or someone finds an injection hack and can see the system salt file or the user data isn't that compelling of a reason to use dual salts. If any of this, indeed you'd have more to worry than a list of the user salted and encrypted passwords!

All this being said, the dual salt solution is indeed much more secure, especially if there's a chance someone else other than you will see the system salt in your code. Think of a situation where maybe a contractor or a co-worker leaves. If they know the salt and the salting patter/algorithm used they can create rainbow tables and use that against your site. Adding the second random salt to the user record, protects against this.

It's all about weighing the value of what your securing vs. the amount of reasonable effort someone would need to go through to get at what your securing. Also, simply not being completely negligent by not using salts at all or not encrypting at all is sadly better than many other less secure places our basic data is stored. If it's no credit info, medical records, social sec. numbers, and just vanilla user info (email, address, etc...) and you have no plans to ever bring in this data, single salt is probably sufficient. If you can't make this judgment call with 100% certainty now, error on the side of the more secure option.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top