Apache Commons Lang’s RandomStringUtils Update on Performance and Security

1. The Problem

Recently, during an upgrade from Apache Commons Lang 3.14.0 to newer versions (3.15.0, 3.16.0, 3.17.0), our application began experiencing intermittent freezing in certain operations on our development/test servers. After analyzing the stack traces and reviewing changes in our dependencies, we traced the issue back to the Apache Commons Lang library. Reverting to 3.14.0 temporarily resolved these errors, confirming the new release was the culprit.

Further investigation of the Commons Lang Changelog revealed a significant change that affected performance:

Reimplement RandomUtils and RandomStringUtils on top of SecureRandom#getInstanceStrong() #1235 Thanks to Gary Gregory, Henri Yandell, Fabrice Benhamouda.

This update introduced more robust randomness by leveraging SecureRandom#getInstanceStrong() internally. While this change enhances security, it can lead to performance degradation and even system hangs in specific environments.

2. /dev/random vs. /dev/urandom

On Linux systems, random number generation typically relies on two sources for entropy (randomness seeds): /dev/random and /dev/urandom.

• /dev/random: Blocks (waits) if there is not enough available entropy to generate truly random data. This ensures stronger randomness but can cause latency or system hangs in low-entropy environments.

• /dev/urandom: Never blocks, as it reuses the internal pool for pseudorandom data. It is generally faster but considered (slightly) less secure, though for most applications it is sufficiently secure.

When SecureRandom#getInstanceStrong() is used, it often relies on /dev/random for entropy on Linux. On servers with limited entropy (such as virtualized or containerized environments with minimal user interaction), this can result in slowdowns or complete blocking when generating random data. Common solutions include:

• Using hardware random number generators (if available).
• Increasing system entropy with tools like haveged.
• Switching to a non-blocking approach, if security requirements permit it.

3. A Project to Test Performance Across Versions To better understand the performance impact, I created a small GitHub project to measure token generation times across Apache Commons Lang versions 3.14.0, 3.15.0, 3.16.0, and 3.17.0. Below are the summarized results from running the same token generation logic:

As demonstrated by the test results, upgrading from Apache Commons Lang 3.14.0 to 3.15.0+ introduced an approximate 6x slowdown on my test environment (though performance may vary by hardware and available entropy). While the newer versions enhance security by leveraging stronger randomness, they can noticeably degrade performance—especially on systems that struggle to generate sufficient entropy.

4. Conclusion

This experience underscores the importance of always reviewing a library’s changelog before upgrading—even for libraries as common and trusted as Apache Commons Lang. Security enhancements can introduce unforeseen performance implications, and being aware of these changes can save considerable troubleshooting time.

If your application relies on frequent or large-scale random token generation, weigh the trade-offs between higher security and performance. In some scenarios, configuring your server to generate more entropy (e.g., via haveged or hardware-based random number generators) may be sufficient. In others, using a non-blocking approach (like SecureRandom backed by /dev/urandom) may be acceptable if the highest level of randomness is not strictly required.

Key Takeaways:

• Review Changelogs: Minor version updates can contain major internal changes.
• Test in Your Environment: Always benchmark new versions under realistic conditions.
• Balance Security & Performance: Understand your entropy sources and use them responsibly.

Feel free to check out the test project on GitHub for more details on the performance comparison and share your thoughts or experiences below!

https://github.com/filipeferraz-code-lab/random-token-generator

https://commons.apache.org/proper/commons-lang/changes-report.html#a3.15.0