# Regenerating session ID automatically when IP address has changed

- Thread: https://externals.io/message/69303
- Original archive: https://news-web.php.net/php.internals/69303
- Started by Yasuo Ohgaki on 2013-09-24T02:29:25+00:00
- Messages: 35
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/69303.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #69303 — Yasuo Ohgaki — 2013-09-24T02:29:25+00:00

URL: https://externals.io/message/69303#69303

Hi all,

There isn't any good counter measure session hijack.
However, we can regenerate session ID if IP address has changed.
Hijacked users might notice that they have been logged out if session
ID is regenerated by attackers. Therefore, users have slight chance
to notice that they were under attack. It's not greatly effective, but
better than nothing.

Although this can be implemented in user script, it would be better if
session module supports this behavior. Better security by default
is good thing. It requires INI, since some apps may assume session
ID would not change.
(I do not encourage to use session ID for CSRF protection, but
there are such implementations, for example.)

A concern is that there are growing number of browsers share
state. I do not research these browsers behavior yet. I suppose
session cookie (expire=0) would not be shared.

Anyone has any comments on this?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #69304 — Laruence — 2013-09-24T02:42:25+00:00

URL: https://externals.io/message/69303#69304 · In reply to: #69303

Hey:



> Hi all,
>
> There isn't any good counter measure session hijack.
> However, we can regenerate session ID if IP address has changed.
> Hijacked users might notice that they have been logged out if session
> ID is regenerated by attackers. Therefore, users have slight chance
> to notice that they were under attack. It's not greatly effective, but
> better than nothing.
I don't think this is language concerning issue.

it could be done in user script..

thanks
>
> Although this can be implemented in user script, it would be better if
> session module supports this behavior. Better security by default
> is good thing. It requires INI, since some apps may assume session
> ID would not change.
> (I do not encourage to use session ID for CSRF protection, but
> there are such implementations, for example.)
>
> A concern is that there are growing number of browsers share
> state. I do not research these browsers behavior yet. I suppose
> session cookie (expire=0) would not be shared.
>
> Anyone has any comments on this?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net



-- 
Laruence  Xinchen Hui
http://www.laruence.com/

---

## #69306 — Ronald Chmara — 2013-09-24T03:46:46+00:00

URL: https://externals.io/message/69303#69306 · In reply to: #69303

When you have a group of front-end termination points in a pool, proxying
requests off to hundreds of machines for thousands of applications, tying a
session to any IP is a headache. IMO, sessions are supposed to be tied to
users, not any given inbound IP that can, and may, jump between different
routers, proxies, NAT hosts, etc.

-Ronabop




> Hi all,
>
> There isn't any good counter measure session hijack.
> However, we can regenerate session ID if IP address has changed.
> Hijacked users might notice that they have been logged out if session
> ID is regenerated by attackers. Therefore, users have slight chance
> to notice that they were under attack. It's not greatly effective, but
> better than nothing.
>
> Although this can be implemented in user script, it would be better if
> session module supports this behavior. Better security by default
> is good thing. It requires INI, since some apps may assume session
> ID would not change.
> (I do not encourage to use session ID for CSRF protection, but
> there are such implementations, for example.)
>
> A concern is that there are growing number of browsers share
> state. I do not research these browsers behavior yet. I suppose
> session cookie (expire=0) would not be shared.
>
> Anyone has any comments on this?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net

---

## #69328 — Yasuo Ohgaki — 2013-09-25T03:52:16+00:00

URL: https://externals.io/message/69303#69328 · In reply to: #69306

Hi,



> When you have a group of front-end termination points in a pool, proxying
> requests off to hundreds of machines for thousands of applications, tying a
> session to any IP is a headache. IMO, sessions are supposed to be tied to
> users, not any given inbound IP that can, and may, jump between different
> routers, proxies, NAT hosts, etc.


Session is tied to specific user(browser) regardless of IP unless session
ID is hijacked.
Renewing session ID does not matter. Regenerating session ID when IP has
changed
would help users to notice session hijack. This is the sole purpose of
regenerating
session ID when IP has changed. I think only few apps do this now.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #69329 — Yasuo Ohgaki — 2013-09-25T03:55:23+00:00

URL: https://externals.io/message/69303#69329 · In reply to: #69304

Hi Laruence,



> I don't think this is language concerning issue.
>
> it could be done in user script..
>

Session should be managed as secure as possible.
We can promote better session management in document.
It's an option.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #69331 — Mike Willbanks — 2013-09-25T05:16:54+00:00

URL: https://externals.io/message/69303#69331 · In reply to: #69303

> Hi all,
>
> There isn't any good counter measure session hijack.
> However, we can regenerate session ID if IP address has changed.
> Hijacked users might notice that they have been logged out if session
> ID is regenerated by attackers. Therefore, users have slight chance
> to notice that they were under attack. It's not greatly effective, but
> better than nothing.
>
> Although this can be implemented in user script, it would be better if
> session module supports this behavior. Better security by default
> is good thing. It requires INI, since some apps may assume session
> ID would not change.
> (I do not encourage to use session ID for CSRF protection, but
> there are such implementations, for example.)
>
> A concern is that there are growing number of browsers share
> state. I do not research these browsers behavior yet. I suppose
> session cookie (expire=0) would not be shared.
>
> Anyone has any comments on this?
>

Each and every type of prevention measure has consequences and not only
that but MAJOR consequences.  If you are detecting IP changes you rule out
most if not all major proxy networks that exist.  While not first of mind;
when handling this you can easily remove the old session without properly
transitioning to the new.  This is an option based off of individual
application vs. a language option or construct.  There are a ton of
different measures that you might take based off of changes to the end user
data.  I think this would be a poor idea in the long run due to the
consequences that you may incur.

---

## #69332 — Ronald Chmara — 2013-09-25T05:51:59+00:00

URL: https://externals.io/message/69303#69332 · In reply to: #69328

> Hi,
> 
>
> > […]
>
> Session is tied to specific user(browser) regardless of IP unless session
> ID is hijacked.
> Renewing session ID does not matter. Regenerating session ID when IP has
> changed
> would help users to notice session hijack. This is the sole purpose of
> regenerating
> session ID when IP has changed. I think only few apps do this now.
>

So, say you have many front ends, with load balancing, and public IP
addresses. Those front-ends talk on private IP ranges to back-end machines,
so the session can come in from any public IP, be proxied, and handed off.
This, BTW, is not hypothetical, it's about my work with http://appfog.com.
Some actual numbers to explain : Our Singapore location (for example)
has 29,088
websites, with  6 incoming IP addresses talking to 27 website nodes.
Regenerating session keys is a waste of CPU at that scale, as a given
user's requests may jump around 6 different inbound addresses, and any
number of servers.

Takeaway:
1) Binding session to IP doesn't work at scale.
2) Seeing that the IP has "changed" is totally useless to detect hijacking.
3) Session libraries that are expecting state, on the internet, are
fundamentally broken by design.

<rant>
There is no such thing as a secure http session. Ever. The protocol, by
design, does not allow it. Ever. You can add layers (such as https) to make
things "better", but if you want secure communication, don't use the
internet.
</rant>

-Ronabop

---

## #69333 — Yasuo Ohgaki — 2013-09-25T05:55:57+00:00

URL: https://externals.io/message/69303#69333 · In reply to: #69331

Hi Mike,



> Each and every type of prevention measure has consequences and not only
> that but MAJOR consequences.  If you are detecting IP changes you rule out
> most if not all major proxy networks that exist.  While not first of mind;
> when handling this you can easily remove the old session without properly
> transitioning to the new.  This is an option based off of individual
> application vs. a language option or construct.  There are a ton of
> different measures that you might take based off of changes to the end user
> data.  I think this would be a poor idea in the long run due to the
> consequences that you may incur.


The more I get this kind of response, the more I feel we should
introduce this feature as session module optional feature.

Regenerating session ID should not be any problem as long as
session ID is cookie based, save handler lock session data while
it is used.

As far as I know, the only faulty save handler is mm save handler.
(I would like to implement lock in mm, but it's low priority for me.
 When TranSID is enabled, it would cause problems due to cached
 pages.)

The best practice of the session ID management is regenerating
session ID when events happen. Mandatory one is login event.
Web programmers must regenerate session ID to make sure
session safety at login.

IP address change is one of the event, even though it's not mandatory.

