ABSTRACT

Empty passwords may compromise system security in a way that cannot be easily remedied.

EXPLANATION

It is never a good idea to have an empty password. It also makes fixing the problem extremely difficult once the code is in production. The password cannot be changed without patching the software. If the account protected by the empty password is compromised, the owners of the system will be forced to choose between security and availability.


Example: The following code has an empty password to connect to an application and retrieve addressbook entries:


...
obj = new XMLHttpRequest();
obj.open('GET','/fetchusers.jsp?id='+form.id.value,'true','scott','');
...


This code will run successfully, but anyone can access when they know the username.

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) APP3210.1 CAT II, APP3340 CAT I, APP3350 CAT I

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

[6] Standards Mapping - FIPS200 - (FISMA) IA

[7] Standards Mapping - SANS Top 25 2009 - (SANS 2009) Porous Defenses - CWE ID 259

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

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

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