Today I want to talk about really unproductive topic – that is how to code poorly. Or, more exactly, I am going to pick on my unfavorite  piece of social site again, that is Boonex. We will talk about how one should not implement user sessions and how to do it better.
Boonex uses unencrypted cookies to store session data, that is member ID and hashed member password. Each request Boonex checks database for memberID and password combination. This is to ensure that the person would be logged off the system if password is changed by someone else.
Thus, what is the problem with this approach?
Well, what about making hashed passwords save on PC user logs in? These passwords remain available till user explicitly logs out.  And the hash used is a simple md5 hash which is fast one-way function. You cannot reverse it, but it is susceptible for dictionary or brute force attacks. There are databases for such md5 strings as well.
You could partly solve that problem by using a seed with the hashed password. However, it would make the password guessing game more complex but not impossible. Also, you do not need the password for being logged in, just the cookies. And it is quite simple to change values in them with Firefox.
Another problem we had is with effectiveness of this password checking. It is one of multiple requests that are done on each page load. Even when they are fast, they affected boonex performance, which is quite bad anyways. But caching this information makes a security hole open:  ID could be changed and your system could be compromised.
It is much safer to save session information on server side.  PHP native session management is much better than what boonex has to offer, thus you should switch to it in the code (I have demo version of boonex  7 on August, it still has this problem).   It is quite some work, but it is worth it. Or, even better, look for some other social network script.

Today I want to talk about really unproductive topic – that is how to code poorly. Or, more exactly, I am going to pick on my unfavorite  piece of social site again, that is Boonex. We will talk about how one should not implement user sessions and how to do it better.boonex

Boonex uses unencrypted cookies to store session data, that is member ID and hashed member password. Each request Boonex checks database for memberID and password combination. This is to ensure that the person would be logged off the system if password is changed by someone else.

Thus, what is the problem with this approach?

Well, what about making hashed passwords save on PC user logs in? These passwords remain available till user explicitly logs out.  And the hash used is a simple md5 hash which is fast one-way function. You cannot reverse it, but it is susceptible for dictionary or brute force attacks. There are databases for such md5 strings as well.

You could partly solve that problem by using a seed with the hashed password. However, it would make the password guessing game more complex but not impossible. Also, you do not need the password for being logged in, just the cookies. And it is quite simple to change values in them with Firefox.

Another problem we had is with effectiveness of this password checking. It is one of multiple requests that are done on each page load. Even when they are fast, they affected boonex performance, which is quite bad anyways. But caching this information makes a security hole open:  ID could be changed and your system could be compromised.

It is much safer to save session information on server side.  PHP native session management is much better than what boonex has to offer, thus you should switch to it in the code (I have demo version of boonex  7 on August, it still has this problem).   It is quite some work, but it is worth it. Or, even better, look for some other social network script.


Giedrius Majauskas

I am a internet company owner and project manager living at Lithuania. I am interested in computer security, health and technology topics.

0 Comments

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *