session management

[mrr]

I have a friend that is handling session only with well, session variables.
I always thought that was done with cookies.

So when a member logs in, he checks in his database for
username/password and (if ok) then populates other session variables
which values are specific to this particular user.
On any page of the site, PHP begins by looking at those variables and
see if someone is logged in.
The user logs out either by clicking a dedicated link on the website,
either when shutting down the browser. That's fine for him.

So no cookie, I never thought of staying that simple and it looks to
work nicely.

Is there any security/complication concern I should warn him about, in
this particular session handling?

--
mrr

[Erwin Moller]

I think (but might be wrong) you are confusing the session cookie with
the actual session variables.

Session-variables are ONLY on the server.
You access them in PHP from $_SESSION[].
The Client (browser in most cases) never sees them.

Since http is stateless, the visitor is unknown to the server.
That is solved with a session-cookie.
It looks like this:
PHPSESSID:3hgsdfa5fhjgfsd8fhjg

As an aside: You don't HAVE TO use a cookie, you can also pass the
sessionid in the URL, or in a POST, depending on your configuration.
Bottomline is that the server sees a session-id and looks up if there
exists a session with that id.

This way you can store information on the server, coupled to a certain
visitor, and, despite the stateless nature of http, maintain a sort of
state.
For example:
if ($_SESSION["isAdmin"]=="Y"){
// is allowed to do admin stuff
}


Now, securitywise:
1) Stealing the sessionid
It is a good habbit to change the sessionid each invocation.
(Look up "session fixation")
Also, don't use the URL to pass the session-id around.


2) Protect the serverside storage:
Serverside: If somebody has access to the directory where the session
are stored, that person can look into the session.
I once was in a shared hosting environment where I could see, AND read
all sessions of PHP, even the once belonging to other people's website.
(But this was long ago.)

3) man-in-the-middle-attack
If security is important, use https over http because https is harder to
understand if somebody is listening on your line.

Hope this helps a bit.

Regards,
Erwin Moller


--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens

[Ben Bacarisse]

mrr <mir...@free.fr> writes:

> I have a friend that is handling session only with well, session variables.
> I always thought that was done with cookies.

It's not either/or. It is common that a cookie is used for the session
ID, though not for the variables themselves.

> So when a member logs in, he checks in his database for
> username/password and (if ok) then populates other session variables
> which values are specific to this particular user.
> On any page of the site, PHP begins by looking at those variables and
> see if someone is logged in.
> The user logs out either by clicking a dedicated link on the website,
> either when shutting down the browser. That's fine for him.
>
> So no cookie, I never thought of staying that simple and it looks to
> work nicely.

Yes, PHP can manage the session without one. Are you sure that's what's
going on here?

> Is there any security/complication concern I should warn him about, in
> this particular session handling?

Yes, but I don't think this kind of security question can be answered,
with this little data, in a short Usenet post.

--
Ben.

[mrr]

On 03/05/2015 11:54 AM, Erwin Moller wrote:
> On 3/5/2015 8:51 AM, mrr wrote:
>> I have a friend that is handling session only with well, session
>> variables.
>> I always thought that was done with cookies.
>>
>> So when a member logs in, he checks in his database for
>> username/password and (if ok) then populates other session variables
>> which values are specific to this particular user.
>> On any page of the site, PHP begins by looking at those variables and
>> see if someone is logged in.
>> The user logs out either by clicking a dedicated link on the website,
>> either when shutting down the browser. That's fine for him.
>>
>> So no cookie, I never thought of staying that simple and it looks to
>> work nicely.
>>
>> Is there any security/complication concern I should warn him about, in
>> this particular session handling?
>>
>
> I think (but might be wrong) you are confusing the session cookie with
> the actual session variables.

It looks like I'm confused about their respective possible roles I think.

> Session-variables are ONLY on the server.
> You access them in PHP from $_SESSION[].
> The Client (browser in most cases) never sees them.
>
> Since http is stateless, the visitor is unknown to the server.

Here I guess is the answer to my question, I'm interest especially by
the word "stateless".

> That is solved with a session-cookie.
> It looks like this:
> PHPSESSID:3hgsdfa5fhjgfsd8fhjg

