CodeIgniter Community Voice - Mathew Davies

[eluser]Derek Allard[/eluser]
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

[eluser]sikkle[/eluser]
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.

[eluser]Popcorn[/eluser]
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.

[eluser]Pascal Kriete[/eluser]
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 .

[eluser]sikkle[/eluser]
Inparo thanks to you too

will need your community voice soon

[eluser]thehobo[/eluser]
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....

[eluser]Popcorn[/eluser]
You store it on registration, then retreive it when you need to login.

[eluser]thehobo[/eluser]
Aha! I see it now!

[eluser]Latavish[/eluser]
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

[eluser]Popcorn[/eluser]
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 :

Code:

$dynamic_salt = ''; // Randomly generated salt value then store it in the users table.
$static_salt = ''; // Grab this salt value from a config file.

$password = 'password'; // Input password.

$secured_password = sha1($dynamic_salt.$static_salt.$password); // Secure