PK-enabled applications using public key certifications for authentication are not required to implement password authentication, enforce password complexity, or maintenance requirements. Systems not enabling PKI must meet minimum password requirements, as defined in DoDI 8520.2. In short, DoDI 8520.2 identifies when password-based authentication is allowed; however password-based authentication is highly discouraged.7 Upon a proven CAC/PIV smart card solution for Android, it is anticipated that Password Guidance will be deprecated for a CAC/PIV solution. If Android devices incorporate hardware cryptographic modules in the future, that also may allow more flexible authentication guidance.
1Password Masks
Passwords shall be masked, so that they are not visibly displayed. Characters, such as asterisks can be displayed instead of the actual password.
2Password Strength Compliance
All account passwords, both administrative and non-administrative, must comply with the following:
Passwords must be at least 8 characters long.8
Passwords must contain a mix of upper case letters, lower case letters, and numbers.
When a password is changed, users must not be able to use personal information such as names, telephone numbers, account names, or dictionary words.
Passwords must expire after 60 days.
Users must not be able to reuse any of their previous 10 passwords.
Users must not be able to change passwords more than once a day, except in the case of an administrator or a privileged user. Privileged users may be required to reset a user’s forgotten passwords and the ability to change passwords more than once per day.
When a password is changed, the new password must differ from the previous password by at least four characters.
If applications transmit account passwords, they must be transmitted in an encrypted format. Unclassified systems must adhere to FIPS 140-2 encryption module standards. Classified systems require NSA/COMSEC-approved Type-1 encryption or approval through another NSA process such as the emerging NSA Commercial Solutions for Classified process.
3Notice and Consent Banner
Android (and all Personal Electronic Devices) require the use of a standard Notice and Consent Banner. Deviations to the standard banner are not permitted except as authorized in writing by the Deputy Assistant Secretary of Defense for Information and Identity Assurance. The banner shall be implemented as a click-through (or modal) at logon, blocking further access into the application until the user consents, or taps “OK”, to the banner. The banner text should be customizable in the event of future updates.
For Android applications, use the following banner:
 9