My friend swore me he doesn't use (nor need so) cookie. I don't yet have
access to his code. On the other side he is still a beginner (6 months
of many hours a day learning, no previous studies) and he sometimes uses
advanced functionality (inside some JavaScript frameworks for example)
without really knowing what's going on.

> As an aside: You don't HAVE TO use a cookie, you can also pass the
> sessionid in the URL, or in a POST, depending on your configuration.
> Bottomline is that the server sees a session-id and looks up if there
> exists a session with that id.

I see and get what you're saying here and after.

EDIT: Is what I'm saying down the message the same as what you're saying
in the next few lines?

> This way you can store information on the server, coupled to a certain
> visitor, and, despite the stateless nature of http, maintain a sort of
> state.
> For example:
> if ($_SESSION["isAdmin"]=="Y"){
> // is allowed to do admin stuff
> }
>
>
> Now, securitywise:
> 1) Stealing the sessionid
> It is a good habbit to change the sessionid each invocation.
> (Look up "session fixation")
> Also, don't use the URL to pass the session-id around.
>
>
> 2) Protect the serverside storage:
> Serverside: If somebody has access to the directory where the session
> are stored, that person can look into the session.
> I once was in a shared hosting environment where I could see, AND read
> all sessions of PHP, even the once belonging to other people's website.
> (But this was long ago.)
>
> 3) man-in-the-middle-attack
> If security is important, use https over http because https is harder to
> understand if somebody is listening on your line.
>
> Hope this helps a bit.

Sure it does, thanks.

> Regards,
> Erwin Moller
>

Despite your answer, I'm still a bit confused.

I thought session variables were tight to a session with a particular
client.
Let's say you have 2 registered users in your database, Charles and
Aude. On you main page you have a "connection" link that leads you to a
form where you're asked for your name. The client enter "Charles", the
server checks and sees "Charles" in the database. It founds it, fill in
a "name" session variable with "Charles" and eventually retrieve
Charles' personal information in the database.

Now Aude comes in and connect too.

The server is dealing with 2 sets of session variables. It knows that
Charles and Aude are connected (and will be connected for ever until
they restart their browsers).

So now:
If Charles click to visit further the website, the server *has* to know
that it's dealing with the set of session variable where name="Charles",
with that particular session, no?
If so, on each page of the website Charles visit, the server could first
test for the value of the name variable and if present in the database
prints whatever it wants about Charles.

Does it makes sense?
Of course, in real world you would check for a password too.

--
mrr

[Erwin Moller]

It might be possible you and your friend have a misunderstanding about
the role of the cookie.
He possibly thinks he isn't storing any sensitive information in cookies
(as he shouldn't). He is "only" storing the session-id.

(Not sure, I am guessing here)

No problem. I like to help. :-)

>
> I thought session variables were tight to a session with a particular
> client.

That is correct.

> Let's say you have 2 registered users in your database, Charles and
> Aude. On you main page you have a "connection" link that leads you to a
> form where you're asked for your name. The client enter "Charles", the
> server checks and sees "Charles" in the database. It founds it, fill in
> a "name" session variable with "Charles" and eventually retrieve
> Charles' personal information in the database.

OK.

>
> Now Aude comes in and connect too.
>
> The server is dealing with 2 sets of session variables. It knows that
> Charles and Aude are connected (and will be connected for ever until
> they restart their browsers).

correct.

>
> So now:
> If Charles click to visit further the website, the server *has* to know
> that it's dealing with the set of session variable where name="Charles",
> with that particular session, no?

Maybe.
What actually happens (but I didn't see your code of course) is
something like this:

1) You present the visitor a page with a login: username and password
for example.
They reside in a form. Form is posted, and server does something like this:

<?php

session_start(); // Or use session.autostart in php.ini

// Receive posting
$username = $_POST["username"];
$password = $_POST["password "];

// Check against database:
$SQL = "SELECT userid, isadmin, cansendemail FROM tblusers where
((username={$username}) AND (password={$password}))";
// NEVER use the above example as I posted.
// You should make sure you are not vunurable to SQL injection
// make sure you escaped $username and $password properly.

// some phantasy execute:
$RS = $conn->getAllAssoc($SQL);

if (isset($RS[0])){
// OK, we know this person.
// Now here the session gets filled
$_SESSION["validUser"] = "Y";
$_SESSION["userid"] = $RS[0]["userid"];
$_SESSION["isadmin"] = $RS[0]["isadmin"];
$_SESSION["cansendemail"] = $RS[0]["cansendemail"];
header("location: http://www.blabla.com/customersOnly.php");
exit;
} else {
// wrong username/password
}

?>


The latter part is what matters.
The session is already running (and will be accessible from every page
that has session_start() at the top).
You set some values in it, in my example:
$_SESSION["validUser"]
$_SESSION["userid"]
$_SESSION["isadmin"]
$_SESSION["cansendemail"]

Now from some other page, eg customersOnly.php, you can check if the
visitor is logged in correctly, simply by checking $_SESSION["validUser"].

eg:
<?php
if ( isset($_SESSION["validUser"]) && ($_SESSION["validUser"]=="Y")){
// do stuff.
} else {
// not welcome
}
?>


Remember the content of $_SESSION never leave the server, but PHP can
use them whenever you need access to them.

> If so, on each page of the website Charles visit, the server could first
> test for the value of the name variable and if present in the database
> prints whatever it wants about Charles.

No. The database is NOT involved.
(Unless you write your own session handler, which is, I expect, not
happening since your friend just started coding.)


Of course you can check against the database every request, but that is
a huge waste of resources.
You should check once, and then rely on the values you have set in your
session. Like my example above with $_SESSION["validUser"].

>
> Does it makes sense?
> Of course, in real world you would check for a password too.
>

I hope my example helps you understand the interaction between login
(with or without password), session, and subsequent checks on other
pages against the values in the session.

Also, don't take my word for it.
Use a webbrowser like Firefox, install an extension named webdeveloper,
or one of the many others, and you can easily see all the cookies going
round.
You will see only 1 session-cookie coming from PHP.

[J.O. Aho]

On 05/03/15 13:59, mrr wrote:
> On 03/05/2015 11:54 AM, Erwin Moller wrote:
>> On 3/5/2015 8:51 AM, mrr wrote:


>> That is solved with a session-cookie.
>> It looks like this:
>> PHPSESSID:3hgsdfa5fhjgfsd8fhjg
>
> My friend swore me he doesn't use (nor need so) cookie. I don't yet have
> access to his code. On the other side he is still a beginner (6 months
> of many hours a day learning, no previous studies) and he sometimes uses
> advanced functionality (inside some JavaScript frameworks for example)
> without really knowing what's going on.

He may not use the setcookie() function, just the session_start()
function, this will create the session cookie, which is just a normal
cookie which stores a session identifier.

There is a way to do this without a cookie, then you add the session id
information to the URL. This is less secure than using the cookie.

> I thought session variables were tight to a session with a particular
> client.

In default configuration it's just tied to the session id, but you can
make your custom session handler and use the IP or/and user agent to tie
the session even closer to one specific user, but users may use tor
which could give you another IP next time you request the page and of
course both IP and user agent can be spoofed.

> Let's say you have 2 registered users in your database, Charles and
> Aude. On you main page you have a "connection" link that leads you to a
> form where you're asked for your name. The client enter "Charles", the
> server checks and sees "Charles" in the database. It founds it, fill in
> a "name" session variable with "Charles" and eventually retrieve
> Charles' personal information in the database.

Charles has a cookie saying session id is weouiyr23uoi23

> Now Aude comes in and connect too.
>
> The server is dealing with 2 sets of session variables. It knows that
> Charles and Aude are connected (and will be connected for ever until
> they restart their browsers).

Aude has now a cookies saying session id is p09o4355rwesljh3

> So now:
> If Charles click to visit further the website, the server *has* to know
> that it's dealing with the set of session variable where name="Charles",
> with that particular session, no?

Charles browser will send the cookie with the session id weouiyr23uoi23
every time he is loading a page, the PHP will then look up the session
file which is stored on disk and store the data to the $_SESSION array.

> If so, on each page of the website Charles visit, the server could first
> test for the value of the name variable and if present in the database
> prints whatever it wants about Charles.

By default session is stored on a file, but you can write your own
session handler which uses a database instead.
(no databases do not print, the fetch data and send it to clients, like
php).


--

//Aho

[Thomas 'PointedEars' Lahn]

Erwin Moller wrote:

> As an aside: You don't HAVE TO use a cookie, you can also pass the
> sessionid in the URL, or in a POST, depending on your configuration.

But (to summarize and add to your only partially quoted recommendations
further below) if you do that you make your application susceptible to
attacks. Using a session cookie is the safest approach. Let the session
expire after a time of inactivity automagically (you can accomplish that by
making requests in the background as long there is activity), and make sure
that the session cookie is HTTP-only to prevent attacks that use client-side
scripting. See also Cookie laws (e.g., EU regulations regarding storing
sensitive information).

> […]

> Now, securitywise:
> 1) Stealing the sessionid
> It is a good habbit to change the sessionid each invocation.

(Is it a habbit or a hare? ;-))

Correct. And the session should have a unique name:

<http://php.net/session_name>

> (Look up "session fixation")

<http://php.net/session_regenerate_id>

> 2) Protect the serverside storage:
> Serverside: If somebody has access to the directory where the session
> are stored, that person can look into the session.
> I once was in a shared hosting environment where I could see, AND read
> all sessions of PHP, even the once belonging to other people's website.
> (But this was long ago.)

The recommendation (and most common implementation, which *differs* from the
PHP defaults) is to have a subdirectory or database for storing session
information, per application, where only the system user running the Web
server (and maybe the system user of the admin of the application) has
access. (It appears to be a little known fact that PHP can transparently
use a database to store session information instead of in separate files in
the file system.)

--
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[mrr]

On 03/05/2015 02:18 PM, Erwin Moller wrote:
>
> Regards,
> Erwin Moller
>

Thanks again Erwin and also to all the other participants (I wont
overload the thread by answering to each messages!)

Now I have a better inside in session management and most of all I have
enough information to understand how search more info (and some of you
gave me a glimpse about security concerns and that matters a lot for me).

For the record, my friend does use a session-start at the beginning of
each of his pages. And I will have a look at one of those firefox
extensions, as you suggested. As to be able to dissect the behavior of
his website.

For the record n°2, I'm much more at ease with C or even Java but I
decided to jump into the 'PHP-JavaScript-Ajax' web world and I see there
are some quite competent people here so you might see me again (I do
realize I won't learn everything here and I'll keep my questions for
non-usual/specific matters).

Have a nice week-end!

--
mrr

[J.O. Aho]

On 06/03/15 13:47, mrr wrote:

> For the record n°2, I'm much more at ease with C or even Java but I
> decided to jump into the 'PHP-JavaScript-Ajax' web world and I see there
> are some quite competent people here so you might see me again (I do
> realize I won't learn everything here and I'll keep my questions for
> non-usual/specific matters).

PHP has some similarities to C, but gives you a lot for "free" as it
handles sessions for you and other global variables, you can do the same
in C, but you need to do so much more yourself. Once in the time there
was quite many C written cgi, nowadays many of those projects switched
to PHP.



Side note:
There are other alternatives for PHP for those who want to solve things
with other methods, see Mono/C#, python, ruby and jsp for starters and
there are those who more or less relay on javascript.


--

//Aho

[Jørn Andersen]

On Thu, 05 Mar 2015 14:18:27 +0100, Erwin Moller
<erwinmol...@xs4all.nl> wrote:

>What actually happens (but I didn't see your code of course) is
>something like this:
>
>1) You present the visitor a page with a login: username and password
>for example.
>They reside in a form. Form is posted, and server does something like this:
>
><?php
>
>session_start(); // Or use session.autostart in php.ini
>
>// Receive posting
>$username = $_POST["username"];
>$password = $_POST["password "];
>
>// Check against database:
>$SQL = "SELECT userid, isadmin, cansendemail FROM tblusers where
>((username={$username}) AND (password={$password}))";
>// NEVER use the above example as I posted.
>// You should make sure you are not vunurable to SQL injection
>// make sure you escaped $username and $password properly.

And *never* save passwords in clear text in a database.
User passwords should *always* be hashed!

Good luck,
Jørn

--
Jørn Andersen
http://socialister.dk
http://marxisme.dk

