[Community Poll] Recommended length for secrets #7323
-
|
I have a bit of a general question. I know most of the secrets say they should be at least 64 characters long, while some say it should be at least 20 characters long. While those are the minimum size, are they the recommended size? Should I for instance make the JWT_SECRET or the SESSION_SECRET 100, or 500, or 100 characters long? I am guessing the longer those values are the more secure it technically is but also would take longer to encrypt/decrypt? Is there a sweetspot? I would love some community feedback as well as feedback from the maintainer. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
Please note this response was created using generative AI leveraging previously available information from the repository. This information may be helpful however it is our strong recommendation that you carefully consider the information before blindly applying it. The recommended length for secrets such as JWT_SECRET or SESSION_SECRET typically depends on the specific security requirements and the balance between security and performance. While longer secrets do indeed provide a higher level of security due to increased complexity, they can also impact performance due to longer processing times for encryption and decryption. From the sources provided, there isn't a specific recommendation for an optimal length beyond the minimum requirements mentioned (64 characters for some secrets). However, it's generally advisable to use secrets that are sufficiently long to ensure security without unnecessarily impacting performance. A common practice is to use secrets that are between 64 to 128 characters long. This range is often considered a good balance, providing strong security while maintaining reasonable performance. It's also important to ensure that the secrets are composed of a random combination of letters, numbers, and symbols to maximize their effectiveness against brute force attacks. If performance becomes a concern with longer secrets, you might consider profiling the application to understand the actual impact and adjust accordingly. However, without specific performance issues, sticking to the 64-128 character range is typically adequate. For more detailed guidance tailored to your specific use case, consulting the documentation or seeking advice from security professionals might be beneficial. This comment was generated by Glime. |
Beta Was this translation helpful? Give feedback.
-
|
As we use AES256-GCM for most of our encryption the maximum entropy is 256bits. After 64 characters you start to see diminishing returns, and at about 128 characters you'll see rapidly diminishing returns. Theoretically there would be no benefit beyond about 512 characters or would be so immeasurable that it doesn't matter. For HMAC signatures it is basically the same. The length of the secret has no effect on encryption time however as the AES258-GCM algorithm is fixed-size. Thus we digest any user input through the SHA256 hashing algorithm to get the correct key length of effectively random bytes (provided the input was also effectively random). |
Beta Was this translation helpful? Give feedback.
As we use AES256-GCM for most of our encryption the maximum entropy is 256bits. After 64 characters you start to see diminishing returns, and at about 128 characters you'll see rapidly diminishing returns. Theoretically there would be no benefit beyond about 512 characters or would be so immeasurable that it doesn't matter.
For HMAC signatures it is basically the same.
The length of the secret has no effect on encryption time however as the AES258-GCM algorithm is fixed-size. Thus we digest any user input through the SHA256 hashing algorithm to get the correct key length of effectively random bytes (provided the input was also effectively random).