Rule Definition
The software should not have hardcoded credentials (username, password) in the application code or files. Hard-coded credentials typically create a significant security hole that allows an attacker to bypass the authentication that has been configured by the software administrator. This hole might be difficult for the system administrator to detect. Even if detected, it can be difficult to fix, so the administrator may be forced into disabling the product entirely.

Remediation
Potential remediations : - Outbound authentication : consider storing passwords and keys outside of the code, in the most strongly-protected, encrypted storage. This storage should be protected from outsiders, even other local users from the same system. - Inbound authentication : consider using login authentication with strong passwords or keys instead of hardcoding usernames and passwords. - If hardcoded credentials cannot be removed, perform access control checks and limit accessed resources.

Violation Code Sample

Java example : 
... 
DriverManager.getConnection(url, "jeff", "1234"); 
... 

C# example : 
... 
var request = WebRequest.CreateHttp(url); 
request.Credentials = new NetworkCredential("jeff", "1234"); 
var reader = new StreamReader(request.GetResponse().GetResponseStream()); 
... 

These are examples of external hard-coded credentials on the client-side of a connection. This code will run successfully, but anyone who has access to it will have access to the password. Accessing this information is possible for employees who have the source code or external attackers using disassembly tools. Malicious users with access to this information could use it to break into the system.

Fixed Code Sample

// Store passwords outside of the code in a storage protected from outsiders

CWE-798 : Use of Hard-coded Credentials http://cwe.mitre.org/data/definitions/798.html