EllisLab is blessed with two of the greatest communities that can be found anywhere on the internet in ExpressionEngine and more recently CodeIgniter.  Despite being a relative newcomer to the scene, the people attracted to CodeIgniter are among the smartest, most talented and down-to-earth developers around today.  From time to time we want to highlight some of these talented people, and we’ve asked them to lend their voice to ours.  Have your voice.  I hope you enjoy what they have to say as much as I did.

This week,  our Community Voice author is Mathew Davies (AKA Popcorn), author of the Redux Authentication library, a light, easy to use and fully featured auth engine. What follows is a brief discussion of some of the logic and security that went into the library, and considerations for your own programming.

Read the full article

Hey Mathew,

You just forgot to mention that CodeIgniter in fact uses a session encryption key, so the session cookie is more secure than he originally thought.

Not that is enough to make it rock solide, but still people will prolly love to hear that

Good job Mathew, glad to have you with us here.

Thanks for spotting that sikkle.

Ps : Everyone who replies to this thread also has to thank sikkle for being a great help to the community

Cheers.

Great read, and a really nice library as well.

Just to explain my quoted self real quick.  Double hashing, such as sha1(sha1($password)) or even more amusing sha1(md5($password)), is bad.  However, you may see people double hashing with an added salt.  That is known as key stretching and actually increases the strength of the hash.  In practice, you won’t do enough iterations to make a difference, so Mathew’s method is excellent (goes without saying).

On the cookie issue - decryption works against tampering, but theoretically you don’t need to decrypt the cookie to forge it.  You just have to present it to the site with the proper credentials and the server will decrypt it for you.  If you’re using CI sessions with the database that becomes very hard as you need to catch the user’s last request (along with his user agent and ip).  The database part is important though.

Chris Shiflett did an article a long time ago about Microsoft’s Passport system having a similar cookie vulnerability.  While outdated, it’s definitely worth a read.  It also shows that a clever person can turn a browser quirk into a security issue.  In fact, all of his articles are worth reading to get into the right mindset.

Keep up the great work.
And of course, thank you Sikkle .

Inparo thanks to you too

will need your community voice soon

I’m confused about the microtime dynamic salt bit. How would i know the dynamic salt value when i need to compare the hashed value?

Or i’m missing something very obvious here….

You store it on registration, then retreive it when you need to login.

Aha! I see it now!

Excellent tips there Derek,

Is to seed your password the same as to salt? If they are different i think I can see how to salt may be more secure.

$seed = ‘6j3l23b35bdg’; //Some Random Generated numer
$password = ‘ilikecrownroyalinmycoffee’;
$secured_password = sha1($seed.$password);

Latavish

Humf, I wrote the article Latavish

What you have shown me is a dynamic salt value.

The best thing is to do something like this :

I am still failing to see how this is really anymore secure then using a static salt in the situation that your DB had been compromised (and brute forced with a rainbow hash) which Im led to believe is the main reason for using salt for passwords. The reason being that the dynamic salt can be actually seen in the table row that has been compromised and hence can be used as a part of the rainbow hash.

Lone, rainbow tables don’t reverse the hash - they find a collision.

Hash functions aren’t perfect, they all have a size limit (160 bits in the case of sha1) so the birthday paradox applies to all of them.

If we have password x and assume that y = sha1(x), then we can find another password z where sha1(z) = y.  That works really well if they aren’t salted, because we now just punch z into the password field and the server authenticates us.  But with a salt the hash becomes different for the two.  So sha1(x) == sha1(z), but sha1(x+salt) != sha1(z+salt).

What the static salt does, is it stretches the key we hash so that the odds of finding that particular collision are lower.  Also if you have a very random password, and someone does manage to crack the hash, they won’t be able to tell where the salt ends and the password starts.

Something like this would have a similar effect, with a few more operations:

To truly reverse sha1, you would need to brute force it, which is not feasible (article explaining why).

Hello Everybody,

There is an interesting article on phpsec.org about salted passwords. This is the philosophy :

This way, the salt is not clearly stored in the database:  ;D