ABSTRACT

A hardcoded salt can compromise system security in a way that cannot be easily remedied.

EXPLANATION

It is never a good idea to hardcode a salt. Not only does a hardcoded salt allow all of the project's developers to view the salt, it also makes fixing the problem extremely difficult. Once the code is in production, the salt cannot be easily changed. If attackers know the value of the salt, they can compute rainbow tables for the application and more easily reverse hashed values.


Example 1: The following code uses a hardcoded salt:


...
crypt(password, "ms");
...


This code will run successfully, but anyone who has access to it will have access to the salt. Once the program has shipped, there is no going back from the salt "ms". A devious employee with access to this information can use it to break into the system.

REFERENCES

[1] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A7 Insecure Cryptographic Storage

[2] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A8 Insecure Cryptographic Storage

[3] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A8 Insecure Storage

[4] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3150.1 CAT II

[5] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 326

[6] Standards Mapping - Web Application Security Consortium 24 + 2 - (WASC 24 + 2) Information Leakage

[7] Standards Mapping - FIPS200 - (FISMA) MP

[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.3, Requirement 6.5.8

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.3

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.8