Login system based on SOAP database

Question

I have recently been challenged with coming up with a Login framework which holds user data in a separate database which I connect via a SOAP connection. Now, I have done something along these lines before using only MySQL.

Now to come up with the login system, I store the user info returned in $_SESSION variables; They return the password in plaintext (along with some other information) - not sure why - however, I do not store that password in plaintext; rather I encrypt the password with an unique key for each user.

To check if the user is currently connected I use their sessions using 2 different parameters hashed together and compare to the logged_in__string which is done at log in; this is the basic setup:

$_SESSION['logged_in__string'] = hash ( 'sha512', 'USER_PASSWORD' . $_SERVER['HTTP_USER_AGENT'] );

After I create that, I encrypt the password using an unique key for each user; Then create a new function, check() which will decrypt the password, and create the hashed value compare it to the $_SESSION['logged_in__string'] and if equal then user is logged in.

My interest is in the $_SESSION variables. What are some potential risks in the approach I have taken, and if there are any, what are some good methods to secure these sessions for the user.

Answer 1

Hash your passwords

First of all, it sounds like the database stores password in plaintext. That is very, very, very bad. See this question for how to do it right.

The problem with your system

Now, to your actual question. The aim of your system is to stop session hijacking. However, it does nothing of the sort. If I steal one of your users session cookie and send it in a request to your server, how would you know it was stolen? All your system does is decrypt the password the real user provided at logg in and check that it is correct, which it always will be. Your system basically boils down to checking that password = password with some "magic crypto dust sprinkled on top" (to quote Androl Genhald).

To see this, write down your system in simplified pseudo code and then go through how the server would behave in case of an attack with pen and paper. I find that is a useful technique for problems like this.

A bit besides the point, but: Only using one round of SHA-256 is not enough for hashing passwords. And storing the encrypted data and the key at the same place is not a good idea.

The solution

Keep it simple:

$_SESSION['logged_in'] = true

Then, to protect against session hijacking, you can do the following:

• Use good HTTPS.
• Make sure your session IDs have sufficient entropy.
• Mark the session cookie as secure and HTTP-only.
• Watch out for XSS.

Your system also makes sure that the user agent stays constant during a session. This is only limited protection since the user agent can be easily spoofed, but it might help against an unsofisticated attacker. If you want to keep that check, simply store the original user agent in the session and then at every request check that the user agent header is the same as the one you have stored.