Figure 3‑2 Standard DoD PED Banner
In certain environments, the Notice and Consent Banner may have adverse operational security impacts by advertising the fact that the device is associated with the U.S. Government. We recommend that exceptions should be granted from this requirement when appropriate.
Data Protection
Data from Android applications are typically stored in local SQLite databases, located in the application’s directory within the /data partition. The database stores all data in plain text, allowing easy ability for extraction of the .db file and viewing contents in a relational database management system (RDBMS) or other tool. Applications have the ability to store data in other formats or in other directories.
This section will focus on options to store sensitive information within an Android application.
Database Encryption 4Database Encryption Guidance
Sensitive and personally identifiable information (PII), as defined by Application Security and Development STIG V3R2 and FIPS PUB 140-2, shall be protected by means of FIPS 140-2 compliant cryptographic algorithms. If cryptographic technologies are not implemented correctly, it may be possible for an attacker to access protected data.
5Potential Implementations
A challenge for Android applications is that there is no known FIPS 140-2 compliant cryptographic module for SQLite databases. There are, however, some solutions that claim to provide the level of encryption that NIST requires for FIPS 140-2 testing.
Three examples of database encryption include SQLite Encryption Extension (SEE)10, SQLite Crypt11, and SQLCipher12. These are add-ons to SQLite which allows an application to read and write encrypted database files using the Advanced Encryption Standard (AES), and the add-ons could be vetted by NIST for FIPS 140-2 compliancy. This level of protection for sensitive data is necessary in order to assure data protection for an extended period of time.
Known implementations of encrypted Android SQLite databases, are utilizing wxSQLite. wxSQLite 13 includes a SQLite compatible encryption codec in C using the Android Native Development Kit (NDK), and leverages AES. When implemented it is transparent to the developer and user, though it relies on a key to access the database. NOTE: This method is merely a deterrent, as a persistent attacker could locate the on-device key to decrypt the database.
SD Card Storage
Applications should avoid storing data on an external SD card or in the /sdcard partition. It is common for developers to store large databases (i.e. >100MB) on SD cards to facilitate the need for extra storage, but this presents security risks. The /sdcard partition within Android uses a file system that does not support file ownership or file permissions. Therefore, files stored in the /sdcard partition can be accessed or modified by other Android applications. Also, it is trivial for someone with physical access to the Android device to remove the SD card and retrieve or modify its contents, while the internal storage device is more difficult for an attacker to gain physical access to.
6SD Card Storage Guidance
Any use of SD card storage by an application shall be documented as a necessity. The certifying authority must approve data and/or application storage via SD card before it will be approved for usage. Applications must employ encryption and integrity protection on data stored on the SD card, unless it can be demonstrated that the data is not sensitive in any way and that malicious or accidental modifications to the data will have no adverse impact on the application.
Android Application Package
Application developers need to recognize that anyone with access to an Android device can trivially retrieve the .apk application packages from the device, then decompile or reverse engineer the application. Sensitive information such as encryption keys should not be stored within the application code.
File Permissions
Android file systems (except the /sdcard partition) support UNIX file permissions. Each application owns its own directory on the /data partition and has the ability to set its own file permissions on its files and directories.
7File Permission Guidance
Each application’s files and directories should not be set world-readable or world-writable. World-readable files can be accessed by other applications. World-writable files can be modified by other applications. Regardless of read permission, data stored on the device should be encrypted, as discussed in section 3.1, to prevent data leakage in the event of the device being compromised.
Existing Java and Android secure coding guidelines should be leveraged whenever possible. Oracle (formerly Sun) provides a "Secure Coding Guidelines for the Java Programming Language" document14. iSEC Partners provides a "Developing Secure Mobile Applications for Android" paper15. In this section, we describe important secure programming practices, but this section is not all-inclusive. The other sections of this document also describe secure programming practices applicable to those specific sections.
Input Validation
Text fields can potentially be influenced by an attacker to contain characters that maliciously impact software components.
8Input Validation Guidance
Whenever possible, text fields should be strongly typed, meaning that the allowed characters, lengths, and ranges are known and enforced through input validation. Whitelisting (determining and enforcing the allowed content) is generally a better approach than blacklisting (removing specifically disallowed characters), as it is difficult to anticipate all potentially malicious content.
Android applications often use SQLite databases to store and retrieve data. SQL injection vulnerabilities, commonly found in web applications, can occur in Android applications as well. In an SQL injection, an attacker maliciously inputs SQL commands through a data input field, causing unauthorized modifications to or information leakage from an SQL database.
1Input via SQL Guidance
To avoid SQL injection vulnerabilities, user input should not be directly passed to SQL queries (for instance, through string concatenation). Instead, prepared or parameterized statements should be used, which ensure that the inputs to the SQL database are properly sanitized and do not contain malicious content. Android's SQLiteDatabase provides convenience methods to delete, insert, replace, and update database rows. These methods make use of SQL prepared statements and avoid SQL injection vulnerabilities. We recommend these methods be used when possible.
In some cases, the convenience methods may not be an option. In those cases, any time a dynamic input value is used (an input whose value could be set or influenced with malicious intent), a parameterized query needs to be used to avoid SQL injection vulnerabilities. An example of an SQL parameterized query:
CORRECT: db.rawQuery("SELECT * from table where id = ? and name = ?", new String[] { id, name});
INCORRECT: db.rawQuery("SELECT * from table where id =" + id + " and name =" + name, null); This code segment is potentially vulnerable because an attacker could inject malicious SQL statements into the id or name variables.
3Avoiding command injection attacks
Command injection vulnerabilities are possible in Android applications. In a command injection attack, the attacker injects malicious commands into the variables passed to certain functions, which results in the malicious commands being executed. The DISA Application Security and Development STIG lists methods in several programming languages that are susceptible to command injection attacks. The Java methods listed are: Class.forName(), class.newInstance(), and Runtime.exec(). Use of these methods should be avoided. There are often safer Java alternatives to calling these methods. For example, perform filesystem actions using the java.io.File classes rather than invoking Linux shell commands through Runtime.exec(). However, when the use of these methods is necessary, avoid dynamic inputs to these methods that can be influenced by a malicious entity. Instead, use a statically defined list of the set of allowed inputs. If the inputs can be set or influenced externally, then a whitelist of allowed characters, as discussed above, should be used. For instance, only allowing alphanumeric values and blocking all other characters.
|
