Privacy violations occur when:

1. Private user information enters the program.

2. The data is written to an external location, such as the console, file system, or network.
Example 1: The following code contains a logging statement that tracks the records added to a database by storing the contents in a log file.

pass = getPassword();
...
dbmsLog.println(id+":"+pass+":"+type+":"+tstamp);

The code in Example 1 logs a plain text password to the file system. Although many developers trust the file system as a safe storage location for data, it should not be trusted implicitly, particularly when privacy is a concern.

Privacy is one of the biggest concerns in the mobile world for a couple of reasons. One of them is a much higher chance of device loss. The other has to do with inter-process communication between mobile applications. With mobile platforms, applications are downloaded from various sources and are run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which is why application authors need to be careful about what information they include in messages addressed to other applications running on the device. Sensitive information should never be part of inter-process communication between mobile applications.

Example 2: The following code reads username and password for a given site from an Android WebView store and broadcasts them to all the registered receivers.

...
webview.setWebViewClient(new WebViewClient() {
  public void onReceivedHttpAuthRequest(WebView view,
        HttpAuthHandler handler, String host, String realm) {
    String[] credentials = view.getHttpAuthUsernamePassword(host, realm);
    String username = credentials[0];
    String password = credentials[1];
    Intent i = new Intent();
    i.setAction("SEND_CREDENTIALS");
    i.putExtra("username", username);
    i.putExtra("password", password);
    view.getContext().sendBroadcast(i);
  }
});
...

This example demonstrates several problems. First of all, by default, WebView credentials are stored in plain text and are not hashed. If a user has a rooted device (or uses an emulator), they can read stored passwords for given sites. Second, plain text credentials are broadcast to all the registered receivers, which means that any receiver registered to listen to intents with the SEND_CREDENTIALS action will receive the message. The broadcast is not even protected with a permission to limit the number of recipients, although in this case we do not recommend using permissions as a fix.

Private data can enter a program in a variety of ways:

- Directly from the user in the form of a password or personal information

- Accessed from a database or other data store by the application

- Indirectly from a partner or other third party

Typically, in the context of the mobile environment, this private information includes (along with passwords, SSNs, and other general personal information):

- Location

- Cell phone number

- Serial numbers and device IDs

- Network Operator information

- Voicemail information


Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private.

Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can create risk.

Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable to store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted. For example, in 2004, an unscrupulous employee at AOL sold approximately 92 million private customer email addresses to a spammer marketing an offshore gambling web site [1].

In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Despite these regulations, privacy violations continue to occur with alarming frequency.

A key derivation function is used to derive a key from a base key and other parameters. In a password-based key derivation function, the base key is a password and the other parameters are a salt value and an iteration count. An iteration count has traditionally served the purpose of increasing the cost of generating keys from a password. If the iteration count is too low, the feasibility of an attack increases as an attacker can compute "rainbow tables" for the application and more easily determine the hashed password values.

Example 1: The following code uses an iteration count of 50:

...
final int iterationCount=50;
PBEParameterSpec pbeps=new PBEParameterSpec(salt,iterationCount);
...

Applications that use a low iteration count for password-based encryption are vulnerable to trivial dictionary-based attacks -- exactly the type of attack that password-based encryption schemes were designed to protect against.

Single sign-on enables a service provider to use a single identity system across multiple applications without requiring that each application manage credential information separately. An identity provider verifies the user credentials and provides a token to the service provider to prove the user's validity. These tokens are the primary artifact the service provider uses to authenticate and authorize users into the service. These tokens are susceptible to replay attack and can enable an attacker to impersonate a valid user and gain unauthorized access to the service. A network intruder with man-in-the-middle access or browser cache on a public kiosk could reveal this type of authentication token to malicious vectors. After attackers have access to a valid token, user credentials are not required, which could be secured with an additional two factor provision. Security Assertion Markup Language (SAML) tokens are a popular example of SSO tokens. A service provider can take several measures to thwart replay attacks for SAML tokens. These include setting a short token validity period and assigning a unique ID to each token request and response.

It is never a good idea to use an empty salt. Not only does an empty salt defeat its own purpose but all of the project's developers can view the salt. It makes fixing the problem extremely difficult because after 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 easily determine the hashed values.

Example 1: The following code defines an empty salt for password hashing:

...
define('SECURE_AUTH_SALT', "");
...

This code runs successfully, but anyone who has access to it can see the salt. After the program ships, there is likely no way to change the empty salt. An employee with access to this information can use it to break into the system.

The California driver's license number must be treated as private information. As such, this information is susceptible to theft if it is transmitted, stored or processed in an unsafe manner. Access to legitimate driver license numbers could lead to the theft of victim's identity.

Privacy violation occurs when:
1. A California driver's license number enters the program.

2. The California driver's license number is written to an external location, such as the console, file system or network.

Transmitting the driver license number over an unencrypted channel, hardcoding personal information inside the application code, unencrypted storage of the license details in insufficiently protected back up files are some of the potential causes that could allow an attacker to gain access to a victim's California license number.

The license information could either be supplied to the application directly by the user, accessed from a database or similar data store or indirectly provided by a partner or other third party.

Unsafe logging of the license information could also pose a risk. Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk.

California SB-1386 is a California law regulating the handling of private information like the driver's license number.

The credit card number must be treated as private information. As such, this information is susceptible to theft if it is transmitted, stored or processed in an unsafe manner. Access to legitimate driver license numbers could lead to the theft of victim's identity.

Privacy violation occurs when:
1. A credit card number enters the program.

2. The credit card number is written to an external location, such as the console, file system or network.

Transmitting credit card information over an unencrypted channel, hardcoding it inside the application code, unencrypted storage of credit card details in insufficiently protected back up files are some of the potential causes that could allow an attacker to gain access to a victim's credit card number.

The credit card information could either be supplied to the application directly by the user, accessed from a database or similar data store or indirectly provided by a partner or other third party.

Unsafe logging practice could also pose a risk. Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk.

Collection and management of private information is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

The social security number (SSN) must be treated as private information. As such, this information is susceptible to theft if it is transmitted, stored or processed in an unsafe manner. Access to legitimate social security numbers could lead to the theft of victim's identity.

Privacy violation occurs when:
1. A social security number enters the program.

2. The social security number is written to an external location, such as the console, file system or network.

Transmitting social security numbers over an unencrypted channel, hardcoding them inside the application code, unencrypted storage of social security details in insufficiently protected back up files are some of the potential causes that could allow an attacker to gain access to a victim's SSN.

The SSN information could either be supplied to the application directly by the user, accessed from a database or similar data store or indirectly provided by a partner or other third party.

Unsafe logging practice could also pose a risk. Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk.

Collection and management of private information is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]