Log In

How to join?
About Project
netsago NetSago
Authorisation system on environment variables. by n0xi0uzz

Phrack all issues downloader by n0xi0uzz

Artilces — Authorisation system on environment variables.

Authorisation system on environment variables.
14 September 2006 21:30

Tags: perl, authorisation

Print (opens in new window)

In this tutorial I'll try to give a detailed look at creating and using authorisation and web-session control system on environment variables.
At first time I've got interest to this subject in consequence of Dmitry Zernov (also known as malgajan) and his works in this sphere (in russian language). But Dmitry wasn't able to continue this works, so I did that cause I use this system in my projects.
Now I have viable system with positive (and of course, negative) sides. I still work with it, but main principles have already formulated and realized. So, about this principles I want to tell in this tutorial.
Notice: All illustrations of code written in Perl.

Information about user (especially, his password) are stored at web-server in encrypted form. For encryption I used standart function of Perl crypt(); (which usually realizes method of encryption DES), like this:
crypt($password, $password);
In this example variable $password contains user's password. You see that for password encryption you can use any method of encryption. So, user fills authorisation form on website, our script encrypt password using chosen method of encryption and this password compares with stored on server password.
If password is correct, script is starting to form data for web-session. Sessions realized using additional CGI-parameter (hash) in this system, which adds to each link on website.

Session control.
So, for confirmation of user's authorisation we should get and form data about user and keep it during user's session. Also we should be sure that user's hash is correct and used by that user, who get it. And for advancing security was realized session timeout, — if user don't use hash during fixed time, system deletes such hash.
System forms hash on three environment variables — REMOTE_ADDR, HTTP_USER_AGENT, HTTP_X_FORWARDED_FOR (according as user's IP-address, information about user's browser and information from proxy-server). Also, for full security, system generates random integer number from 0 to 99. This number stores on server with other information about session. Formation of hash is quite simply: first of all, system counts "control sum" (counting sum of symbol numbers for each variable):
foreach $item (@ENVs)
    foreach ((split(//, $item))) {$hash += ord(($_));};
So, "control sum" is in variable $hash. Then system generates random integer number and encrypts "contorl sum" by random number using crypt(); function (or maybe more likely method of encryption for you). To make length of all hashes fixed, system "cuts" them. Here is example of code:
$id = int(rand(99));
$hash = substr(crypt($hash, $id), 2, 8);
Hash and random number (and maybe other info about user, e.g. his access level or his nickname/login) system saves on server. Also system saves time of authorisation for realization timeout. I've used standart Perl function time(); for this aim.
Then system adds gotten hash to each link on the website. And when user tries to get access to protected information, system checks his hash. Again in the same way script forms hash, but in this case system doesn't generate random integer number, it takes saved number from server; and compares gotten hash with the saved one. Then system counts time of current checking and also compares with the saved one. If everything is correct, system updates session data via changing saved on server time to current. And if something wrong, system deletes all session data from server and redirects user.

Positive and negative sides.
As I said before, this system of authorisation and web-session control has it's positive and negative sides like everything in our world. That's why I don't want tell you much about it, but here are the main ideas:
"+" User don't save any data on his computer (it's difference from authorisation systems wich use cookies). So, we don't care about client's security.
"-" There is no any technology wich will be remember user, so he should authorise when timeout ends.
Also, I recommend to use more effective method of encryption (e.g. Blowfish).

Thematic links.
Example of web-authentication Dmitry Zernov aka malgajan (in russian language)

© Victor Cherkasov aka n0xi0uzz, 2006

Tags: perl, authorisation

Articles with same tags:

Post to LiveJournal with Perl

Advanced Search
Report a Bug
If you find a bug on our site please report us.
6 / 918
Today we have 45 visits by robots. They want to kill all humans.

Registered users: 0
Online: 0

Page build time: 0.010 sec
NetSago.v2.β © [2006;∞)  Neunica