Skip Navigation LinksHome > Categories > Code from a Category

Building a secure entry system, based on Zend Framework.



User Name: serfcompany
Name: Serf
Contact Me: www.datawebcoder.com
Home Page: www.datawebcoder.com
php,mysql,javascript,html,css. Preferable working with Zend Framework. Good know javascript. I worked with various, javascript frameworks such as(jquery, YUI3, extjs, sencha touch). [More]
Viewed Times: 3495
Add Date: 08/16/2012
The question of building a secure entry system into a web application is fairly common. Safety aspect is very important and in this article I'll show you some tricks to solve this problem.

Let's build a simple Zend Framework application with the possibility of authorization. Registration form is out of a login and password.
These fields appear in the database MySQL. The structure of our base would look like:



As you can see, we store your password in the field of type CHAR (32). This is because the used hash function MD5 (), for safe storage. As you know, if you store the passwords in hash functions, then in theory it is impossible to invert the hash value and choose a password. I wrote that, in theory, because, as Joe says in his commentary, Devon, you can use Google to get the most popular hash values. For example, look at this site http://md5.rednoize.com


To increase security, I use the so-called "salt". I added the "salt" in the field of type CHAR (20) in the user table with a randomly generated string. A string generated password in MD5 function MD5 (CONCAT (salt, 'password')), where the 'password' is a string with a password. With the "salt" the password to be more resistant to dictionary attacks, which consists of the values ??of MD5.


With this system, even the administrator of this site will not be able to learn users' passwords. It is very important in terms of confidentiality. You can trust the sites that are able to recover your password?


Our application will use the Zend Framework classes to create a safe entry:


* Zend_Form: creates a form for the login page;
* Zend_Auth_Adapter_DbTable: authenticate users stored in the database;
* Zend_Session: stores data in a session (Session);
* Zend_Config: stores application configuration file;
* Zend_Db_Table: map a database table in a class of PHP.

The structure of the application.

We have a structure of an application with the following directories:


In the application I keep the structure of the application with the Zend Framework files and bootstrap.php Initializer.php.
Class Initializer adjusts Front Controller, which I described the test login.
I think this is a good solution for the system log, because this way we can control the authentication system without changing the controller classes. This means that if a user sends a request to the controller, it must already be authenticated.

In the folder etc I keep a file config.ini and subdirectory structure in the database db.library folder, I put common PHP-classes that are used in my Zend Framework application, and subdirectory Forms. with all forms of application.

Folder publicCss,. Js, images, and index.php.

We now turn our attention to the plug-Initializer, which is the core of our system of entry. It contains two important methods preDispatchand checkSession













PreDispatch method in Zend Framework called first before each action, so it makes sense to store it in an authentication system. In the method preDispatch we get the name of the controller and check it if it is not his name or the index error. If the test passes, the method is performed checkSession.


Note that I used another check in the file config.ini - Globals :: getConfig () -> authentication->; active when the system authentication is enabled. This is handy to enable or disable authentication by changing only one value in the file config.ini. Controllers and error index is outside the system authentication. This is because they contain pages that should be visible without authentication.


CheckSession method is very simple. It checks if the session variable username is empty, it means that the user is not logged in and redirects to the page of login and password, that is, on the authentication page.


As you can see, I used a class Globals, to get some singles (singleton) objects associated with managing a database connection, session, and the configuration file. I usually create these singletons to have only one database object, and session configuration file during the life of my PHP-applications.


In addition, a singleton can I speed up the reading of these objects during the execution of the application.


Login form.

Login form application is described in the file library / Forms / Login.php.
I use a class Zend_Form_Element_Hash to protect against CSRF-attack (CSRF) attacks.
Also, using the method setSalt, to improve security in conjunction with pseudo-random value obtained with the function md5 (uniqid (rand (), TRUE)) and setTimeout to set the "time of life» (TTL) (the timeout value specified in the config.ini file .)



This is the hidden meaning of «token» is inserted into the form and gives us confidence that the data POST request to come to our pages, but not with any other.



In the method loginAction I create a login form (9th row). These landing pages are passed to the method submitAction. In this step we check the validity of the form (16th row). If you have problems with the data of «token», it may mean that we conduct CSRF-attack and we can redirect to a special error page with the name csrf-forbidden. Page csrf-forbidden return 403 error. «Preventing CSRF properly» of Tom Graham.


For user authentication, we use an adapter Zend_Auth_Adapter_DbTable (31th row). We check the password authentication using MD5 (MD5 (?), Where? Is $ password) available for active users (active = 1).


If a user is logged in, we update last_access field in the user table and forwards it to the home page (lines 55-61).


If you are not logged in, we redirect it to a login page with the message "Authentication failed."



Note that the regenerated session id with Zend_Session :: regenerateId () at the time of entry (line 43), and cleared out during the session (logout) (line 14 in the method logoutAction HomeController). This is done for security reasons, to reduce the possibility of holding a session fixation-attacks.


In this post, I will not consider SQL-injection. Why not? Because the class Zend_Db, we ispolzuem annex uses quotas to prevent such attacks. Moreover, we used the validator Zend_Form, to filter the input values ??the user name and password.


Conclusion.

In this post I showed you a secure login to the application using the Zend Framework. Important safety aspects:


-MD5 + «salt" passwords stored in the database;
- generating a pseudo-random key (token) in a form to prevent CSRF attacks.
- timeout key (token) to enhance the safety of the entrance;
- regeneration of the session Id to mitigate the possible session fixation attacks;
- redirect to an error 403 page to prevent CSRF attacks;
- Class Zend_DB uses quotas to prevent SQL-injections.


One of the unsafe things is that the user name and password are sent in plain text. Any attacker can intercept the data sniffer. In order to create a reliable system used by the protocol Secure Sockets Layer (SSL). For now, it's the only way to encrypt communications between the client and the user.


Post a Comment

Name: (Optional)
Email: (Optional, you can get an email if somebody replys your comments)*
Email me if somebody respons my comment below:
Details**:
Enter Text
as Below:
(case insensitive, if hard to read, click the "get a new one" button)
 
    
* Your email address will not be shared with any third parties for any reason.
** Maximum 1000 charactors.