[Hardening] Deprecate RandomSessionIdGenerator due to insufficient entropy (64-bit)

[Allen-wick]

Search before asking

• I had searched in the issues and found no similar issues.

Enhancement Request

The org.apache.shiro.session.mgt.eis.RandomSessionIdGenerator class generates session IDs using Long.toString(SecureRandom.nextLong()), which provides only 64 bits of entropy. This falls below the modern industry minimum of 128 bits recommended by OWASP ASVS and NIST SP 800-63B for session tokens.

While Shiro's default JavaUuidSessionIdGenerator (UUID v4, 122-bit entropy) is secure and used out-of-the-box, the existence of RandomSessionIdGenerator in the public API poses a risk of misuse by developers who might explicitly configure it for legacy or perceived performance reasons.

Describe the solution you'd like

To improve the security posture and guide developers toward secure defaults, I propose the following hardening steps:

1. Mark RandomSessionIdGenerator as @Deprecated in the next minor release, with a Javadoc comment directing users to JavaUuidSessionIdGenerator.
2. Add a startup WARN log if this class is explicitly instantiated or wired via shiro.ini / Spring configuration.
3. Remove the class entirely in the next major release (e.g., Shiro 3.x).

Are you willing to submit PR?

• Yes I am willing to submit a PR!

[lprimak]

Do you think that this class is useful at all? Is it worth fixing it, and not deprecating it for removal?

[Allen-wick]

Thanks for looking into this so quickly and for opening the deprecation PR.
To answer your questions:

1. Is it useful at all?
   I don't believe it has any valid use case in modern security architectures. With OWASP ASVS and NIST SP 800-63B mandating at least 128 bits of entropy for session tokens, a 64-bit long falls fundamentally short. Shiro already provides JavaUuidSessionIdGenerator (which uses UUID v4 with 122-bit entropy) as the secure, standard default.
2. Is it worth fixing?
   No, I don't think it's worth fixing. Attempting to "fix" it to meet the 128-bit threshold (e.g., by concatenating multiple nextLong() calls or generating a numeric string) would alter its fundamental format and data type expectations. This could silently break backward compatibility for legacy applications that explicitly rely on it returning a standard 64-bit numeric string representation.
   Therefore, I completely agree with your approach: deprecating it for removal is the cleanest and most secure path forward. It eliminates the risk of future misuse and correctly guides developers toward the secure UUID default.
   Thanks for taking action on this!