Hi all,
I would like to refactor session id generation to use our new
php_random_bytes API as the single entropy source for session ids,
targeting 7.1
Overall this would give a small performance increase to session generation,
a large security increase to session generation, and remove some points of
possible user error.
There are a few things to consider while doing this:
session.entropy_file will no longer needed, as the best source of random
for the operating system will be selected.
session.entropy_length should be ignored, as this was to specify the length
of additional entropy, and may be non-zero in legacy configuration files,
that are preserved across upgrades
session.hash_function should be deprecated, there is no benefit to hashing
cryptographically strong random bytes, however people may be relying on
this to get session ids of a certain length.
We will have to introduce a new setting to control session id length,
perhaps overridden if session.hash_function is non-default. We have a year
to play with the details.
I'd like to hear if there are any strong objections to this proposal.
Cheers,
Leigh.
Hi all,
I would like to refactor session id generation to use our new
php_random_bytes API as the single entropy source for session ids,
targeting 7.1Overall this would give a small performance increase to session generation,
a large security increase to session generation, and remove some points of
possible user error.There are a few things to consider while doing this:
session.entropy_file will no longer needed, as the best source of random
for the operating system will be selected.session.entropy_length should be ignored, as this was to specify the length
of additional entropy, and may be non-zero in legacy configuration files,
that are preserved across upgradessession.hash_function should be deprecated, there is no benefit to hashing
cryptographically strong random bytes, however people may be relying on
this to get session ids of a certain length.We will have to introduce a new setting to control session id length,
perhaps overridden if session.hash_function is non-default. We have a year
to play with the details.I'd like to hear if there are any strong objections to this proposal.
I don't have one.
But if I may ask, I'm curious, as always: What happens in the case that
php_random_bytes() fails?
Tom
I don't have one.
But if I may ask, I'm curious, as always: What happens in the case that
php_random_bytes() fails?Tom
That's a good point.
session_start() would throw the exception generated by php_random_bytes()
letting you know your system is incapable of generating high quality random
numbers. However this is a serious issue in it's own right, the APIs used
(and the way they are used) really only fail if the underlying environment
is fubar.
I don't have one.
But if I may ask, I'm curious, as always: What happens in the case that
php_random_bytes() fails?Tom
That's a good point.
session_start() would throw the exception generated by php_random_bytes()
letting you know your system is incapable of generating high quality
random numbers.
I think that's entirely satisfactory.
However this is a serious issue in it's own right, the APIs used (and the
way they are used) really only fail if the underlying environment is
fubar.
Agreed.
Tom
I don't have one.
But if I may ask, I'm curious, as always: What happens in the case that
php_random_bytes() fails?Tom
That's a good point.
session_start() would throw the exception generated by php_random_bytes()
letting you know your system is incapable of generating high quality
random numbers.I think that's entirely satisfactory.
However this is a serious issue in it's own right, the APIs used (and the
way they are used) really only fail if the underlying environment is
fubar.Agreed.
Tom
--
I'm very much +1 on this and willing to help if you need some extra hands.
:)
I would like to refactor session id generation to use our new
php_random_bytes API as the single entropy source for session ids,
targeting 7.1
...
I'd like to hear if there are any strong objections to this proposal.
Hi Leigh,
Again, not an objection but a question about performance, in particular,
performance relative to existing 7.0 generation of php_random_bytes'
different routes to randomness.
I suspect without any real evidence that php_random_bytes' different
routes have big performance differences and if any of them are slow
enough to affect sessions, it's worth knowing about.
Do current tests rigs allow such measurements?
Tom