Hi,
>> I've just written session_create_id(string $prefix) today.
>> You can do that easily and securely with session_create_id().
>> It would be in 5.6.
>>
>> You may check easily with user script whatever prefix means.
>>
>> NOTE: No one should not expose sensitive data in prefix!
>>
>
> If anyone would like to prefix by IP address, store it like
>
> session_create_id(sha1($secret.$IP_ADDR).'-');
I want to prefix the session _file_, because that's just the
easiest/fastest way to do such a check and make it work flawlessly
with 'session.use_strict_mode'. Prefixing the session ID doesn't
prevent hijacking it, because that's client-side input via the cookie.
> Since nowadays the vast majority of 'users' do not have fixed IP addresses, and
> the methods used to share IP's on mobile phones is making that even more of a
> problem. It has already been pointed out that this can't be a default.
Again, I've never said or even thought that it should be a default.
Although, IPv6 is late enough already and the world can't ignore it
forever, so that situation would change at some point in the future.
Also, "not fixed" doesn't necessarily mean changing addresses on every
few minutes and not all web apps have or want to have a "permanent
login" feature. And ultimately - it's the developer's choice.
> Personally I keep track of the visitor IP's in a database and so have my own
> handling and I'm fairly sure most frameworks also do that. So I do not believe
> it leaves many options that could be considered safe to use as an alternative?
>
> So to
>> So much needed in fact, that I'm surprised PHP made it to 2014 without that
>> option, especially since there already is 'session.referer_check'.
> the answer is - because no one can come up with something that is safe to use?
I don't think I undestand what you mean ... is what I'm proposing
somehow unsafe? If so, how?
> I'm sure there's a reason why you want that, but I'm not sure I'm seeing
> a generic use case for this for core. Why would most of the core users
> care how the session files are named and require them named in a
> specific way?
I'm saying many, not most.
But while both of these are opinions, I'm quite sure that if we do a
survey, asking the general public - most would say that they want it.
Also, if you hire a security expert to audit your code and
'session.match_ip' is available - put your money on a recommendation
to turn that on.
And true, few people would care about the file name in particular. It
just so happens that performance-wise, that's the best solution.
> Don't bash me when I'm wrong, but why would you want the IP check for
> the session in the first place? Don't get me wrong, I'm definitely in
> favour of more security, but the issue I see, is the following:
> When a user has an ISP that regularrily changes the IP-address assigned
> to the user via DHCP the session then is lost, isn't it? So suddenly the
> user is logged of without any apparent reason whatsoever.
When, but not necessarily.
You could read up a few paragraphs above where I mention IPv6, but you
could also look at some traffic on IRC (just because all addresses are
visible there, unless spoofed) to see that IPs are not in fact that
much regularly changed in general. For an application that doesn't
need a "permanent login" feature, that's not a problem.
> And if that's not a problem, please take into account the users real
> address and not the address of any proxy that is in between (at least
> when it's possible to determin it). And that involves a lot of header
> checks, whether one or the other is set. And as soon as the appropriate
> header is not set (which might be the case due to proxy misbehaviour or
> misconfiguration), you will "only" have the IP of the Proxy. So all
> users behind such a proxy will share the same IP-address. The same goes
> for users behind NAT in a private network.
These headers can be sent by anybody, effectively spoofing the IP
address and therefore must not be taken into account. I'd say that
this is a rare exception and I can live with people behind a proxy or
NAT sharing the same address - we're kind of forced to. :)
---------------------------------------------------
I'm getting the impression that most (if not all) of you are trying
hard to find a reason not to have this feature, with no such reason
existing. It wouldn't be bloat, nor would it break anything.
Ultimately, it's an option, a tool that if you don't need, then you
just don't turn it on. Give us that tool. ;)