There is PHP framework called Piece Framework that has option
regenerate session ID for every request to achieve maximum
session ID security, for example.

If regeneration of session ID causes misbehavior, then it is a bug
including users fault.

I think if I disable this feature when TranSID on and/or expire is not 0,
then there would not be issues. Unless web programmers use session
ID for CSRF protection, etc.

Anyway, I'll start from documentation.
If there are any comments, I'll appreciate it.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #69338 — Madara Uchiha — 2013-09-25T22:49:15+00:00

URL: https://externals.io/message/69303#69338 · In reply to: #69333

Why couldn't this be implemented on userland again? I don't feel this
is a language level issue.


> Hi Mike,
>
> 
>
> > […]
>
>
> The more I get this kind of response, the more I feel we should
> introduce this feature as session module optional feature.
>
> Regenerating session ID should not be any problem as long as
> session ID is cookie based, save handler lock session data while
> it is used.
>
> As far as I know, the only faulty save handler is mm save handler.
> (I would like to implement lock in mm, but it's low priority for me.
>  When TranSID is enabled, it would cause problems due to cached
>  pages.)
>
> The best practice of the session ID management is regenerating
> session ID when events happen. Mandatory one is login event.
> Web programmers must regenerate session ID to make sure
> session safety at login.
>
> IP address change is one of the event, even though it's not mandatory.
>
> There is PHP framework called Piece Framework that has option
> regenerate session ID for every request to achieve maximum
> session ID security, for example.
>
> If regeneration of session ID causes misbehavior, then it is a bug
> including users fault.
>
> I think if I disable this feature when TranSID on and/or expire is not 0,
> then there would not be issues. Unless web programmers use session
> ID for CSRF protection, etc.
>
> Anyway, I'll start from documentation.
> If there are any comments, I'll appreciate it.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net

---

## #69340 — Yasuo Ohgaki — 2013-09-26T01:32:55+00:00

URL: https://externals.io/message/69303#69340 · In reply to: #69338

Hi Madara,



> Why couldn't this be implemented on userland again? I don't feel this
> is a language level issue.
>

PHP is not only language, but also meta framework.
It is better to think as how framework support session. IMHO.
I suppose there aren't many PHP frameworks that implement
session manager by itself.

Any users may implement this by themselves. It's not difficult.

 `session_start()`
if ($_SESSION['IP'] !== $CLIENT_IP) {
   // $CLIENT_IP depends on configuration
   $_SESSION['IP'] = $CLIENT_IP;
   session_regenerate_id(true);
}

The motivation is not make things easier, but to encourage users
use more secure session management. Session ID must be regenerated
when event happens, e.g. login. Session ID should be regenerated
periodically to reduce hijack risk, too. Users should regenerate session
ID anyway. Why not support "should/must be done" operations?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #69343 — Ferenc Kovacs — 2013-09-26T09:07:59+00:00

URL: https://externals.io/message/69303#69343 · In reply to: #69303

> Hi all,
>
> There isn't any good counter measure session hijack.
> However, we can regenerate session ID if IP address has changed.
> Hijacked users might notice that they have been logged out if session
> ID is regenerated by attackers. Therefore, users have slight chance
> to notice that they were under attack. It's not greatly effective, but
> better than nothing.
>
> Although this can be implemented in user script, it would be better if
> session module supports this behavior. Better security by default
> is good thing. It requires INI, since some apps may assume session
> ID would not change.
> (I do not encourage to use session ID for CSRF protection, but
> there are such implementations, for example.)
>
> A concern is that there are growing number of browsers share
> state. I do not research these browsers behavior yet. I suppose
> session cookie (expire=0) would not be shared.
>
> Anyone has any comments on this?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>

1, as you said this regeneration is not feasible for everyone:
in some setups the client remote address not available to php, or through
another environment variable, in other cases the client uses some kind of
proxy or tunnel (tor comes to mind) which causes the source ip to change
between requests, and there are also some ISPs who are doing stuff like
agressive NATing or giving out public IPs through DHCP but with really
short lease times, so the clients are changing IPs frequently.
2, this can be implemented in userland, either in the application
bootstrap, or writing a custom session handler(
http://php.net/manual/en/class.sessionhandler.php).
3, it seems that there is an agreement that introducing language level INI
switches are a bad thing. if we add this, frameworks/apps/etc. which don't
want this feature (because they don't need it, or they have a better
implementation already) would be in a bad spot, because they would either
write some code to detect and circumwent this, or they would have to
educate their users to disable this feature in their installation, which
can be a hard thing to do, as many sites are running on shared hosts, where
doing configuration changes are hard even more when you are requesting to
disable a "security feature".

so to summarize: personally I'm not convinced that this would be useful for
most of the php users, as client IPs changing to frequently to be not
cumbersome for the users to lose their sessions, but this could definitely
break some sites on the internet (php installations behind proxies/load
balancers not passing the original client in in REMOTE_ADDR), and this
would also require countermeasures from the framework/apps/etc. which makes
me vote a -1 on this proposed feature.

maybe this could be shipped as a non-default SessionHandler implementation,
and reuse the current session handler infrastructure and config ini.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

---

## #69347 — Leigh — 2013-09-26T10:19:05+00:00

URL: https://externals.io/message/69303#69347 · In reply to: #69304

>
> I don't think this is language concerning issue.
>
> it could be done in user script..
>
> thanks

I agree entirely with Laurence (and others). This shouldn't be a core
feature. It's not one size fits all.

There's several scenarios where a users IP changes and you don't want to
drop their session. (That doesn't mean it should simply have an option to
disable it either)

Many people still have dynamic IP addresses for their home connections, but
the group who would suffer the most would be mobile users. It's pretty
frustrating to use most sites with a phone as it is, without being kicked
off every time you switch between grps or hsdpa or whatever.

---

## #69348 — Tjerk Meesters — 2013-09-26T10:32:32+00:00

URL: https://externals.io/message/69303#69348 · In reply to: #69347

Hi,




> 
> > […]
>
> I agree entirely with Laurence (and others). This shouldn't be a core
> feature. It's not one size fits all.
>
> There's several scenarios where a users IP changes and you don't want to
> drop their session. (That doesn't mean it should simply have an option to
> disable it either)
>

Let's be clear here: this won't happen (in most cases), because the client
will simply get a new cookie and the session will keep working; it's like
what you would implement if your user level goes from anonymous to logged
in and vice versa.


>
> Many people still have dynamic IP addresses for their home connections, but
> the group who would suffer the most would be mobile users. It's pretty
> frustrating to use most sites with a phone as it is, without being kicked
> off every time you switch between grps or hsdpa or whatever.
>

Aha! I'm glad that you brought up mobile devices, because for those it's
more likely that in certain cases the updated cookie is not received while
the server believes that it was; scenario: "I stepped into an elevator and
was disconnected when I got out.". This makes it an unattractive option to
have enabled by default.




-- 
--
Tjerk

---

## #69359 — Yasuo Ohgaki — 2013-09-26T22:37:47+00:00

URL: https://externals.io/message/69303#69359 · In reply to: #69348

Hi Tjerk,

On Thu, Sep 26, 2013 at 7:32 PM, Tjerk Meesters <tjerk.meesters@gmail.com>wrote:

>
> > […]
>
> Aha! I'm glad that you brought up mobile devices, because for those it's
> more likely that in certain cases the updated cookie is not received while
> the server believes that it was; scenario: "I stepped into an elevator and
> was disconnected when I got out.". This makes it an unattractive option to
> have enabled by default.
>

When IP packets are lost, clients may not receive new session ID.
This may occur when packets are lost while server is trying to set
new session ID cookie. Unless users have really bad connections,
this happens unlikely.

Users who are concerned for this situation should disable it. Users
who are concerned security should accept this case.

The motivation of the feature is to encourage secure session
management to users, not to cover all situations perfectly. Changing
session ID on events is best practice of security. Failures in rare cases
would not make it bad practice.

This feature cannot be enabled by default, since HTTP header that
indicates client IP may vary.

Anyway, how many of us follows session ID management security best
practice?

 - login
 - logout
 - re-authentication (e.g. Require password to change sensitive info)
 - timeout (Long living session ID should be renewed)
 - IP change (This could be hijacked session)
 - else?

Regenerating session ID at login is mandatory, so I suppose
everyone do. (If not, you must.) Generally speaking, if session
ID changes more frequently, hijack attack become more difficult.

Even if session ID is the center of the web security, it is fragile.
Therefore, it should be as secure as possible whenever it can. IMHO.

Regards,

P.S. As I wrote previous mail, I'll start from documentation.
Even if I made patch, it would be an optional feature anyway.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #69360 — Sanford Whiteman — 2013-09-26T22:39:03+00:00

URL: https://externals.io/message/69303#69360 · In reply to: #69348

> Let's be clear here: this won't happen (in most cases), because the client
> will simply get a new cookie and the session will keep working; it's like
> what you would implement if your user level goes from anonymous to logged
> in and vice versa.

I'm glad you addressed this because I'd been thinking that a lot of
people were misinterpreting the common (non-hijacked) scenario,
thinking that session regeneration meant a client-facing logout, which
of course it doesn't as long as the client uses the new id on the next
request.

The concerns about forward and reverse proxies (you would typically
use x-forwarded-for in the second case) seem also off-topic; even
going through multiple proxies of each type won't matter as long as
cache privacy is respected and the end user receives the new id. (One
can argue that the more individual HTTP circuits you need to traverse,
the more likely packets will be dropped, but that seems excessively
paranoid for discussing this feature. I do agree with the server-side
performance impact of very frequent changes on the forward proxy side
forcing thrashing of the session store.)

But the main problem, to me, is handling the aftermath of a hijack
detected in this way. First, the UX factor: is it really feasible to
provide the user with feedback like "You have been logged out for your
protection because your session may have been hijacked by another user
on your network -- now go find out which guy in the coffeeshop is
listening!" That's quite a challenge. I'm sure many of us have seen
the white hat studies of just how easy it is to get people to ignore
warnings in the browser chrome or from runtimes like Java and Flash:
look up the guy who got his office of "techie" Tor users to ignore
redirects between https and http!

I suppose if the victim accepts that something security-related has
gone wrong, they don't have to understand what it was as long they can
do something in response, and the most actionable advice is "You MUST
leave this network immediately because it's insecure." But many people
will ignore this message, and then (if I'm not misunderstanding the
intent here) they will be prompted to log in again, on the same
network. Problem: now the person who's still sniffing the network, who
might have had only their session info before, can possibly sniff
their username and hashed password, which is potentially much, much
worse! (If a fresh login is over SSL but regular traffic is not, and
the attacker was only using primitive sniffing of plaintext, that
would be a mitigator.)

Assuming a fresh login is not itself vulnerable, after authentication,
do you offer (or force?) all other sessions linked to the user id to
be expired? If so, this would of course include a legit session in
another browser or device.

In sum, I'm curious about the expected use of the feature _after_ the
alert goes off. yohgaki?

> Aha! I'm glad that you brought up mobile devices, because for those it's
> more likely that in certain cases the updated cookie is not received while
> the server believes that it was; scenario: "I stepped into an elevator and
> was disconnected when I got out.". This makes it an unattractive option to
> have enabled by default.

Maybe the feature just needs to be disabled by default, yet not being
able to protect against mobile session hijacking because of fear of
lost responses seems like weakening it to the point of uselessness. I
don't know the actual numbers, but I worry most about my users using
their tablets in a coffeshop or hotel and if I had to turn this off
for most mobile browsers, that would be a bit silly (AFAIK, there's
not yet a universally-supported way of distinguishing wifi from mobile
data, i.e. navigator.connection.type).

We all accept that request-response cycles don't always complete on
mobile, particularly on 3G, but I haven't yet seen anyone get metrics
on how common it is based on network behavior _and_ user movement...
also figuring that huge packet loss, once felt by the user, influences
people to decide the network is effectively "down" and to not attempt
any more requests for a while. It would make for an interesting study
and forcibly changing a test cookie on every request (regardless of IP
change) would be part of figuring out how bad the real-world situation
is, at least for a given app and its users.

-- S.

---

## #69362 — Sanford Whiteman — 2013-09-26T22:57:52+00:00

URL: https://externals.io/message/69303#69362 · In reply to: #69359

> Users who are concerned for this situation should disable it. Users
> who are concerned security should accept this case.

I assume "users" are as we understand them here, i.e. me.

But as a developer-user I would likely want to empower my end-users to
turn off this feature themselves. With high-volume sites (not that I
really have any anymore, but a guy can dream) there isn't going to be
a one-size-fits-all regarding connection quality, but there can be a
default INI setting and then a function that we can call to override
it. Paranoid users will turn/leave it on.... any user in a sketchy
connection situation will turn it off (per session or for all their
future sessions).

Which is kind of why this is sounding more and more like a nice
discussion... about a userland solution.

-- S.

---

## #69366 — Yasuo Ohgaki — 2013-09-27T00:08:18+00:00

URL: https://externals.io/message/69303#69366 · In reply to: #69362

Hi Sanford,

On Fri, Sep 27, 2013 at 7:57 AM, Sanford Whiteman <
swhitemanlistens-software@cypressintegrated.com> wrote:

> > […]
>
> I assume "users" are as we understand them here, i.e. me.
>
> But as a developer-user I would likely want to empower my end-users to
> turn off this feature themselves. With high-volume sites (not that I
> really have any anymore, but a guy can dream) there isn't going to be
> a one-size-fits-all regarding connection quality, but there can be a
> default INI setting and then a function that we can call to override
> it. Paranoid users will turn/leave it on.... any user in a sketchy
> connection situation will turn it off (per session or for all their
> future sessions).
>
> Which is kind of why this is sounding more and more like a nice
> discussion... about a userland solution.


Besides the issue with unstable connection, we have URL based
session. When URL based session is used, this feature should be
disabled as pages are cached by browsers.

Even if this change is made, it would not be a default and there would be
INI for client IP header or variable. So no need to worry for being default.
(Did I missed "not" for "not a default" in previous mails? If I did, my
 apologies.)

BTW, if connection is unstable and an app force user to logout,
is it going to be a problem? It would depend on message displayed, but
I guess users think it is due to unstable connection. If mobile apps are
native, almost all apps store username/password or some credential
that automatically reconnect to service. Therefore, I suppose it
wouldn't become issue. I might be too optimistic, though.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #69367 — Sanford Whiteman — 2013-09-27T00:45:26+00:00

URL: https://externals.io/message/69303#69367 · In reply to: #69366

> When URL based session is used, this feature should be
> disabled as pages are cached by browsers.

OK, I suppose, but that seems to be an edgier case than what we're
already discussing.

> BTW, if connection is unstable and an app force user to logout,
> is it going to be a problem? It would depend on message displayed, but
> I guess users think it is due to unstable connection. 

I definitely (!!!) would not think that if an app forced me to log in
again that it had to do with my connection quality unless I had
already decided the connection was practically unusable -- and that
all bets were off as to whether anything would work as expected.

Even if I intuited the reason and/or was told about it, I would not
accept being logged out of an app because I went into an elevator (to
use Tjerk's point) or through a train tunnel as appropriate. At all.
You're basically adding insult to injury: not only do you have a bad
connection, but you need to always log in. Makes for a very, very bad
user experience. I would hate an app that did that to me... if I
encountered the situation.

And what I was interrogating is _how common_ such a situation would be
in each developer's real world, predicting it would be different based
on the ecosystem of a particular app + its users.

For example, my main app is too heavy for most people to use over 3G
connections, period, so they are unlikely to run into the problem with
us because they wouldn't be trying to use the site in the first place.

Other apps have a lightweight version that is otherwise usable over
slow/sporadic connections and thus its users are more likely to
encounter timeouts, which the app has previously been tolerating. This
why I referred to _the end-user_ (not _PHP users_) being able to turn
such a feature off. Only a site that is 100% sure that it only is
useable over WiFi/WAN/LAN should roll out such a feature without
giving users control, because otherwise you are _ensuring_ your site
won't work on 3G! Why would you do that if it used to work?

> If mobile apps are native, almost all apps store username/password
> or some credential that automatically reconnect to service.

Native apps can have different levels of resilience -- we MUST
consider sites that just happen to be accessed from mobile. And in
those cases there can't be any question that being logged out because
you didn't receive the updated id is not acceptable. The question is
only _how often_ you are pissing off users, not _whether_ you will
piss off a user when you do this.

I also want to know how you deal with the other insult-to-injury that
I mentioned, where logging out someone after a _real_ session hijack
then reveals their credentials to the attacker who's still listening
on the same network. I'm starting to think there are unintended
consequences here that are approaching "considered harmful" levels.

-- S.

---

## #69371 — Yasuo Ohgaki — 2013-09-27T01:37:53+00:00

URL: https://externals.io/message/69303#69371 · In reply to: #69367

Hi Standord,

On Fri, Sep 27, 2013 at 9:45 AM, Sanford Whiteman <
swhitemanlistens-software@cypressintegrated.com> wrote:

> > […]
>
> OK, I suppose, but that seems to be an edgier case than what we're
> already discussing.
>
> > […]
>
> I definitely (!!!) would not think that if an app forced me to log in
> again that it had to do with my connection quality unless I had
> already decided the connection was practically unusable -- and that
> all bets were off as to whether anything would work as expected.
>
> Even if I intuited the reason and/or was told about it, I would not
> accept being logged out of an app because I went into an elevator (to
> use Tjerk's point) or through a train tunnel as appropriate. At all.
> You're basically adding insult to injury: not only do you have a bad
> connection, but you need to always log in. Makes for a very, very bad
> user experience. I would hate an app that did that to me... if I
> encountered the situation.
>
> And what I was interrogating is _how common_ such a situation would be
> in each developer's real world, predicting it would be different based
> on the ecosystem of a particular app + its users.
>
> For example, my main app is too heavy for most people to use over 3G
> connections, period, so they are unlikely to run into the problem with
> us because they wouldn't be trying to use the site in the first place.
>
> Other apps have a lightweight version that is otherwise usable over
> slow/sporadic connections and thus its users are more likely to
> encounter timeouts, which the app has previously been tolerating. This
> why I referred to _the end-user_ (not _PHP users_) being able to turn
> such a feature off. Only a site that is 100% sure that it only is
> useable over WiFi/WAN/LAN should roll out such a feature without
> giving users control, because otherwise you are _ensuring_ your site
> won't work on 3G! Why would you do that if it used to work?
>
> > […]
>
> Native apps can have different levels of resilience -- we MUST
> consider sites that just happen to be accessed from mobile. And in
> those cases there can't be any question that being logged out because
> you didn't receive the updated id is not acceptable. The question is
> only _how often_ you are pissing off users, not _whether_ you will
> piss off a user when you do this.
>
> I also want to know how you deal with the other insult-to-injury that
> I mentioned, where logging out someone after a _real_ session hijack
> then reveals their credentials to the attacker who's still listening
> on the same network. I'm starting to think there are unintended
> consequences here that are approaching "considered harmful" levels.


I also don't want to disturb end-users too much.

The reason why I think unstable connection would not be much
problem is lost session ID occurs only when end-users are connected
to site _and_ the connection is immediately lost before setting new session
ID.

Under normal circumstances, entering elevator or tunnel would not loose
session ID most likely since lost connection would not loose session ID.
When end-users simply lost their connection, IP address wouldn't change.
Therefore, session ID wouldn't change.

Establishing connection and immediately loosing it might cause lost session
ID.
To loose session ID, end-users have to send request to server and loose
connection _before_ they receive new session ID. I'm supposing this
happens most unlikely. I might be too optimistic, though.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #69372 — Sanford Whiteman — 2013-09-27T01:48:49+00:00

URL: https://externals.io/message/69303#69372 · In reply to: #69371

> Under normal circumstances, entering elevator or tunnel would not loose 
> session ID most likely since lost connection would not loose session ID. 
> When end-users simply lost their connection, IP address wouldn't change.

There's good reason to believe that the "event" of being assigned a
new IP from a forward proxy farm will be triggered by the "event" of
dropping and reconnecting to the mobile network repeatedly.

So, in general, if ever there were a time to be sensitive to
preserving sessions, it's when someone has a sporadic connection.

I might be too pessimistic...

---

## #69386 — Leigh — 2013-09-27T10:12:27+00:00

URL: https://externals.io/message/69303#69386 · In reply to: #69348

>
> 
> > […]
>
>
> Let's be clear here: this won't happen (in most cases), because the client
> will simply get a new cookie and the session will keep working; it's like
> what you would implement if your user level goes from anonymous to logged in
> and vice versa.

Right, so maybe I misunderstood the intent of this.

I was reading it as: valid SID on new IP = drop session, which to me
seems like the more "secure" approach.

What you're saying is is when a valid SID is supplied on a new IP, you
regenerate the SID and the session continues to be valid on the new
IP?

So on a successful session hijack (correct SID, new IP) the attacker
gets a new SID and keeps the valid session while the legitimate user
gets kicked out.

Not seeing how that improves things at all.

---

## #69387 — Andreas Heigl — 2013-09-27T10:19:09+00:00

URL: https://externals.io/message/69303#69387 · In reply to: #69386

Am 27.09.13 12:12, schrieb Leigh:
> 
> > […]
> 
> Right, so maybe I misunderstood the intent of this.
> 
> I was reading it as: valid SID on new IP = drop session, which to me
> seems like the more "secure" approach.
> 
> What you're saying is is when a valid SID is supplied on a new IP, you
> regenerate the SID and the session continues to be valid on the new
> IP?
> 
> So on a successful session hijack (correct SID, new IP) the attacker
> gets a new SID and keeps the valid session while the legitimate user
> gets kicked out.
> 
> Not seeing how that improves things at all.

So what about an ISP that changes the IP-Adress of it's clients every
half hour? Suddenly the IP for a valid SID has changed and the
legitimate user gets kicked out. Every half hour. No Attacker needed.

Does that improve things?

Regards

Andreas


-- 
                                                              ,,,
                                                             (o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org                       http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca                                               |
+---------------------------------------------------------------------+

---

## #69389 — Peter Lind — 2013-09-27T10:39:01+00:00

URL: https://externals.io/message/69303#69389 · In reply to: #69386

> On 26 September 2013 11:32, Tjerk Meesters <tjerk.meesters@gmail.com>
> wrote:
> > […]
> to
> > […]
> client
> > […]
> logged in
> > […]
>
> Right, so maybe I misunderstood the intent of this.
>
> I was reading it as: valid SID on new IP = drop session, which to me
> seems like the more "secure" approach.
>
> What you're saying is is when a valid SID is supplied on a new IP, you
> regenerate the SID and the session continues to be valid on the new
> IP?
>
> So on a successful session hijack (correct SID, new IP) the attacker
> gets a new SID and keeps the valid session while the legitimate user
> gets kicked out.
>
> Not seeing how that improves things at all.
>
> --
> 
> 
>
>
In your scenario, user gets booted and thus knows somethings wrong. Much
better than the attacker hijacking the session without the user knowing
anything at all.

Regards
Peter

-- 
<hype>
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
</hype

---

## #69390 — Leigh — 2013-09-27T10:54:31+00:00

URL: https://externals.io/message/69303#69390 · In reply to: #69389

> 
> > […]
>
> In your scenario, user gets booted and thus knows somethings wrong. Much
> better than the attacker hijacking the session without the user knowing
> anything at all.
>
> Regards
> Peter

And what is done to invalidate the session now gained by the attacker?
Since this is a proposal to handle such things internally.

Do you really think random user X will think something is wrong beyond
the site they were using just kicking them out for no reason? So now
what do they do now? Log in again? The attacker still has the
previously valid session, so nothing is gained.

This is exactly why this kind of logic belongs as user code. We're
starting to define rules for a system that should be agnostic to how
it is being used.

---

## #69391 — Peter Lind — 2013-09-27T11:00:24+00:00

URL: https://externals.io/message/69303#69391 · In reply to: #69390

> 
> > […]
>
> And what is done to invalidate the session now gained by the attacker?
> Since this is a proposal to handle such things internally.
>
>
And what is done when the user thinks everything is fine and dandy? My
point was that the scenario you created did not pose a problem - if
anything it would be a benefit (as you actually *can* detect some problems
now).

Do you really think random user X will think something is wrong beyond
> the site they were using just kicking them out for no reason? So now
> what do they do now? Log in again? The attacker still has the
> previously valid session, so nothing is gained.
>
>
That's for the userland code to decide.


> This is exactly why this kind of logic belongs as user code. We're
> starting to define rules for a system that should be agnostic to how
> it is being used.
>

I would agree. I was just pointing out that your example was not in fact
much of an argument against the proposal.

Regards
Peter

-- 
<hype>
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
</hype

---

Next page: https://externals.io/message/69303.md?page=2