Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #15042 > unrolled thread

session management

Back to article view | Back to comp.lang.php

Contents

  session management mrr <mireero@free.fr> - 2015-03-05 08:51 +0100
    Re: session management Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-03-05 11:54 +0100
      Re: session management mrr <mireero@free.fr> - 2015-03-05 13:59 +0100
        Re: session management Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-03-05 14:18 +0100
          Thank all! Re: session management mrr <mireero@free.fr> - 2015-03-06 13:47 +0100
            Re: Thank all! Re: session management "J.O. Aho" <user@example.net> - 2015-03-07 08:53 +0100
          Re: session management Jørn Andersen <jorn@jorna.dk> - 2015-03-07 11:59 +0100
            Re: session management "J.O. Aho" <user@example.net> - 2015-03-07 14:21 +0100
              Re: session management mrr <mireero@free.fr> - 2015-03-11 22:23 +0100
                Re: session management Jerry Stuckle <jstucklex@attglobal.net> - 2015-03-11 16:40 -0400
                Re: session management "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-03-11 21:59 +0100
                  Re: session management mrr <mireero@free.fr> - 2015-03-13 01:05 +0100
              Re: session management Jørn Andersen <jorn@jorna.dk> - 2015-03-13 02:37 +0100
                Re: session management "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-03-13 02:54 +0100
            Re: session management Richard Damon <Richard@Damon-Family.org> - 2015-03-07 11:29 -0500
            Re: session management Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-03-09 11:29 +0100
        Re: session management "J.O. Aho" <user@example.net> - 2015-03-05 18:22 +0100
      Re: session management Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-03-06 11:33 +0100
    Re: session management Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-05 11:55 +0000

#15042 — session management

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

[toc] | [next] | [standalone]

#15044

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.

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

[toc] | [prev] | [next] | [standalone]

#15046

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

[toc] | [prev] | [next] | [standalone]

#15047

On 3/5/2015 1:59 PM, mrr wrote:
> 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.

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)



>
>> 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.

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.

Regards,
Erwin Moller



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

[toc] | [prev] | [next] | [standalone]

#15064 — Thank all! Re: session management

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

[toc] | [prev] | [next] | [standalone]

#15067 — Re: Thank all! Re: session management

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

[toc] | [prev] | [next] | [standalone]

#15068

On Thu, 05 Mar 2015 14:18:27 +0100, Erwin Moller
<erwinmollerusenet@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

[toc] | [prev] | [next] | [standalone]

#15070

On 07/03/15 11:59, jorn@jorna.dk wrote:
> On Thu, 05 Mar 2015 14:18:27 +0100, Erwin Moller
> <erwinmollerusenet@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!

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

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#15099

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

[toc] | [prev] | [next] | [standalone]

#15100

On 3/11/2015 5:23 PM, mrr wrote:
> 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?
> 

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
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#15101

mrr wrote:

> 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?

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

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

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#15102

On 03/11/2015 09:59 PM, Christoph M. Becker wrote:
> mrr wrote:
>
>> 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?
>
> There's a good FAQ regarding password hashing in the PHP manual:
>
> <http://php.net/manual/en/faq.passwords.php>
>

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

-- 
mrr

[toc] | [prev] | [next] | [standalone]

#15103

On Sat, 07 Mar 2015 14:21:15 +0100, "J.O. Aho" <user@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?

Good luck,
Jørn

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

[toc] | [prev] | [next] | [standalone]

#15104

jorn@jorna.dk word:

> On Sat, 07 Mar 2015 14:21:15 +0100, "J.O. Aho" <user@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

[toc] | [prev] | [next] | [standalone]

#15072

On 3/7/15 5:59 AM, jorn@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.

[toc] | [prev] | [next] | [standalone]

#15094

On 3/7/2015 11:59 AM, jorn@jorna.dk wrote:
> On Thu, 05 Mar 2015 14:18:27 +0100, Erwin Moller
> <erwinmollerusenet@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
>


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

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

Regards,
Erwin Moller


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

[toc] | [prev] | [next] | [standalone]

#15053

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

[toc] | [prev] | [next] | [standalone]

#15063

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.

[toc] | [prev] | [next] | [standalone]

#15045

mrr <mireero@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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web