[J.O. Aho]

Hashing ain't enough, you need to salt it too, speacially if using weak
hashing like sha1.

--

//Aho

[Richard Damon]

On 3/7/15 5:59 AM, jo...@jorna.dk wrote:
>
> And *never* save passwords in clear text in a database.
> User passwords should *always* be hashed!
>
> Good luck,
> Jørn
>

I will agree to the first, but the second always isn't quite true.

There are a few cases where you need to be able to recover the original
password, so hashing isn't viable. The biggest example is if the user is
providing credentials to access some third party resource, in which case
you need to be able to recover exactly what was given to provide to that
third party.

In this case it is still a good idea to at least somewhat encrypt the
password so it isn't idlely visible in the database.

This case isn't common (it shouldn't be), as the user really needs to
have a lot of trust in the site to give it their 3rd party password, and
at least for me, most of the cases where I have done this, the "user"
providing the credentials was the site owner or related individual, and
the 3rd party site was also under their control but for various reasons
not able to have an otherwise trusted access link.

[Erwin Moller]

Use rot13() for that.
http://php.net/manual/en/function.str-rot13.php

(That was a joke, for those who wonder.)

[mrr]

On 03/07/2015 02:21 PM, J.O. Aho wrote:

> Hashing ain't enough, you need to salt it too, speacially if using weak
> hashing like sha1.

English isn't my first language so I'm not sure how that is meant to be
understand?

Was that a joke?

Or should I really begin to search for some technique about adding salt
to a hashed password?

--
mrr

[Jerry Stuckle]

No, it's not a joke. It's very good advice. Salting adds security to
the hash.

One of the tricks I use on all password hashing (even more secure ones)
is to use the userid (or at least part of it) and a random string
(different on each site) along with the password to hash the password
(even though I don't use weak hashes).

This way the same password for two different users on one site end up
with different hashes, as well as the same user on two different sites.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Christoph M. Becker]

There's a good FAQ regarding password hashing in the PHP manual:

<http://php.net/manual/en/faq.passwords.php>

--
Christoph M. Becker

[mrr]

Thanks guys, actually I now find the idea so logical that I ask myself
why I haven't think about it by myself :)

--
mrr

[Jørn Andersen]

On Sat, 07 Mar 2015 14:21:15 +0100, "J.O. Aho" <us...@example.net>
wrote:
<snip>

>> And *never* save passwords in clear text in a database.
>> User passwords should *always* be hashed!
>
>Hashing ain't enough, you need to salt it too, speacially if using weak
>hashing like sha1.

That is true in many (most) cases. And since it’s very easy to do with
newer PHP versions (5.5+), no doubt it’s best practice.

However, since there is no such thing as “absolute security”, the
difference between no hashing and weak hashing like sha1 (or even md5)
is much bigger than the difference between weak hashing and a good
salted hashing.

Saving an unhashed password in a database means that *anyone* with
access to the database can read it directly. Even weak hashing makes
this much more difficult.

Any security measure needs to be considered in context: What are you
trying to protect? What are the weak spots? And what are you willing
to pay for the security you want?

[Christoph M. Becker]

jo...@jorna.dk word:

> On Sat, 07 Mar 2015 14:21:15 +0100, "J.O. Aho" <us...@example.net>
> wrote:
> <snip>
>>> And *never* save passwords in clear text in a database.
>>> User passwords should *always* be hashed!
>>
>> Hashing ain't enough, you need to salt it too, speacially if using weak
>> hashing like sha1.
>
> That is true in many (most) cases. And since it’s very easy to do with
> newer PHP versions (5.5+), no doubt it’s best practice.

ACK.

> However, since there is no such thing as “absolute security”, the
> difference between no hashing and weak hashing like sha1 (or even md5)
> is much bigger than the difference between weak hashing and a good
> salted hashing.

IMO, hashing unsalted passwords with md5 is only marginally better than
storing the passwords directly[1], but you're still having all the
disadvantages of having hashed passwords. At the very least put a
little salt in--better strech the hashes additionally. And of course,
don't reinvent the wheel--use a library developed by experts.

[1] <https://www.google.com/#q=ec34ab51842c0c4dd543d6eb04894c23>

--
Christoph M. Becker