Password management issues occur when a password is stored in plain text in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base64 encoding, but this does not adequately protect the password.
Example: The following code reads a password from a properties file and uses the password to set default authentication credentials for URL requests.

...
var fs:FileStream = new FileStream();
fs.open(new File("config.properties"), FileMode.READ);
var decoder:Base64Decoder = new Base64Decoder();
decoder.decode(fs.readMultiByte(fs.bytesAvailable, File.systemCharset));
var password:String = decoder.toByteArray().toString();

URLRequestDefaults.setLoginCredentialsForHost(hostname, usr, password);
...

This code will run successfully, but anyone with access to config.properties can read the value of password and easily determine that the value has been base64 encoded. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's configuration files or other data store. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base64 encoding, but this does not adequately protect the password.
Example: The following code reads a password from the registry and uses the password to create a new network credential.

...
string value = regKey.GetValue(passKey).ToString());
byte[] decVal = Convert.FromBase64String(value);
NetworkCredential netCred =
  new NetworkCredential(username,decVal.toString(),domain);
...

This code will run successfully, but anyone who has access to the registry key used to store the password can read the value of password. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's configuration files or other data store. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base64 encoding, but this does not adequately protect the password.
Example: The following code reads a password from the registry, decodes it using a trivial encoding algorithm and uses the password to connect to a database.

...
RegQueryValueEx(hkey, TEXT(.SQLPWD.), NULL,
                NULL, (LPBYTE)password64, &size64);
Base64Decode(password64, size64, (BYTE*)password, &size);
rc = SQLConnect(*hdbc, server, SQL_NTS, uid,
                SQL_NTS, password, SQL_NTS);
...

This code will run successfully, but anyone who has access to the registry key used to store the password can read the value of password64 and easily determine that the value has been base64 encoded. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base64 encoding, but this does not adequately protect the password.
Example: The following code reads a password from a properties file and uses the password to connect to a database.

...
01  RECORDX.
     05  UID              PIC X(10).
     05  PASSWORD         PIC X(10).
     05  LEN              PIC S9(4) COMP.
...
EXEC CICS
  READ
  FILE('CFG')
  INTO(RECORDX)
  RIDFLD(ACCTNO)
  ...
END-EXEC.

CALL "g_base64_decode_inplace" using
   BY REFERENCE PASSWORD
   BY REFERENCE LEN
   ON EXCEPTION
       DISPLAY "Requires GLib library" END-DISPLAY
END-CALL.

EXEC SQL
  CONNECT :UID
  IDENTIFIED BY :PASSWORD
END-EXEC.
...

This code will run successfully, but anyone with access to CFG can read the value of password and easily determine that the value has been base64 encoded. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base64 encoding, but this does not adequately protect the password.
Example: The following code reads a password from a JSON file and uses the password to set the request's authorization header.

...
file, _ := os.Open("config.json")
decoder := json.NewDecoder(file)
decoder.Decode(&values)
password := base64.StdEncoding.DecodeString(values.Password)

request.SetBasicAuth(values.Username, password)
...

This code will run successfully, but anyone with access to config.json can read the value of password and easily determine that the value has been base64 encoded. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base64 encoding, but this does not adequately protect the password.
Example: The following code uses a hardcoded password to connect to an application and retrieve address book entries:

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

This code will run successfully, but anyone who accesses the containing web page can view the password.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base64 encoding, but this does not adequately protect the password.
Example: The following code reads a password from a plist file and uses it to unzip a password-protected file.

...
NSDictionary *dict= [NSDictionary dictionaryWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"Config" ofType:@"plist"]];
NSString *encoded_password = [dict valueForKey:@"encoded_password"];
NSData *decodedData = [[NSData alloc] initWithBase64EncodedString:encoded_password options:0];
NSString *decodedString = [[NSString alloc] initWithData:decodedData encoding:NSUTF8StringEncoding];
[SSZipArchive unzipFileAtPath:zipPath toDestination:destPath overwrite:TRUE password:decodedString error:&error];
...

This code will run successfully, but anyone with access to the Config.plist file can read the value of encoded_password and easily determine that the value has been base64 encoded.

In the mobile environment, password management is especially important given that there is such a high chance of device loss.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base64 encoding, but this does not adequately protect the password.
Example: The following code reads a password from a properties file and uses the password to connect to a database.

...
$props = file('config.properties', FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);
$password = base64_decode($props[0]);

$link = mysql_connect($url, $usr, $password);
if (!$link) {
    die('Could not connect: ' . mysql_error());
}
...

This code will run successfully, but anyone with access to config.properties can read the value of password and easily determine that the value has been base64 encoded. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base64 encoding, but this does not adequately protect the password.
Example: The following code reads a password from a properties file and uses the password to connect to a database.

...
props = os.open('config.properties')
password = base64.b64decode(props[0])

link = MySQLdb.connect (host = "localhost",
                           user = "testuser",
                           passwd = password,
                           db = "test")
...

This code will run successfully, but anyone with access to config.properties can read the value of password and easily determine that the value has been base64 encoded. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's configuration files or other data store. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base64 encoding, but this does not adequately protect the password.
Example: The following code reads a password from an environment variable, decodes it using a trivial encoding algorithm and uses the password to connect to a database.

require 'pg'
require 'base64'
...
passwd = Base64.decode64(ENV['PASSWD64'])
...
conn = PG::Connection.new(:dbname => "myApp_production", :user => username, :password => passwd, :sslmode => 'require')

This code will run successfully, but anyone who has access to the environment variable used to store the password can read the value of PASSWD64 and easily determine that the value has been base64 encoded. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base64 encoding, but this does not adequately protect the password.
Example 1: The following code reads a password from a properties file and uses the password to connect to a database.

...
val prop = new Properties();
prop.load(new FileInputStream("config.properties"));
val password = Base64.decode(prop.getProperty("password"));

DriverManager.getConnection(url, usr, password);
...

This code will run successfully, but anyone with access to config.properties can read the value of password and easily determine that the value has been base64 encoded. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base64 encoding, but this does not adequately protect the password.
Example 1: The following code reads a password from a plist file and uses it to unzip a password-protected file.

...
var myDict: NSDictionary?
if let path = NSBundle.mainBundle().pathForResource("Config", ofType: "plist") {
    myDict = NSDictionary(contentsOfFile: path)
}
if let dict = myDict {
    let password = base64decode(dict["encoded_password"])
    zipArchive.unzipOpenFile(zipPath, password:password])
}
...

This code will run successfully, but anyone with access to the Config.plist file can read the value of encoded_password and easily determine that the value has been base64 encoded.

In the mobile environment, password management is especially important given that there is such a high chance of device loss.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base64 encoding, but this does not adequately protect the password.

Example 1: The following Linux shadow file contains a password that is using the weak encryption algorithm DES.

...
root:qFio7llfVKk.s:19033:0:99999:7:::
...

The DES algorithm has proven weak, and can be brute-forced in a matter of days.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base64 encoding, but this does not adequately protect the password.
Example: The following code reads a password from a properties file and uses the password to connect to a database.

...
...
Private Declare Function GetPrivateProfileString _
  Lib "kernel32" Alias "GetPrivateProfileStringA" _
  (ByVal lpApplicationName As String, _
  ByVal lpKeyName As Any, ByVal lpDefault As String, _
  ByVal lpReturnedString As String, ByVal nSize As Long, _
  ByVal lpFileName As String) As Long
...
Dim password As String
...
password = StrConv(DecodeBase64(GetPrivateProfileString("MyApp", "Password", _
  "", value, Len(value), _
   App.Path & "\" & "Config.ini")), vbUnicode)
...
con.ConnectionString = "Driver={Microsoft ODBC for Oracle};Server=OracleServer.world;Uid=scott;Passwd=" & password &";"
...

This code will run successfully, but anyone with access to Config.ini can read the value of Password and easily determine that the value has been base64 encoded. Any devious employee with access to this information can use it to break into the system.

XML injection occurs when:

1. Data enters a program from an untrusted source.

2. The data is written to an XML document.

Applications typically use XML to store data or send messages. When used to store data, XML documents are often treated like databases and can potentially contain sensitive information. XML messages are often used in web services and can also be used to send sensitive information. XML messages can even be used to send authentication credentials.

The semantics of XML documents and messages can be altered if an attacker has the ability to write raw XML. In the most benign case, an attacker may be able to insert extraneous tags and cause an XML parser to throw an exception. In more nefarious cases of XML injection, an attacker may be able to add XML elements that change authentication credentials or modify prices in an XML e-commerce database. In some cases, XML injection can even lead to cross-site scripting or dynamic code evaluation.

Example 1:

Assume an attacker is able to control shoes in following XML.

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

Now suppose this XML is included in a back end web service request to place an order for a pair of shoes. Suppose the attacker modifies his request and replaces shoes with shoes</item><price>1.00</price><item>shoes. The new XML would look like:

<order>
   <price>100.00</price>
   <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

When using SAX parsers, the value from the second <price> overrides the value from the first <price> tag. This allows the attacker to purchase a pair of $100 shoes for $1.

XML injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to an XML document.

Applications typically use XML to store data or send messages. When used to store data, XML documents are often treated like databases and can potentially contain sensitive information. XML messages are often used in web services and can also be used to transmit sensitive information. XML messages can even be used to send authentication credentials.

The semantics of XML documents and messages can be altered if an attacker has the ability to write raw XML. In the most benign case, an attacker may be able to insert extraneous tags and cause an XML parser to throw an exception. In more nefarious cases of XML injection, an attacker may be able to add XML elements that change authentication credentials or modify prices in an XML e-commerce database. In some cases, XML injection can lead to cross-site scripting or dynamic code evaluation.

Example 1:

Assume an attacker is able to control shoes in following XML.

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

Now suppose this XML is included in a back end web service request to place an order for a pair of shoes. Suppose the attacker modifies his request and replaces shoes with shoes</item><price>1.00</price><item>shoes. The new XML would look like:

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

When using SAX parsers, the value from the second <price> overrides the value from the first <price> tag. This allows the attacker to purchase a pair of $100 shoes for $1.

XML injection occurs when:

1. Data enters a program from an untrusted source.

2. The data is written to an XML document.

Applications typically use XML to store data or send messages. When used to store data, XML documents are often treated like databases and can potentially contain sensitive information. XML messages are often used in web services and can also be used to transmit sensitive information. XML messages can even be used to send authentication credentials.

The semantics of XML documents and messages can be altered if an attacker has the ability to write raw XML. In the most benign case, an attacker can insert extraneous tags and cause an XML parser to throw an exception. In more nefarious cases of XML injection, an attacker can add XML elements that change authentication credentials or modify prices in an XML e-commerce database. Sometimes XML injection can lead to cross-site scripting or dynamic code evaluation.

Example 1:

Assume an attacker can control shoes in following XML:

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

Now suppose this XML is included in a back-end web service request to place an order for a pair of shoes. Suppose the attacker modifies his request and replaces shoes with shoes</item><price>1.00</price><item>shoes. The new XML would look like:

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

When using SAX parsers, the value from the second <price> overrides the value from the first <price> tag. This allows the attacker to purchase a pair of $100 shoes for $1.

XML injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to an XML document.

Applications typically use XML to store data or send messages. When used to store data, XML documents are often treated like databases and can potentially contain sensitive information. XML messages are often used in web services and can also be used to transmit sensitive information. XML messages can even be used to send authentication credentials.

The semantics of XML documents and messages can be altered if an attacker has the ability to write raw XML. In the most benign case, an attacker may be able to insert extraneous tags and cause an XML parser to throw an exception. In more nefarious cases of XML injection, an attacker may be able to add XML elements that change authentication credentials or modify prices in an XML e-commerce database. In some cases, XML injection can lead to cross-site scripting or dynamic code evaluation.

Example 1:

Assume an attacker can control shoes in the following XML.

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

Now suppose this XML is included in a back end web service request to place an order for a pair of shoes. Suppose the attacker modifies his request and replaces shoes with shoes</item><price>1.00</price><item>shoes. The new XML would look like:

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

This may allow an attacker to purchase a pair of $100 shoes for $1.

XML injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to an XML document.

Applications typically use XML to store data or send messages. When used to store data, XML documents are often treated like databases and can potentially contain sensitive information. XML messages are often used in web services and can also be used to transmit sensitive information. XML messages can even be used to send authentication credentials.

The semantics of XML documents and messages can be altered if an attacker has the ability to write raw XML. In the most benign case, an attacker may be able to insert extraneous tags and cause an XML parser to throw an exception. In more nefarious cases of XML injection, an attacker may be able to add XML elements that change authentication credentials or modify prices in an XML e-commerce database. In some cases, XML injection can lead to cross-site scripting or dynamic code evaluation.

Example 1:

Assume an attacker is able to control shoes in following XML.

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

Now suppose this XML is included in a back end web service request to place an order for a pair of shoes. Suppose the attacker modifies his request and replaces shoes with shoes</item><price>1.00</price><item>shoes. The new XML would look like:

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

When using SAX parsers, the value from the second <price> overrides the value from the first <price> tag. This allows the attacker to purchase a pair of $100 shoes for $1.

XML injection occurs when:

1. Data enters a program from an untrusted source.

2. The data is written to an XML document.

Applications typically use XML to store data or send messages. When used to store data, XML documents are often treated like databases and can potentially contain sensitive information. XML messages are often used in web services and can also be used to transmit sensitive information. XML messages can even be used to send authentication credentials.

The semantics of XML documents and messages can be altered if an attacker has the ability to write raw XML. In the most benign case, an attacker may be able to insert extraneous tags and cause an XML parser to throw an exception. In more nefarious cases of XML injection, an attacker may be able to add XML elements that change authentication credentials or modify prices in an XML e-commerce database. In some cases, XML injection can lead to cross-site scripting or dynamic code evaluation.

Example 1:

Assume an attacker is able to control shoes in following XML.

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

Now suppose this XML is included in a back end web service request to place an order for a pair of shoes. Suppose the attacker modifies his request and replaces shoes with shoes</item><price>1.00</price><item>shoes. The new XML would look like:

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

When using XML parsers, the value from the second <price> overrides the value from the first <price> tag. This allows the attacker to purchase a pair of $100 shoes for $1.


A more serious form of this attack called XML External Entity (XXE) injection can occur when the attacker controls the front or all of the parsed XML document.

Example 2: Here is some code that is vulnerable to XXE attacks:

Assume an attacker is able to control the input XML to the following code:

...
<?php
$goodXML = $_GET["key"];
$doc = simplexml_load_string($goodXml);
echo $doc->testing;
?>
...

Now suppose that the following XML is passed by the attacker to the code in Example 2:

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

When the XML is processed, the content of the <foo> element is populated with the contents of the system's boot.ini file. The attacker may utilize XML elements which are returned to the client to exfiltrate data or obtain information as to the existence of network resources.

XML injection occurs when:

1. Data enters a program from an untrusted source.

2. The data is written to an XML document.

Applications typically use XML to store data or send messages. When used to store data, XML documents are often treated like databases and can potentially contain sensitive information. XML messages are often used in web services and can also be used to transmit sensitive information. XML messages can even be used to send authentication credentials.

The semantics of XML documents and messages can be altered if an attacker has the ability to write raw XML. In the most benign case, an attacker may be able to insert extraneous tags and cause an XML parser to throw an exception. In more nefarious cases of XML injection, an attacker may be able to add XML elements that change authentication credentials or modify prices in an XML e-commerce database. In some cases, XML injection can lead to cross-site scripting or dynamic code evaluation.

Example 1:

Assume an attacker is able to control shoes in following XML.

<order>
    <price>100.00</price>
    <item>shoes</item>
</order>

Now suppose this XML is included in a back end web service request to place an order for a pair of shoes. Suppose the attacker modifies his request and replaces shoes with shoes</item><price>1.00</price><item>shoes. The new XML would look like:

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

When using SAX parsers, the value from the second <price> overrides the value from the first <price> tag. This allows the attacker to purchase a pair of $100 shoes for $1.

XML injection occurs when:

1. Data enters a program from an untrusted source.

2. The data is written to an XML document or parsed as XML.

Applications typically use XML to store data or send messages. When used to store data, XML documents are often treated like databases and can potentially contain sensitive information. XML messages are often used in web services and can also be used to transmit sensitive information. XML messages can even be used to send authentication credentials.

The semantics of XML documents and messages can be altered if an attacker has the ability to write raw XML. In the most benign case, an attacker may be able to insert extraneous tags and cause an XML parser to throw an exception. In more nefarious cases of XML injection, an attacker may be able to add XML elements that change authentication credentials or modify prices in an XML e-commerce database. In some cases, XML injection can lead to cross-site scripting or dynamic code evaluation.

Example 1:

Assume an attacker is able to control shoes in following XML.

<order>
    <price>100.00</price>
    <item>shoes</item>
</order>

Now suppose this XML is included in a back end web service request to place an order for a pair of shoes. Suppose the attacker modifies his request and replaces shoes with shoes</item><price>1.00</price><item>shoes. The new XML would look like:

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

When using SAX parsers, the value from the second <price> overrides the value from the first <price> tag. This allows the attacker to purchase a pair of $100 shoes for $1.

XML injection occurs when:

1. Data enters a program from an untrusted source.

2. The data is written to an XML document or parsed as XML.

Applications typically use XML to store data or send messages. When used to store data, XML documents are often treated like databases and can potentially contain sensitive information. XML messages are often used in web services and can also be used to transmit sensitive information. XML messages can even be used to send authentication credentials.

The semantics of XML documents and messages can be altered if an attacker has the ability to write raw XML. In the most benign case, an attacker may be able to insert extraneous tags and cause an XML parser to throw an exception. In more nefarious cases of XML injection, an attacker may be able to add XML elements that change authentication credentials or modify prices in an XML e-commerce database. In some cases, XML injection can lead to cross-site scripting or dynamic code evaluation.

Example 1:

Assume an attacker is able to control shoes in following XML.

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

Now suppose this XML is included in a back end web service request to place an order for a pair of shoes. Suppose the attacker modifies his request and replaces shoes with shoes</item><price>1.00</price><item>shoes. The new XML would look like:

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

When using SAX parsers, the value from the second <price> overrides the value from the first <price> tag. This allows the attacker to purchase a pair of $100 shoes for $1.

XML injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to an XML document.

Applications typically use XML to store data or send messages. When used to store data, XML documents are often treated like databases and can potentially contain sensitive information. XML messages are often used in web services and can also be used to transmit sensitive information. XML messages can even be used to send authentication credentials.

The semantics of XML documents and messages can be altered if an attacker has the ability to write raw XML. In the most benign case, an attacker may be able to insert extraneous tags and cause an XML parser to throw an exception. In more nefarious cases of XML injection, an attacker may be able to add XML elements that change authentication credentials or modify prices in an XML e-commerce database. In some cases, XML injection can lead to cross-site scripting or dynamic code evaluation.

Example 1:

Assume an attacker is able to control shoes in the following XML.

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

Now suppose this XML is included in a back end web service request to place an order for a pair of shoes. Suppose the attacker modifies his request and replaces shoes with shoes</item><price>1.00</price><item>shoes. The new XML would look like:

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

When using SAX parsers, the value from the second <price> overrides the value from the first <price> tag. This allows the attacker to purchase a pair of $100 shoes for $1.

Initialization vectors (IVs) should be created using a cryptographic pseudorandom number generator. Without using a random IV, the resulting ciphertext becomes much more predictable and susceptible to a dictionary attack.

Example 1: The following code performs AES encryption using a non-random IV:

...
Blob iv = Blob.valueOf('1234567890123456');
Blob encrypted = Crypto.encrypt('AES128', encKey, iv, input);
...

Initialization vectors (IVs) should be created using a cryptographic pseudorandom number generator. Not using a random IV makes the resulting ciphertext much more predictable and susceptible to a dictionary attack.

Example 1: The following code creates an non-random IV using hardcoded bytes.

byte[] iv = { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 };
using (SymmetricAlgorithm aesAlgo = SymmetricAlgorithm.Create("AES"))
{
    ...
    aesAlgo.IV = iv;
    ...
}

Initialization vectors (IVs) should be created using a cryptographic pseudorandom number generator. Not using a random IV makes the resulting ciphertext much more predictable and susceptible to a dictionary attack.

Example 1: The following code creates a non-random IV using a hardcoded string.

unsigned char * iv = "12345678";
EVP_EncryptInit_ex(&ctx, EVP_idea_gcm(), NULL, key, iv);

Use a cryptographic pseudorandom number generator to create initialization vectors (IVs). Otherwise, the resulting ciphertext is more predictable and susceptible to a dictionary attack.

Example 1: The following code reuses the key as the IV:

import (
    "crypto/aes"
    "crypto/cipher"
    "crypto/rand"
)
...
block, err := aes.NewCipher(key)
...
mode := cipher.NewCBCEncrypter(block, key)
mode.CryptBlocks(ciphertext[aes.BlockSize:], plaintext)

If you use the key as the IV, attackers can recover the key, which enables them to decrypt the data.

Initialization vectors (IVs) should be created using a cryptographic pseudorandom number generator. Not using a random IV makes the resulting ciphertext much more predictable and susceptible to a dictionary attack.

Example 1: The following code creates a non-random IV using hardcoded bytes.

...
NSString *iv = @"1234567812345678";  //Bad idea to hard code IV
char ivPtr[kCCBlockSizeAES128];

[iv getCString:ivPtr maxLength:sizeof(ivPtr) encoding:NSASCIIStringEncoding];
...
ccStatus = CCCrypt(   kCCEncrypt,
                      kCCAlgorithmAES128,
                      kCCOptionPKCS7Padding,
                      [key cStringUsingEncoding:NSASCIIStringEncoding],
                      kCCKeySizeAES128,
                      [ivPtr], /*IV should be something random (not null and not constant)*/
                      [self bytes], dataLength, /* input */
                      buffer, bufferSize, /* output */
                      &numBytesEncrypted
                  );

In addition, if CBC mode is selected when calling CCCrypt and no IV is provided (nil) then an IV of all zeros will be used.

Initialization vectors (IVs) should be created using a cryptographic pseudorandom number generator. Not using a random IV makes the resulting ciphertext much more predictable and susceptible to a dictionary attack.

Example 1: The following code reuses the key as the IV:

from Crypto.Cipher import AES
from Crypto import Random
...
key = Random.new().read(AES.block_size)
cipher = AES.new(key, AES.MODE_CTR, IV=key)

When you use the key as the IV, an attacker may recover the key, allowing the data to be decrypted.

Initialization vectors (IVs) should be created using a cryptographic pseudorandom number generator. Not using a random IV makes the resulting ciphertext much more predictable and susceptible to a dictionary attack.

Example 1: The following code reuses the key as the IV:

require 'openssl'
...
cipher = OpenSSL::Cipher::AES.new('256-GCM')
cipher.encrypt
@key = cipher.random_key
cipher.iv=@key

encrypted = cipher.update(data) + cipher.final # encrypts data without hardcoded IV
...

When you use the key as the IV, an attacker may recover the key, allowing the data to be decrypted.

Initialization vectors (IVs) should be created using a cryptographic pseudorandom number generator. Not using a random IV makes the resulting ciphertext much more predictable and susceptible to a dictionary attack.

Example 1: The following code creates a non-random IV using hardcoded bytes.

...
let cStatus = CCCrypt(UInt32(kCCEncrypt),
UInt32(kCCAlgorithmAES128),
UInt32(kCCOptionPKCS7Padding),
key,
keyLength,
"0123456789012345", 
plaintext, 
plaintextLength,
ciphertext, 
ciphertextLength,
&numBytesEncrypted)

In addition, if CBC mode is selected when calling CCCrypt and no IV is provided (nil) then an IV of all zeros will be used.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    var storedPassword:String = null;
    var temp:String;

    if ((temp = readPassword()) != null) {
        storedPassword = temp;
    }

    if(Utils.verifyPassword(userPassword, storedPassword))
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for userPassword.

Assigning null to password variables is never a good idea as it might enable attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    string storedPassword = null;
    string temp;

    if ((temp = ReadPassword(storedPassword)) != null) {
        storedPassword = temp;
    }

    if (Utils.VerifyPassword(storedPassword, userPassword)) {
        // Access protected resources
        ...
    }
    ...

If ReadPassword() fails to retrieve the stored password due to a database error or other problem, then an attacker can easily bypass the password check by providing a null value for userPassword.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    string storedPassword = null;
    string temp;

    if ((temp = ReadPassword(storedPassword)) != null) {
        storedPassword = temp;
    }

    if(Utils.VerifyPassword(storedPassword, userPassword))
        // Access protected resources
        ...
    }
    ...

If ReadPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for userPassword.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    char *stored_password = NULL;

    readPassword(stored_password);

    if(safe_strcmp(stored_password, user_password))
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for user_password.

Assigning null to password variables is never a good idea as it might enable attackers to bypass password verification or it might indicate that resources are protected by an empty password.

It is not a good idea to have a null password.

Example: The following code sets the password initially to null:

    ...
    var password=null;
    ...
    {
        password=getPassword(user_data);
        ...
    }
    ...
    if(password==null){
        // Assumption that the get didn't work
        ...
        }
    ...

Never assign null to password variables because it might enable attackers to bypass password verification or indicate that resources are not protected by a password.

Example: The following JSON initializes a null password.

{
  ...
  "password" : null
  ...
}

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    NSString *stored_password = NULL;

    readPassword(stored_password);

    if(safe_strcmp(stored_password, user_password)) {
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for user_password.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

<?php
    ...
    $storedPassword = NULL;

    if (($temp = getPassword()) != NULL) {
      $storedPassword = $temp;
    }

    if(strcmp($storedPassword,$userPassword) == 0) {
        // Access protected resources
        ...
    }
    ...
?>

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for userPassword.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example: The following code initializes a password variable to null.

DECLARE
    password VARCHAR(20);
BEGIN
    password := null;
END;

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

...
storedPassword = NULL;

temp = getPassword()
if (temp is not None) {
  storedPassword = temp;
}

if(storedPassword == userPassword) {
    // Access protected resources
    ...
}
...

If getPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for userPassword.

Assigning nil to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to nil, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    @storedPassword = nil
    temp = readPassword()
    storedPassword = temp unless temp.nil?
    unless Utils.passwordVerified?(@userPassword, @storedPassword)
      ...
    end
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for @userPassword.

Due to the dynamic nature of Ruby, many functions also take an optional number of arguments, so the password may be set to nil as a default value when none is specified. In this case you also need to make sure that the correct number of arguments are specified in order to make sure a password is passed to the function.

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 following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    ws.url(url).withAuth("john", null, WSAuthScheme.BASIC)
    ...

Assigning nil to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

...
var stored_password = nil

readPassword(stored_password)

if(stored_password == user_password) {
// Access protected resources
...
}
...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for user_password.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code 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;Passwd=" & storedPassword &";"
    ...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:

...
Rfc2898DeriveBytes rdb = new Rfc2898DeriveBytes("", salt,100000);
...

Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:

...
CCKeyDerivationPBKDF(kCCPBKDF2,
                     "",
                     0,
                     salt,
                     saltLen
                     kCCPRFHmacAlgSHA256,
                     100000,
                     derivedKey,
                     derivedKeyLen);
...

Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

Example 2: Some lower-level APIs may require passing the length of certain arguments as well as the argument values themselves, such that a function can read the argument's value as a number of consecutive bytes beginning at the argument's location in memory. The following code passes zero as the password length argument to a cryptographic PBKDF:

...
CCKeyDerivationPBKDF(kCCPBKDF2,
                     password,
                     0,
                     salt,
                     saltLen
                     kCCPRFHmacAlgSHA256,
                     100000,
                     derivedKey,
                     derivedKeyLen);
...

In this scenario, even if password contains a strong, appropriately managed password value, passing its length as zero will result in an empty, null, or otherwise unexpected weak password value.

It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:

...
$zip = new ZipArchive();
$zip->open("test.zip", ZipArchive::CREATE);
$zip->setEncryptionIndex(0, ZipArchive::EM_AES_256, "");
...

Anyone with access to the code can determine that it generates one or more cryptographic keys based on an empty password argument. Additionally, anyone with even basic cracking techniques might successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:

from hashlib import pbkdf2_hmac
...
dk = pbkdf2_hmac('sha256', '', salt, 100000)
...

Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:

...
key = OpenSSL::PKCS5::pbkdf2_hmac('', salt, 100000, 256, 'SHA256')
...

Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:

...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
"",
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...

Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

Example 2: Some lower-level APIs may require passing the length of certain arguments as well as the argument values themselves, such that a function can read the argument's value as a number of consecutive bytes beginning at the argument's location in memory. The following code passes zero as the password length argument to a cryptographic PBKDF:

...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
password,
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...

In this scenario, even if password contains a strong, appropriately managed password value, passing its length as zero will result in an empty, null, or otherwise unexpected weak password value.