RE: [php-49] Security question: benefits, if any, of using 'session_regenerate_id'

From: user 7.
Sent on: Thursday, December 11, 2008 2:21 PM
First, a direct comment -- don't use MD5. There are enormously
comprehensive rainbow tables for MD5 that can give the attacker clear
insight into your algorythm, so use SHA2.


As a security guy, I have a couple of more general comments on this thread.

First, there are two major patterns for session hijacking. The first is to
intercept communications and then submit the session key in a seperate
request. Let's call this an information disclosure attack since the
session key is disclosed.

The second major pattern is to take advantage of a predictable pattern in
key generation and to submit a likely-valid key. Let's call this one a
spoofing attack, because an identity is spoofed through key pattern
analysis. They're both spoofing attacks, sure, but we'll name them for the
sake of clarity.

The discussion so far hasn't make the distinctions between these two
attack patterns. Now on to the mitigations.

Using a sufficiently entropic key (salted, complex, whatever you want to
call it) will only mitigate the spoofing attack pattern. If you insist on
building your own algorythm, it should be unpredictable even if your
random number generator is broken and always returns the same value --
don't rely on random numbers. And again, no MD5.

Personally, I would rely on managed code here and allow PHP to
autogenerate the session id. If it's broken, then someone smarter than me
will fix it and all I have to do is patch.

Mitigations against information disclosure pattern:

- Session keys should have a both a fixed expiration (1 hour, 1 day,
whatever makes business sense) and they should have a timeout expiration.
This limits the time a session key is useful even if disclosed.

- You should always have an authentication event when you change the
session key or when a key expires.

- Encrypt everything and use a common SSL authority. If you?re scaling
this out, this isn?t realistic but works fine in low-volume sites with
protected assets.

-Encrypt protected/sensitive assets if you can't encrypt everything. When
a user enters a protected or sensitive area of the application, everything
should be encrypted. You should require an authentication event when
switching from http to https, which leads to:

-Remember that session ids that are sent via plaintext are vulnerable to
interception. This is why you often have to re-enter a password before
making a purchase. The application is re-establishing a trusted,
authenticated session.

-Add an additional, dynamic token. This is usually done for XSRF
mitigation but is useful here as well. Issue a ?security? token with each
page delivered. When the user clicks on to another page, the security
token is submitted and a new/different security token is issued. You want
to do this independently of a session token ? if the submitted security
token doesn?t match the expected one, you can fail to an authentication
event that doesn?t lose all of the session information. These tokens can
be in POST, GET, hidden field, etc, so long as it?s a shared
secret/one-time token. I wouldn?t suggest cookies since many people
disable them, and the URL would be the easiest implementation since you
can include it in anchor tags while generating a page.

-Any time a security token check fails, you should fail *all* use of the
session token. If the session has been hijacked, both the legit session
and attacker will face an authentication event. This will catch a hijack
the next time the legit user hits a page.

Better than all of this -- used managed code. A good framework will do all
of this for you automatically. I'll leave the discussion about which one
to another thread.

-- Don



