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

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

Best practice, (secure), to save session data?

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

Contents

  Best practice, (secure), to save session data? Simon <bad@example.com> - 2012-06-14 10:35 +0200
    Re: Best practice, (secure), to save session data? Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-14 07:46 -0400
    Re: Best practice, (secure), to save session data? Chris Davies <chris-usenet@roaima.co.uk> - 2012-06-14 13:52 +0100
      Re: Best practice, (secure), to save session data? Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-14 12:30 -0400
        Re: Best practice, (secure), to save session data? Chris Davies <chris-usenet@roaima.co.uk> - 2012-06-15 08:46 +0100
          Re: Best practice, (secure), to save session data? Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-15 07:04 -0400
            Re: Best practice, (secure), to save session data? Chris Davies <chris-usenet@roaima.co.uk> - 2012-06-15 16:20 +0100
              Re: Best practice, (secure), to save session data? Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-15 16:25 -0400
                Re: Best practice, (secure), to save session data? Chris Davies <chris-usenet@roaima.co.uk> - 2012-06-18 19:02 +0100
                  Re: Best practice, (secure), to save session data? Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-18 15:13 -0400
                    Re: Best practice, (secure), to save session data? Chris Davies <chris-usenet@roaima.co.uk> - 2012-06-18 23:12 +0100
                      Re: Best practice, (secure), to save session data? Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-18 21:30 -0400
                      Re: Best practice, (secure), to save session data? Arno Welzel <usenet@arnowelzel.de> - 2012-06-19 08:37 +0200
    Re: Best practice, (secure), to save session data? Arno Welzel <usenet@arnowelzel.de> - 2012-06-15 22:44 +0200

#6325 — Best practice, (secure), to save session data?

Hi,

We have a site where many users can login/logout, (giving them access to 
their personal information).

The users have 2 choices, either we 'remember' the user after they close 
their browsers or not, (for up to 30 days).

We create a unique cookie id and we store/retreive the data based on 
that unique id.

But that means a read + a write every single time any user hits the 
site. I realise that it is a very small operation with a tiny amount of 
overhead, but I wonder if it is the 'best' solution.

It was suggested that I base64_encode/base64_decode the data as a cookie 
but I am not sure about the security implications of doing that, (the 
way I see it, if they can get the session cookie then they can just as 
well access the base64_encoded data anyway).

We have an https site, but we also allow login/access via http.

Any tutorial/reading material/suggestions on how I can store logged in 
users credentials.

Thanks

Simon

[toc] | [next] | [standalone]

#6327

On 6/14/2012 4:35 AM, Simon wrote:
> Hi,
>
> We have a site where many users can login/logout, (giving them access to
> their personal information).
>
> The users have 2 choices, either we 'remember' the user after they close
> their browsers or not, (for up to 30 days).
>
> We create a unique cookie id and we store/retreive the data based on
> that unique id.
>
> But that means a read + a write every single time any user hits the
> site. I realise that it is a very small operation with a tiny amount of
> overhead, but I wonder if it is the 'best' solution.
>
> It was suggested that I base64_encode/base64_decode the data as a cookie
> but I am not sure about the security implications of doing that, (the
> way I see it, if they can get the session cookie then they can just as
> well access the base64_encoded data anyway).
>
> We have an https site, but we also allow login/access via http.
>
> Any tutorial/reading material/suggestions on how I can store logged in
> users credentials.
>
> Thanks
>
> Simon
>

Anything stored on the user's machine is subject to compromise.  Base64 
encoding data provides absolutely no security.  And you're right, if 
someone has access to the cookie, they have access to the data.

It's just like handing someone the key to your car.  They can take your 
car any time they want.  There is no way around this.

If you're concerned about the security implications, don't save the 
cookie (and keep relatively short timeouts on your sessions).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

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

#6328

Simon <bad@example.com> wrote:
> the way I see it, if they can get the session cookie then they can
> just as well access the base64_encoded data anyway.

Almost.

1. If you put the data in the session cookie as base64 then it can be
decoded and viewed any time someone likes. No security.

2. If you encrypt the data into the cookie using a secret known only to
the website then at least someone has to go to the bother of trying to
brute force the data string, but they have as much time as they like to
do so. Password security.

3. If you put a session key in the cookie with, say, a 4 hour timeout on
the webserver side where the real data is stored, then after the timeout
has expired the session key is useless to anyone trying to obtain your
client's data. Time security.

You have to trade off password-based vs time-based security. Generally
#3 is the preferred solution.

Chris

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

#6329

On 6/14/2012 8:52 AM, Chris Davies wrote:
> Simon<bad@example.com>  wrote:
>> the way I see it, if they can get the session cookie then they can
>> just as well access the base64_encoded data anyway.
>
> Almost.
>
> 1. If you put the data in the session cookie as base64 then it can be
> decoded and viewed any time someone likes. No security.
>
> 2. If you encrypt the data into the cookie using a secret known only to
> the website then at least someone has to go to the bother of trying to
> brute force the data string, but they have as much time as they like to
> do so. Password security.
>

Incorrect.  They don't need to break the string.  All they have to do is 
send the cookie.  The server doesn't care which client the cookie came from.

> 3. If you put a session key in the cookie with, say, a 4 hour timeout on
> the webserver side where the real data is stored, then after the timeout
> has expired the session key is useless to anyone trying to obtain your
> client's data. Time security.
>

Yes, but if there's personal data, 4 hours may be too long.

> You have to trade off password-based vs time-based security. Generally
> #3 is the preferred solution.
>
> Chris


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

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

#6331

>> 2. If you encrypt the data into the cookie using a secret known only to
>> the website then at least someone has to go to the bother of trying to
>> brute force the data string, but they have as much time as they like to
>> do so. Password security.
>>

Jerry Stuckle <jstucklex@attglobal.net> wrote:
> Incorrect.  They don't need to break the string.  All they have to do is 
> send the cookie.  The server doesn't care which client the cookie came from.

No. Read what I said again, in the context of the OP's comment. He was
talking about putting the real data into the cookie.

Chris

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

#6332

On 6/15/2012 3:46 AM, Chris Davies wrote:
>>> 2. If you encrypt the data into the cookie using a secret known only to
>>> the website then at least someone has to go to the bother of trying to
>>> brute force the data string, but they have as much time as they like to
>>> do so. Password security.
>>>
>
> Jerry Stuckle<jstucklex@attglobal.net>  wrote:
>> Incorrect.  They don't need to break the string.  All they have to do is
>> send the cookie.  The server doesn't care which client the cookie came from.
>
> No. Read what I said again, in the context of the OP's comment. He was
> talking about putting the real data into the cookie.
>
> Chris

I read it.  The thing you miss is the hacker doesn't need to decode the 
encrypted data in the cookie.  All he needs to do is send it - just like 
the original client would.

He won't have the password - but he doesn't need it.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

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

#6333

Jerry Stuckle <jstucklex@attglobal.net> wrote:
> I read it.  The thing you miss is the hacker doesn't need to decode the 
> encrypted data in the cookie.  All he needs to do is send it - just like 
> the original client would.

You're (still?) missing my differentiator between this and a session
cookie.


> He won't have the password - but he doesn't need it.

It wasn't about having a password (implicit with the cookie or otherwise),
it was having access to the data stored directly in the cookie itself.

Chris

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

#6336

On 6/15/2012 11:20 AM, Chris Davies wrote:
> Jerry Stuckle<jstucklex@attglobal.net>  wrote:
>> I read it.  The thing you miss is the hacker doesn't need to decode the
>> encrypted data in the cookie.  All he needs to do is send it - just like
>> the original client would.
>
> You're (still?) missing my differentiator between this and a session
> cookie.
>
>
>> He won't have the password - but he doesn't need it.
>
> It wasn't about having a password (implicit with the cookie or otherwise),
> it was having access to the data stored directly in the cookie itself.
>
> Chris

It would help if you were to quote the relevant comments.  You said:

"2. If you encrypt the data into the cookie using a secret known only to
the website then at least someone has to go to the bother of trying to
brute force the data string, but they have as much time as they like to
do so. Password security."

As I stated - this is not correct.  No one needs to "brute force the 
data string" to get logged in - all they have to do is send the cookie.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

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

#6370

Jerry Stuckle <jstucklex@attglobal.net> wrote:
> As I stated - this is not correct.  No one needs to "brute force the 
> data string" to get logged in - all they have to do is send the cookie.

My original quote suggested option 2 as getting access to the data stored
in the cookie. Real data stored in the cookie, not a session value that
would/could get you access to the data stored on the website. That you
might also be able to log in is a potential side-effect and was (from
my perspective, at least) irrelevant.

Chris

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

#6374

On 6/18/2012 2:02 PM, Chris Davies wrote:
> Jerry Stuckle<jstucklex@attglobal.net>  wrote:
>> As I stated - this is not correct.  No one needs to "brute force the
>> data string" to get logged in - all they have to do is send the cookie.
>
> My original quote suggested option 2 as getting access to the data stored
> in the cookie. Real data stored in the cookie, not a session value that
> would/could get you access to the data stored on the website. That you
> might also be able to log in is a potential side-effect and was (from
> my perspective, at least) irrelevant.
>
> Chris

Yes, and my point was - you don't NEED access to the encrypted data. 
All you need to do is send a copy of the cookie itself to log in.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

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

#6377

Jerry Stuckle <jstucklex@attglobal.net> wrote:
> Yes, and my point was - you don't NEED access to the encrypted data. 
> All you need to do is send a copy of the cookie itself to log in.

At no point until my most recent did I suggest this cookie might even
provide an authentication service. In the scenario as described it
contains (encrypted) information, not an authentication token.

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

#6378

On 6/18/2012 6:12 PM, Chris Davies wrote:
> Jerry Stuckle<jstucklex@attglobal.net>  wrote:
>> Yes, and my point was - you don't NEED access to the encrypted data.
>> All you need to do is send a copy of the cookie itself to log in.
>
> At no point until my most recent did I suggest this cookie might even
> provide an authentication service. In the scenario as described it
> contains (encrypted) information, not an authentication token.

The op's question was how to use cookies for authentication.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

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

#6379

Chris Davies, 19.06.2012 00:12:

> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>> Yes, and my point was - you don't NEED access to the encrypted data. 
>> All you need to do is send a copy of the cookie itself to log in.
> 
> At no point until my most recent did I suggest this cookie might even
> provide an authentication service. In the scenario as described it
> contains (encrypted) information, not an authentication token.

Maybe you missed the point in the OP:

"The users have 2 choices, either we 'remember' the user after they
close their browsers or not, (for up to 30 days).

We create a unique cookie id and we store/retreive the data based on
that unique id."

And "remembering a user for up to 30 days" means "if a cookie is set,
the user does not have to log in" to me.



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

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

#6338

Simon, 14.06.2012 10:35:

> We have a site where many users can login/logout, (giving them access to
> their personal information).
> 
> The users have 2 choices, either we 'remember' the user after they close
> their browsers or not, (for up to 30 days).

Which means, everybody who copies the cookie has access to the personal
information.

> It was suggested that I base64_encode/base64_decode the data as a cookie
> but I am not sure about the security implications of doing that, (the
> way I see it, if they can get the session cookie then they can just as
> well access the base64_encoded data anyway).

Yep.

> We have an https site, but we also allow login/access via http.
> 
> Any tutorial/reading material/suggestions on how I can store logged in
> users credentials.

You can't. Either you ask the user to enter the password/key *always* or
the application becomes less secure, since the only security is that the
cookie is not copied by an attacker. There is no "comfortable" way.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [standalone]

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

csiph-web