Page 1 of 1

Encrypted password in session variable?

Posted: Mon Apr 07, 2008 10:52 pm
by loneCoder
Hello,

I am in the middle of a long project, and I have run into a security issue that I am not sure how to handle. I have a server with hundreds of user accounts. I am using PHP to access each users home directory (using ssh2_sftp). I need to store the users login credentials in a session variable, but I can not hash the password before storing as I usually would since I need to use this password in its plain text form.

My thought was to use a two way encryption and store the encrypted text in a session variable and the key in a cookie on the users computer. That way, if the server were compromised, there would be no way to gain access to a plain text password. Has anyone ever tried somthing similar? -or- Does anyone have a better idea to throw my way?

--Jordan

Re: Encrypted password in session variable?

Posted: Tue Apr 08, 2008 1:33 pm
by Mordred
A cookie-stealing XSS is much more likely to happen than database disclosure, so I can't say it's good as it stands.

How would you use (i.e. how often) the password? If ~once per session, you can encrypt it with a key = random + user_login_password (think of it as two-factor authorization: something you have and something you know). Keep the random in a cookie. Ask for the login password when you need to use the shell password.

In that way:
- a stolen session and cookie will not work without the login password.
- a compromised database will have the encrypted password (and maybe the user login) but will still lack the random from the cookie
- a compromised database and stolen cookie will still be time-resistant to attack if the user login is protected with a salt-and-pepper hash with LONG site-wide salt. You will have time to alert the users to change their shell and account passwords (you still need a system to detect the breach though)

Re: Encrypted password in session variable?

Posted: Tue Apr 08, 2008 8:09 pm
by loneCoder
Thanks for the quick response.

Your solution is similar to what I had in mind, but I will need to use the shell password multiple times per session. The application I am building is a simple file browser. It will have the functionality of moving, stat-ing, deleting etc. Each of these tasks will be sent in a separate SSH request.

The user’s web login password is the same as their shell login. This password is stored (hashed) in a database. You make a solid point about the cookie stealing. What if I stored the password encrypted in a session variable in the form sessionVariable = encrypt(password . "secret string" . salt). Then re-write the links on the page to send the salt back to the server on the next request (using SSL). An attacker would need to steal the session cookie, have read access to the PHP script to get the secret string and find some way of stealing the salt from the server request.

Any thoughts?

Re: Encrypted password in session variable?

Posted: Thu Apr 10, 2008 6:12 am
by Mordred
loneCoder wrote:What if I stored the password encrypted in a session variable in the form sessionVariable = encrypt(password . "secret string" . salt). Then re-write the links on the page to send the salt back to the server on the next request (using SSL). An attacker would need to steal the session cookie, have read access to the PHP script to get the secret string and find some way of stealing the salt from the server request.
No, the attacker can still use a XSS to steal both the session id and the salt (whether you keep it in a link parameter or cookie is irrelevant). He will then replicate the request with the same session id and salt, with no need to know the secret string, since the server will do the job of decrypting the password. You can try to lock the session to IP, but that's unfortunately not a universal solution.
The user’s web login password is the same as their shell login. This password is stored (hashed) in a database.
This may be an easier point of entry in case of database breach. [plug="shameless"]Read my article [plug].

I don't have time now to think about the implications of the user login in this, but I intuitively feel there should be a simpler solution in this case.