> Yeah, that is actually what I do. I use a counter hash as a session id
> then use a random hash which can change as a way to authenticate the id. I
> have my own session handler which is database based.
>
> Thing to note when doing this is php sessions don't have a way to do this
> automaticly. You will need to set and maintain another cookie to be used
> as your hash, or attach a url string. Thought I should state this since
> the thread started off talking about session_regenerate_i­d. Might be
> confusing to some that reference this.
>
> ____________________­____________________­
> From: [address removed] [[address removed]] On Behalf Of Richard
> [[address removed]]
> Sent: Thursday, December 11,[masked]:12 AM
> To: [address removed]
> Subject: Re: [php-49] Security question: benefits, if any, of using
> 'session_regenerate_­id'
>
> Instead of using the session_id to make your hash uniquie per user..
> Store an md5 in the session.. Its not used as the session id, its just
> used to verify your hash.
>
> Richard Thomas
> http://www.cyberl...­
>
>
>
> On Dec 11, 2008, at 11:08 AM, Mike Ree wrote:
>
>> I'm not sure how this would work. Sounds like your saying use your
>> own random md5 as the session id. So in a sence this would be using
>> your own sessions rather than php's built in sessions.
>>
>> By session id i mean what you use to reference the session.
>>
>> ____________________­____________________­
>> From: [address removed] [[address removed]] On Behalf Of Richard
>> [[address removed]
>> ]
>> Sent: Thursday, December 11,[masked]:02 AM
>> To: [address removed]
>> Subject: Re: [php-49] Security question: benefits, if any, of using
>> 'session_regenerate_­id'
>>
>> Simple fix, Don't use the session id in the hash, instead store a
>> random MD5 in your session to use as part of the hash, now it follows
>> the user even if the session is regenerated.
>>
>>
>> Richard Thomas
>> http://www.cyberl...­
>>
>>
>>
>> On Dec 11, 2008, at 10:52 AM, Mike Ree wrote:
>>
>>> If you have multiple windows opened and change the session it will
>>> mess up all other windows session information. That is a good reason
>>> why you don't want to change it too often. But it is good to
>>> understand that sessions can be hijacked and for security reasons
>>> you may want to change it from time to time.
>>>
>>> ____________________­____________________­
>>> From: [address removed] [[address removed]] On Behalf Of Ryan
>>> Biesemeyer [[address removed]]
>>> Sent: Thursday, December 11,[masked]:42 AM
>>> To: [address removed]
>>> Subject: Re: [php-49] Security question: benefits, if any, of using
>>> 'session_regenerate_­id'
>>>
>>> I don't see much of a benefit to using this function, actually. Sure,
>>> it introduces the concept of 'moving targets', but it also introduces
>>> a lot of likelihood for odd behavior, and the function itself is not
>>> very well documented.
>>>
>>> E.G.: Application uses a form token system that relies on a hash of
>>> time(), session_id(), salt, and $userID, ensuring that a form is from
>>> the person, session, and time-range I expect before processing it. If
>>> I were to implement session_regenerate_i­d(), any form that was
>>> previously opened (background tabs, additional windows, etc) would
>>> fail token validation and therefore not be processed, despite the
>>> fact
>>> that the token is within its lifetime.
>>>
>>> More importantly though, if a session *was* hijacked, it would be
>>> equally likely that the cracker would inherit the new session_id and
>>> the legit user would lose the session (if not more likely, as a
>>> purposeful hacker would be loading pages at a higher rate than a
>>> normal user, thus hitting the script more often).
>>>
>>> I don't see many benefits to using this; looks like complexity for
>>> complexity's sake.
>>>
>>> -Ryan
>>>
>>> On Wed, Dec 10, 2008 at 6:15 PM, Ian Maddox <[address removed]> wrote:
>>>> This is topical:
>>>> http://www.server...­
>>>>
>>>> It is an interesting post on session hijacking that briefly covers
>>>> session_regenerate_i­d().  However, you need to use this function
>>>> with
>>>> caution.  You must make sure to delete the old session. This can be
>>>> done by
>>>> passing true into the function or by using session_destroy(). By
>>>> default,
>>>> the session is merely copied and not actually renamed, so a
>>>> compromised
>>>> sessionID could still be used by an attacker to access a user's
>>>> account.
>>>>
>>>> --Ian
>>>>
>>>> On Mon, Dec 8, 2008 at 10:45 PM, David Malouf <[address removed]>
>>>> wrote:
>>>>>­
>>>>>­ Came across this function (http://us3.php.ne...­
>>>>>­ session_regenerate_i­d).
>>>>>­
>>>>>­ Is this used (at the beginning of each PHP/'view' script) to help
>>>>>­ prevent
>>>>>­ 'session-stealing' (or whatever is the correct title for this
>>>>>­ idea)?
>>>>>­
>>>>>­ What else can/should/might this function be used for?
>>>>>­
>>>>>­
>>>>>­ David
>>>>>­
>>>>>­
>>>>>­
>>>>>­
>>>>>­
>>>>>­ --
>>>>>­ Please Note: If you hit "REPLY", your message will be sent to
>>>>>­ everyone on
>>>>>­ this mailing list ([address removed])
>>>>>­ This message was sent by David Malouf ([address removed]) from
>>>>>­ The
>>>>>­ Seattle PHP Meetup Group.
>>>>>­ To learn more about David Malouf, visit his/her member profile
>>>>>­ To unsubscribe or to update your mailing list settings, click here
>>>>>­
>>>>>­ Meetup Support: [address removed]
>>>>>­ 632 Broadway, New York, NY 10012 USA
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Please Note: If you hit "REPLY", your message will be sent to
>>>> everyone on
>>>> this mailing list ([address removed])
>>>> This message was sent by Ian Maddox ([address removed]) from The
>>>> Seattle PHP
>>>> Meetup Group.
>>>> To learn more about Ian Maddox, visit his/her member profile
>>>> To unsubscribe or to update your mailing list settings, click here
>>>>
>>>> Meetup Support: [address removed]
>>>> 632 Broadway, New York, NY 10012 USA
>>>
>>>
>>>
>>>
>>> --
>>> Please Note: If you hit "REPLY", your message will be sent to
>>> everyone on this mailing list ([address removed])
>>> http://php.meetup...­
>>> This message was sent by Ryan Biesemeyer ([address removed]) from The
>>> Seattle PHP Meetup Group.
>>> To learn more about Ryan Biesemeyer, visit his/her member profile:
>>> http://php.meetup...­
>>> To unsubscribe or to update your mailing list settings, click here:
>>> http://www.meetup...­
>>> Meetup Support: [address removed]
>>> 632 Broadway, New York, NY 10012 USA
>>>
>>>
>>> --
>>> Please Note: If you hit "REPLY", your message will be sent to
>>> everyone on this mailing list ([address removed])
>>> http://php.meetup...­
>>> This message was sent by Mike Ree ([address removed]) from The
>>> Seattle PHP Meetup Group.
>>> To learn more about Mike Ree, visit his/her member profile:
>>> http://php.meetup...­
>>> To unsubscribe or to update your mailing list settings, click here:
>>> http://www.meetup...­
>>> Meetup Support: [address removed]
>>> 632 Broadway, New York, NY 10012 USA
>>>
>>
>>
>>
>>
>> --
>> Please Note: If you hit "REPLY", your message will be sent to
>> everyone on this mailing list ([address removed])
>> http://php.meetup...­
>> This message was sent by Richard ([address removed]) from The
>> Seattle PHP Meetup Group.
>> To learn more about Richard, visit his/her member profile:
>> http://php.meetup...­
>> To unsubscribe or to update your mailing list settings, click here:
>> http://www.meetup...­
>> Meetup Support: [address removed]
>> 632 Broadway, New York, NY 10012 USA
>>
>>
>> --
>> Please Note: If you hit "REPLY", your message will be sent to
>> everyone on this mailing list ([address removed])
>> http://php.meetup...­
>> This message was sent by Mike Ree ([address removed]) from The
>> Seattle PHP Meetup Group.
>> To learn more about Mike Ree, visit his/her member profile:
>> http://php.meetup...­
>> To unsubscribe or to update your mailing list settings, click here:
>> http://www.meetup...­
>> Meetup Support: [address removed]
>> 632 Broadway, New York, NY 10012 USA
>>
>
>
>
>
> --
> Please Note: If you hit "REPLY", your message will be sent to everyone on
> this mailing list ([address removed])
> http://php.meetup...­
> This message was sent by Richard ([address removed]) from The Seattle PHP
> Meetup Group.
> To learn more about Richard, visit his/her member profile:
> http://php.meetup...­
> To unsubscribe or to update your mailing list settings, click here:
> http://www.meetup...­
> Meetup Support: [address removed]
> 632 Broadway, New York, NY 10012 USA
>
>
> --
> Please Note: If you hit "REPLY", your message will be sent to everyone on
> this mailing list ([address removed])
> http://php.meetup...­
> This message was sent by Mike Ree ([address removed]) from The Seattle PHP
> Meetup Group.
> To learn more about Mike Ree, visit his/her member profile:
> http://php.meetup...­
> To unsubscribe or to update your mailing list settings, click here:
> http://www.meetup...­
> Meetup Support: [address removed]
> 632 Broadway, New York, NY 10012 USA
>
>


Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy