| Best practice, (secure), to save session data? [message #178402] |
Thu, 14 June 2012 08:35  |
Simon
Messages: 29
Registered: February 2011
Karma: 0
|
Junior Member |
|
|
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
|
|
|
|
| Re: Best practice, (secure), to save session data? [message #178404 is a reply to message #178402] |
Thu, 14 June 2012 11:46  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Best practice, (secure), to save session data? [message #178405 is a reply to message #178402] |
Thu, 14 June 2012 12:52 |
Chris Davies
Messages: 6
Registered: June 2012
Karma: 0
|
Junior Member |
|
|
Simon <bad(at)example(dot)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
|
|
|
|
| Re: Best practice, (secure), to save session data? [message #178406 is a reply to message #178405] |
Thu, 14 June 2012 16:30 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 6/14/2012 8:52 AM, Chris Davies wrote:
> Simon<bad(at)example(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Best practice, (secure), to save session data? [message #178407 is a reply to message #178406] |
Fri, 15 June 2012 07:46 |
Chris Davies
Messages: 6
Registered: June 2012
Karma: 0
|
Junior Member |
|
|
>> 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(at)attglobal(dot)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
|
|
|
|
| Re: Best practice, (secure), to save session data? [message #178408 is a reply to message #178407] |
Fri, 15 June 2012 11:04 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Best practice, (secure), to save session data? [message #178409 is a reply to message #178408] |
Fri, 15 June 2012 15:20 |
Chris Davies
Messages: 6
Registered: June 2012
Karma: 0
|
Junior Member |
|
|
Jerry Stuckle <jstucklex(at)attglobal(dot)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
|
|
|
|
| Re: Best practice, (secure), to save session data? [message #178412 is a reply to message #178409] |
Fri, 15 June 2012 20:25 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 6/15/2012 11:20 AM, Chris Davies wrote:
> Jerry Stuckle<jstucklex(at)attglobal(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Best practice, (secure), to save session data? [message #178414 is a reply to message #178402] |
Fri, 15 June 2012 20:44 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Best practice, (secure), to save session data? [message #178446 is a reply to message #178412] |
Mon, 18 June 2012 18:02 |
Chris Davies
Messages: 6
Registered: June 2012
Karma: 0
|
Junior Member |
|
|
Jerry Stuckle <jstucklex(at)attglobal(dot)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
|
|
|
|
| Re: Best practice, (secure), to save session data? [message #178450 is a reply to message #178446] |
Mon, 18 June 2012 19:13 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 6/18/2012 2:02 PM, Chris Davies wrote:
> Jerry Stuckle<jstucklex(at)attglobal(dot)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(at)attglobal(dot)net
==================
|
|
|
|
|
|
| Re: Best practice, (secure), to save session data? [message #178454 is a reply to message #178453] |
Tue, 19 June 2012 01:30 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 6/18/2012 6:12 PM, Chris Davies wrote:
> Jerry Stuckle<jstucklex(at)attglobal(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Best practice, (secure), to save session data? [message #178455 is a reply to message #178453] |
Tue, 19 June 2012 06:37 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Chris Davies, 19.06.2012 00:12:
> Jerry Stuckle <jstucklex(at)attglobal(dot)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
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]