I recently found the following configuration settings:

and I have some questions about them:

Use-strict-mode says the following:

session.use_strict_mode specifies whether the module will use strict session id mode. If this mode is enabled, the module does not accept uninitialized session ID. If uninitialized session ID is sent from browser, new session ID is sent to browser. Applications are protected from session fixation via session adoption with strict mode. Defaults to 0 (disabled).

My rudimentary understanding is that it creates always a session ID for you, but I already saw another config option with does the same. So I assume that my understanding is wrong. So why do we need it? (The closest I saw is that it prevents OWASP A9, but it does not give me a lot of information)


allows you to define how many bits are stored in each character when converting the binary hash data to something readable. The possible values are '4' (0-9, a-f), '5' (0-9, a-v), and '6' (0-9, a-z, A-Z, "-", ",").

From my understanding this does not contribute anything to security, only tells what chars can be used for your session. The bigger the number - more characters and thus smaller string. So why not to put 6 (instead of default 4)?


This one is clear, but from the big list of possible functions, which is the one (I assume that default md5 is not good) is preferable?

P.S. before asking the question, I read this answer.

  • Try not to ask multi-questions. Split this up over 3 questions and you might get better results.
    – schroeder
    Commented Apr 28, 2014 at 20:01

1 Answer 1



This indeed only affects how the raw session ID is encoded. You can generally set it to any value you want. However, a value of 6 will lead to “strangely looking” session cookies, because the comma has to be URL-encoded.


If the PHP environment uses weak session IDs without additional entropy (see session.entropy_file and session.entropy_length), then it can become feasible to recover the seed of the PHP pseudo-random number generator through the IDs and use that to predict future values (chapter 4.2). A slow hash algorithm like Whirlpool or SHA-512 makes this harder, because finding the original input of the hash takes longer. But of course the real solution to this problem is to not use weak session IDs in the first place.


This is supposed to make session fixation attacks harder by not allowing an attacker to make up their own session IDs. See the corresponding RFC for a more detailed description of the ideas behind it.

However, an attacker doesn't have to come up with their own IDs to perform a session fixation attack. They can simply obtain a valid ID from the application and use that. So this feature is rather questionable.

  • If the attacker can do a session fixation attack using a session ID from your application, then it means you application forgot to regenerate a new session ID (and destroy the old one) when doing a right upgrade. So this use_strict_mode option is actually very useful
    – Xenos
    Commented Oct 5, 2018 at 16:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .