The Yii Framework has, by default, an authentication system that uses best practice security. One thing that the authentication system could use is password encryption for both our application and users’ security (in the event our user database table is exposed to eyes that we don’t necessarily want seeing).
Larry Ullman has written a long series of introductory tutorials and individual modification to more advanced functionality of your Yii application. If you are new to the Yii framework, Ullman’s series of tutorials make a good place to start. This tutorial of the native classes in Yii expects that – while not a Yii expert – you have a better-than-beginner understanding of the scaffolding and methods Yii utilizes, knowledge of the MVC theoretical style of creating applications, an intermediate level of knowledge with php, and no knowledge of creating secure web applications.
Basic Security Protocols
If we are building web applications, we have to know that the hope we can build an impenetrable system will lead one to hubris. What is the security-minded developer to do? Paradoxes aside, it would be a good idea to become a hacker if you want to be better prepared against them. However, short of taking a chance of garnering the unwanted attention of organizations and authorities that would be less than happy about your educational exploits (assuming that you’re even successful), how do we protect our application, data, and users from those same organizations and authorities who’d like to snoop around our web servers? By using some simple maxims of data security.
One of the over-arching principles of web security is “Authentication in Layers”. What authentication refers to is the idea of a keyed pair, one user name or identity associated with a single password. Layers, refers to just that, or that the authentication should have several security layers to it besides just matching a username to a password. We want to obfuscate the process some, or make it more difficult for hackers to attack. While adhering to this maxim when developing does not ensure total security, it will create added security layers to your application and its data, something akin to all the small measures any human-created structure with defense has in mind.
For instance, the portcullis of a fortress is meant to keep intruders out. Will the portcullis by itself work? Maybe, maybe not. That’s why many fortresses also built moats, an extra layer of defense to wear intruders down before reaching the portcullis. The same goes for the authentication systems of security-conscious web apps – authentication in layers.
When looking at Ullman’s lesson about creating a custom authentication, he makes a quick reference to installing a SH1 hash to the password check before running the validate() method in the UserIdenty component. He also happens to mention that when we decide to build user account controllers, that we have to ensure that we send the password into the database with a SH1 hash as well, otherwise it won’t work.
This is true and best practice. Imagine if this hacker doesn’t hack our authentication system, but through some clever server exploit accesses our raw database files. She or he doesn’t know how our authentication system works at all, let’s say, but if we haven’t one-way encrypted the password fields that our web application users input at the account creation process, it doesn’t matter what kind of authentication system we have; our hacker has all our site’s account users data, with all its unencrypted passwords.
Now, not only does this agent have access to our site at-will, he or she has corresponding usernames, passwords, and email addresses to try on other sites to potentionally compromise accounts of our users on other sites. Not only has the security of our application failed itself, it has failed its users.
Ullen, to my satisfaction, does not really address this issue, explain its importance, or go through how it should be done. While I am impressed by the helpful explanation, let’s extend what he has done a bit further, doing our application’s security and (more importantly) our users’ privacy a solid.
