Storing passwords in sessions, why?

[rawkes]

What is the reasoning behind storing the users password in a session / cookie? Where else would it be used apart from authenticating the user the very first time they log in (before the session is even created)?

[glowdot]

How else would you know that they have actually logged in, and not just bypassed the login page to get to the privileged page?

[rawkes]

Because a session would exist with their userID, surely? I just don't understand the use of the password after they have used it to log in.

[glowdot]

Ah, I think I misunderstood your question.

If you don't need the password later, then you don't need to store it. As for storing it in a cookie though, this is sometimes used to allow sessions to be authenticated across subdomains (although there are other, better ways).

[php_daemon]

Bad practice in any case.

[spikeZ]

Never store sensitive information in a session/cookie or otherwise. there is absolutley NO need to store anything sensitive other than perhaps an id number so you can query the database.

[rawkes]

This is exactly what I thought, but time and time again I see threads here with people storing the username and password in the session/cookie and wanted to know if there was any reason for their madness.

[php_daemon]

Yep, be very careful of what you're picking up on the net. You can get lots of ideas and learn a lot but you can pick up bad practices just as easy.

[rawkes]

I was having another think about this. I understand storing a password in the session is pointless, but say the user ticked "Remember me for 2 weeks" when they log in - wouldn't I need to store the password in the cookie so they get logged in automatically in say 3 days time? It's just if I only stored the userID in the cookie, then they could easily change that and log themselfs in as someone else without entering a password.

[frank1]

well
when people start coding in php ..most book ..tutorials found in the net...shows using session rather than storing in database


so people are not able to give that habit for long term....
so

[AlienDev]

All you ever need to store in a session is the user id and a string on random characters (created when user registers and stored in database). Then use the SQL:

SELECT *
FROM users
WHERE user_id = {$_SESSION['user_id']}
AND hash = {$_SESSION['hash']}

[rawkes]

All you ever need to store in a session is the user id and a string on random characters (created when user registers and stored in database). Then use the SQL:

SELECT *
FROM users
WHERE user_id = {$_SESSION['user_id']}
AND hash = {$_SESSION['hash']}

That makes sense, It could be made even more secure by changing the HASH stored in the db/session/cookie every so often. Thanks for the tip.

[rawkes]

All you ever need to store in a session is the user id and a string on random characters (created when user registers and stored in database).

That makes sense, It could be made even more secure by changing the HASH stored in the db/session/cookie every so often. Thanks for the tip.

[Lysyi]

Storing passwords in cookie - definitely NOT!
Just because it could be easily stolen because they're sent unencrypted over the web.

But storing passwords in session may make sense.
Session vars are not passed through http and so could not be stolen.
For example, for integrating two scripts together.
I recently integrated a flashchat script into phpfox.
When a user logs into phpfox his username/password are stored into session.
And if then he decides to visit the chat, a scripts performs automatic authentication, taking username/password from session, so the user doesn't need to login again.
Now I'm integrating a webmail script into the same instance of phpfox using the same scheme.
So in the case of integrating several scripts together storing passwords in session (but NOT in cookies) may make a lot of sense and be very useful

[spikeZ]

Guy's, have you not heard of SESSION HIJACKING?

Sessions are NOT as secure as you may think.
http://en.wikipedia.org/wiki/Talk:Session_hijacking
http://shiflett.org/articles/session-hijacking
http://www.sitepoint.com/blogs/2004/...sion-security/
http://www.google.com/search?client=...utf-8&oe=utf-8

Just some articles on the subject.

[Lysyi]

Guy's, have you not heard of SESSION HIJACKING?

okay, when session is hijacked, all you can steal is just the sessionID.
so you can have access to the user's member zone for a limited time until he logs out.
but you don't have access to session variables
for this you must have access to the server's hard disk
so the password still remains secure

[-T-]

My rules of thumb
1. store as little information about the user
in cookies, userid (and maybe hashed + salted version of the password if it's a remember me cookie, so the user can't just change the cookie to get access to others accounts. Though, make sure you use a different salt then you use in the database, or even better, make a hash of the hashed password stored in the database with a new salt)

