ABSTRACT

Null passwords can compromise security.

EXPLANATION

Assigning null to password variables is a bad idea because it can allow attackers to bypass password verification or might indicate that resources are protected by an empty password.



Example: The code below initializes a password variable to null and uses it to connect to a database.


...
Dim storedPassword As String
Set storedPassword = vbNullString

Dim con As New ADODB.Connection
Dim cmd As New ADODB.Command
Dim rst As New ADODB.Recordset

con.ConnectionString = "Driver={Microsoft ODBC for Oracle};Server=OracleServer.world;Uid=scott;Pwd=" & storedPassword &";"
...


If the code above succeeds, it indicates that the database user account "scott" is configured with an empty password, which can be easily guessed by an attacker. Even worse, once the program has shipped, updating the account to use a non-empty password will require a code change.

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