• php forms
  • conkurent
  • real estate

Site Password

One of the main axioms of informational security tells that the system usability is inversely proportional to its security level. So a web developer must find an optimal proportion between protection system complicity and usability when choosing security methods for a web project.

One of the most popular ways of protection is site password. This method allows to save user passwords and logins on server database together with their permitted access level. When site password is used, a visitor that enters a website for the first time must input is login/password. After this his personal account is created by a system, his profile is saved in database. Site password prohibits free access to its resources and makes it possible only after successful authorization procedure.

Arranging site password mechanism is the full responsibility of a programmer. A developer must provide the security of saving user lists, their login/password correct verification, saving security contexts and their recurrent usage, etc. Security context means a set of parameters that uniquely define user (usually it contains login, password and session identifier).

Here is an example of simple site password realization:

One of the most popular shortcomings in site password scripts is using GET method. When using it the data is transferred straight in the address. As a result this data is visible even to the naked eye. Second imperfection is saving login/password information strictly in the page code. When adding new user, a programmer each time needs manually change page code. It’s more rational to save this information in separate file or in database. The database is more preferable, as it is better secured.

Third shortcoming of site password scripts is lack of saving authorization results. It means that it will be enough to reload the page and you will be asked to input your login/password once again.

Lets consider the salvation of all these shortcomings to make our site password maximally secure. To hide transmitted data is rather easy with the help of POST method. In this case browser will transmit data directly to server (hidden from users), and it will be possible to catch it only by special programs or with the help of hackers.

As was said before, user lists must be saved separately from code page. Lets create the table in test database:

Add several records to it:

Now lets add a mechanism of correct checking user name and password directly in database:

And the last thing for good site password system: we need to teach a server to remember the fact of registration. The easiest way is implementing of session mechanism into the code. Lets make mecessary changes:

Subscription management software

Members area script

Website protection

Membership software