2. keeping information about the user in sessions is somewhat safe, but you have to make sure you do not print out the contents of the session to the user anywhere, and make sure that they are not stored in the default dir (/tmp in nix boxes). If they are stored in the default dir they can be read by other people on the server (only true on shared hosts, but still a nice rule to keep in hand at all times)


Spikez, even though a session is hijacked the information stored in it can not be read unless the script itself reads and print it out to the user. A session hijacking does not give the hijacker access to more information about the user then the user can see in the on the page himself. And if he has the session, he can go into the usercp (or whatever you want to call it) and get information on the user. It really doesn't matter if it's stored in the database or the session, the information is there.

I'm not saying it's impossible to get information out of a session, but it's not the direct fault of a hijacking.

[kromey]

FYI, the default configuration for PHP is to store sessions as world-readable/writable files in a temporary directory. This means that even in shared hosting situations that are "secure" because they use su_exec (or similar), your sessions are still there to be read by anybody on the server. This includes anyone who manages to gain control of another users' badly-coded app. When you know this, I can't imagine any reason why you would ever store anything sensitive in a session even if it isn't sent across the web.

For Lysyi's situation where s/he needed to integrate several scripts together, I would use a temporary table to store the user's password and not store them in a session variable. Although honestly I'd spend more time hacking to make sure I didn't need to even do that (I've written complicated login scripts that effectively log a user into multiple different apps at the same time, thus completely negating the need to store the user's password in plaintext anywhere while still seamlessly integrating disparate session schemes).

[Lysyi]

Kromey,
but it's quite secure for dedicated servers?
and what about co-location?

could you let me take a look at your complicated login scripts' code?
are any of them open source?

regards,
Ilya

[kromey]

Ilya,
Sadly I'm not at liberty to share my complicated login scripts - they were written for the company I worked for at the time and thus belong to them. However, since the concept behind them is not patented (nor can it be, seeing as there is prior art and it is an obvious idea), I will share the way I created them:

Each app has its own login code. This code needs only the user's username and password (rarely are there any exceptions to this), and it takes care of everything that needs doing to log the user into the app (setting up the session or setting its own cookie or whatever). Thus the general approach is to wrap each app's login code in its own function which is then called in sequence from your site's login script, and voila! your users are logged in to every app on your site!

The only time this gets tricky is when multiple apps use identical $_SESSION variables. I solve this by doing find&replace in each app, replacing "$_SESSION['" with "$_SESSION['$app_", where $app is a unique prefix for that application (e.g. a prefix for phpBB might be "pbb", turning $_SESSION['user'] into $_SESSION['pbb_user']). Another option here would be two-dimensional $_SESSION array, e.g. $_SESSION['pbb']['user'], which may help debugging if you need to dump the $_SESSION array.

Another sticky spot I ran into once was two separate apps that took care of their own session handling by setting cookies; the problem was both apps named their cookies "login". Of course, since both were written such that the only code that directly accessed these cookies was the login code that I copied into my uber-login script and a single include that was called at the top of every file, changing the name of the cookies was easy (I used the same app-specific prefix that I used for $_SESSION variables for these cookies, so they became "app1_login" and "app2_login").

Yes, it takes some work to pull off, but it's more secure than storing passwords in plaintext where anyone can read them.

However, you are right, Ilya, when you point out that on dedicated servers, virtual dedicated servers, and co-located servers, world-readable session files are not a significant risk; most people, however, are in shared hosting situations and thus need to be aware of the significant risk they put their users in when they store passwords in such an insecure manner.

[Lysyi]

Yes, Kromey, a very interesting approach. Maybe I will use it in my future work. Thank you for the idea.

But I think I have an idea how to make sessions very, very secure even on a shared hosting.
Let's just encrypt the variables with Mcrypt!
It supports many powerful algorythms, for example AES which is adopted as an encryption standard by the U.S. government.
The key can be stored in a non-world-readable file on server, or in the database.
We just encrypt all variables with mcrypt, and then just decrypt them when needed. The process is very fast and won't eat up a lot of resources.
I think in many cases it could be a more faster solution than storing data in mysql. Or I'm wrong?
And even if someone reads session files on a shared hosting, s/he won't get any data, just a cipher without the key.

