#2685 (ok 2.11.7) overriding session.hash_bits_per_character
Hi,
At Debian we've gotten a bug report which I'm quoting below. Basically, the user has hashing of his sessions dir, but this is appearently broken by the
following bit of code that phpMyAdmin employs in session.php:
// use more secure session ids (with PHP 5)
if (version_compare(PHP_VERSION, '5.0.0', 'ge')
&& substr(PHP_OS, 0, 3) != 'WIN') {
ini_set('session.hash_function', 1);
ini_set('session.hash_bits_per_character', 6);
}
As I understand it, only the first option actually changes the security, as it increases the number of bits in the algorithm. Changing the hash_bits_per_character option only changes the style of the session hash names, not their security.
Yet, "hard" overriding this second option causes trouble for sysadmins that have enabled hashing of their session dir as in the quoted bug report. I see
no real reason to hardcode the bits_per_character option, as the only thing it does is make te ID's a bit shorter, but they're not human readable anyway...
Is there a reason why bits_per_character is hardcoded, or could it be removed?
thanks,
Thijs
=== begin quote ===
Enabling hashing session files to directories[1] with default php
configuration requires creating a directory hierarchy[2] for them.
Phpmyadmin enforces different session names[3] than configured by
sysadmin, but does use default directory and hashing depth. So if
sysadmin creates hierarchy for his session naming scheme, phpmyadmin
will fail creating (some) of the session files because no directories
[G-Zg-z] (and maybe more?) exist in the directory tree.
IMO phpmyadmin should honor session settings in the main php.ini or
allow this behaviour to be configured by debconf (along with its own
session directory).
[1] accomplished by setting session.save_path="2;/var/lib/php5" in
/etc/php5/apache2/php.ini
- session name: sess_a1765f9b22bc2e2c2b672f4ab34a3199
- is stored as /var/lib/php5/a/1/sess_a1765f9b22bc2e2c2b672f4ab34a3199
[2] with default php setting sessions are hashed to hex-digit
directories (session.hash_bits_per_character = 4)
[3] /usr/share/phpmyadmin/libraries/session.inc.php:66 [in 2.9.1.1 -TK]
=== end quote ===
Logged In: YES
user_id=210714
Originator: YES
Also, with our revision 7518, the more secure hash function had been disabled on Windows.
Logged In: YES
user_id=210714
Originator: YES
Fixed in subversion, thanks for reporting.
Logged In: YES
user_id=326580
Originator: NO
it was disabled/limited on windows, cause it used characters not valid in pathname on windows
Logged In: YES
user_id=326580
Originator: NO
it was disabled/limited on windows, cause it used characters not valid in pathname on windows
Logged In: YES
user_id=1383652
Originator: NO
If someone decides to use the "N-option" in his session.save-path he must be aware that any php script might use ini_set('session.hash_bits_per_character', 6) and therefore is responsible to create *all* neccessary folders IMHO, see http://sourceforge.net/tracker/?func=detail&atid=377408&aid=1955386&group_id=23067
Shorter session ids are desirable since they increase performance.
just my 2cent
Logged In: YES
user_id=210714
Originator: YES
Sebastian,
now that the session.hash_bits_per_character is no longer forced, I guess current code works also on Windows? (default value being 4, producing 0-9 and a-f)
Logged In: YES
user_id=326580
Originator: NO
@marc: yes
Logged In: YES
user_id=326580
Originator: NO
@marc: yes
Logged In: YES
user_id=285765
Originator: NO
@windkiel: what do you mean, improves performance? I can't think of a reason why there should be a significant difference.
Logged In: YES
user_id=1383652
Originator: NO
>I can't think of a reason why there should be a significant difference.
shorter cookies, shorter URLs reduce the transferred number of packets for example,
YMMV
so you agree on the main part of my post?
Logged In: YES
user_id=285765
Originator: NO
I do not see that those things would be anywhere near significant, considering TCP packet size, the total amount of processing needed anyway and the addition of special code to achieve this.
Otherwise I do not agree: software shouldn't be changing php.ini values unless it really has to, because, as this bug shows, it creates the situation that one part of the served scripts behaves differently than others. As an admin you shouldn't have to be grepping the source code of each and every installed php script to find out which of your settings it overrides and which possible consequences that may have.
If the admin thinks it's important to save on say the length of session names, then he can set that globally, where it will also have more impact aswell.
Logged In: YES
user_id=326580
Originator: NO
about admin changes in the php.ini: IMO it is not important what anybody thinks what others should do or not, the admin should know what he does, and if he changes something from default he should know and take care for all consequences
about changing ini values in apps: users does not blame the admins or herself for security or performance problems, they blame on us (phpMyAdmin), even if not phpMyAdmin developers feel responsible for lazy admins, and not all ini options should be the same for every app
and you will never know if not any app will use self crafted session ids even more wired
just for the records: i do not see this as a bug, but a feature request, the admin should take care of what he changes!
Logged In: YES
user_id=326580
Originator: NO
about admin changes in the php.ini: IMO it is not important what anybody thinks what others should do or not, the admin should know what he does, and if he changes something from default he should know and take care for all consequences
about changing ini values in apps: users does not blame the admins or herself for security or performance problems, they blame on us (phpMyAdmin), even if not phpMyAdmin developers feel responsible for lazy admins, and not all ini options should be the same for every app
and you will never know if not any app will use self crafted session ids even more wired
just for the records: i do not see this as a bug, but a feature request, the admin should take care of what he changes!
Logged In: YES
user_id=285765
Originator: NO
All right and well, but there aren't concrete indications that changing this setting has security or performance benefits as per this bug log.
If there's no good reason to introduce a potential problem, whether it's the admins responsibility or not, we should not make their lives harder just for the sake of it.
We could debate whether it's a feature request or bug, but since it's already fixed, that seems unnecessary.