But still the problem of cookie or session id hijacking remains.
To solve this problem needed something like "unsent cookie".
That is a cookie which is stored in client's browser only and isn't sent over the web.
This also could be a text file on user's hard disk. The file stores the password.
With every http request server sends a challenge string in a cookie. The browser combines it with the stored password using HMAC and in the next request to the server sends the md5 (or sha1) of this. The server performs analogous operation itself and compares results. This is called CHAP (Challenge-handshake authentication protocol).
So authentication is made at every request, and even if a cookie is hijacked, the hijacker won't get into the member zone without knowing the password.
But how to implement this?
There is no support for "unsent cookies" in browsers. Javascript cannot access files on clients computer (or can?). Maybe this can be done with Java?
What do you think?

[kromey]

It's very similar to how NTLM or Kerberos work. Unfortunately, seamless integration in a browser- and platform-agnostic is unbelievably difficult. Getting Kerberos working is easier than NTLM (unless you're a Windows-only shop), but it's still no trivial task, and there still seem to be plenty of browsers who do not support Kerberos (IE and FF do, however I believe (but have not tested) that Safari, Opera, Konquerer do not). Add to the fact that Kerberos is designed for LAN setups and not the internet, and you have a complex problem.

I once dreamed up a scheme where every response from the server included a one-time-use token (stored in a cookie); the next request must include this token or be rejected. This makes session hijacking more difficult (you not only need a valid session ID, you need the appropriate token as well), but is still far from fool-proof.

Another idea I had was a lot more complex and completely destroys accessibility because it requires the user have a modern browser with JavaScript enabled: every page request is in fact an AJAX request. The user in actuality never leaves index.php, and instead is sending requests via AJAX. This enables a JavaScript-based CHAP scheme similar to what you described possible (because no, JavaScript cannot access local files, nor is there anything like an "unsent cookie"). The downsides are a site on which your users cannot bookmark particular pages (since they're always on index.php, they always bookmark index.php), it completely fails when JavaScript is disabled or otherwise unavailable (thus completely destroying accessibility), and users who watch the location bar may be confused by the fact that they never appear to move.

I suppose it may be possible to achieve a similar effect by using JavaScript to set a cookie for your domain (you can't set cookies for other domains anyway) but for a non-existent path, thus creating a cookie that is in effect never sent. I'm going to run some tests and see if this is possible...

Edit:


Yes, you can set cookies for non-existent paths. Unfortunately, cookies are only available to the page if they would be sent to the server on this request. Thus setting a cookie for a non-existent path is useless because you can never access it.

[Lysyi]

Your idea with AJAX is great!
I beleive there are only some 5% users who turn off javascript in their browsers.

I think integration of "unsent cookie" into browsers is much easier than Kerberos or NTLM.
Maybe it's worth of becoming a standart for all browsers?
And what about not Javascript, but Java. Do you know if it can create and access files on user's hard disk?

[kromey]

I've never used Java (aside from a school project once where I had to put a ready-made Java applet on my website) and am completely unaware of its abilities in this regard.

If you don't mind locking out your users who don't have JavaScript, then by all means use my AJAX idea. Most of my sites need to be accessible (i.e. people who need to use screen readers need to be able to use it just as well as Eagle-Eye Joe with his 20/10 vision), so it's not something I can use. My sites use JavaScript to enhance the experience, but I take great care to ensure that the entire site can be used effectively without JavaScript (and for that matter, without even CSS).

[kibblerok]

All you ever need to store in a session is the user id and a string on random characters (created when user registers and stored in database). Then use the SQL:

SELECT *
FROM users
WHERE user_id = {$_SESSION['user_id']}
AND hash = {$_SESSION['hash']}

This is how i currently do this, are there any downsides to this method?

Would anything extra be overkill?