Use improper, short, insufficient and predictable instead of weak

Author: sydseter

Document/0x04b-Mobile-App-Security-Testing.md

@@ -139,7 +139,7 @@ When developing a mobile application, it's crucial to accurately identify and ha
 
 Properly distinguishing security-relevant contexts helps in minimizing false positives during security testing. False positives can divert attention from real issues and waste valuable resources. Here are some common scenarios:
 
-- **Random Number Generation**: Using weak random number generators can be a serious security flaw in contexts like authentication or encryption key generation. However, not all uses of random numbers are security-sensitive. For instance, using a less robust random number generator for non-security purposes like shuffling a list of items in a game is generally acceptable.
+- **Random Number Generation**: Using predictable random number generators can be a serious security flaw in contexts like authentication or encryption key generation. However, not all uses of random numbers are security-sensitive. For instance, using a less robust random number generator for non-security purposes like shuffling a list of items in a game is generally acceptable.
 
 - **Hashing**: Hashing is often used in security for storing passwords or ensuring data integrity. However, hashing a non-sensitive value, like a device's screen resolution for analytics, isn't a security concern.
 

Document/0x04g-Testing-Cryptography.md

@@ -152,10 +152,10 @@ PRNG can be vulnerable when developers use a regular PRNG for cryptographic purp
 
 Mobile SDKs offer standard implementations of PRNG algorithms that produce numbers with sufficient artificial randomness. We'll introduce the available APIs in the Android and iOS specific sections.
 
-### Weak hashing
+### Weak, Risky or Broken Hashing
 
 Make sure to choose a hash function that is built for the purpose you intend it for.
-When hashes are needed for integrity checks, choose an algorithm that is sufficiently collision resistant like the integrity algorithms SHA-256, SHA-384, SHA-512, BLAKE3 and the SHA-3 family. Choosing a weak algorithm may compromise the integrity and authenticity of data at rest and in transit. Also keep in mind that hash functions used for integrity checks, like the SHA series, should not be used for key derivation together with predictable input or in password hashing.
+When hashes are needed for integrity checks, choose an algorithm that is sufficiently collision resistant like the integrity algorithms SHA-256, SHA-384, SHA-512, BLAKE3 and the SHA-3 family. Choosing a risky or broken algorithm may compromise the integrity and authenticity of data at rest and in transit. Also keep in mind that hash functions used for integrity checks, like the SHA series, should not be used for key derivation together with predictable input or in password hashing.
 
 ### Custom Implementations of Cryptography
 

Document/0x05d-Testing-Data-Storage.md

@@ -465,7 +465,7 @@ Deriving a key from a user provided passphrase is a common solution (depending o
 
 Each time the application needs to perform a cryptographic operation, the user's passphrase is needed. Either the user is prompted for it every time, which isn't an ideal user experience, or the passphrase is kept in memory as long as the user is authenticated. Keeping the passphrase in memory is not a best-practice, as any cryptographic material must only be kept in memory while it is being used. Zeroing out a key is often a very challenging task as explained in ["Cleaning out Key Material"](#cleaning-out-key-material).
 
-Additionally, consider that keys derived from a passphrase have their own weaknesses. For instance, the passwords or passphrases might be reused by the user or easy to guess. Please refer to the [Testing Cryptography chapter](0x04g-Testing-Cryptography.md#weak-key-generation-functions) for more information.
+Additionally, consider that keys derived from a passphrase have their own weaknesses. For instance, the passwords or passphrases might be reused by the user or easy to guess. Please refer to the [Testing Cryptography chapter](0x04g-Testing-Cryptography.md#improper-key-derivation-functions) for more information.
 
 #### Cleaning out Key Material
 

Document/0x05e-Testing-Cryptography.md

@@ -210,7 +210,7 @@ KeyPair keyPair = keyPairGenerator.generateKeyPair();
 
 This sample creates the RSA key pair with a key size of 4096-bit (i.e. modulus size). Elliptic Curve (EC) keys can also be generated in a similar way. However as of Android 11 (API level 30), [AndroidKeyStore does not support encryption or decryption with EC keys](https://developer.android.com/guide/topics/security/cryptography#SupportedCipher). They can only be used for signatures.
 
-A symmetric encryption key can be generated from the passphrase by using the Password Based Key Derivation Function version 2 (PBKDF2). This cryptographic protocol is designed to generate cryptographic keys, which can be used for cryptography purpose. Input parameters for the algorithm are adjusted according to [weak key generation function](0x04g-Testing-Cryptography.md#weak-key-generation-functions) section. The code listing below illustrates how to generate a strong encryption key based on a password.
+A symmetric encryption key can be generated from the passphrase by using the Password Based Key Derivation Function version 2 (PBKDF2). This cryptographic protocol is designed to generate cryptographic keys, which can be used for cryptography purpose. Input parameters for the algorithm are adjusted according to [improper key generation function](0x04g-Testing-Cryptography.md#improper-key-derivation-functions) section. The code listing below illustrates how to generate a strong encryption key based on a password.
 
 ```java
 public static SecretKey generateStrongAESKey(char[] password, int keyLength)

docs/news/posts/2024-07-30-new-maswe.md

@@ -41,7 +41,7 @@ Now MASVS, MASWE and MASTG are all seamlessly connected. We start with the high-
 1. **MASVS Controls**: High-level platform-agnostic requirements.
    > For example, "The app employs current cryptography and uses it according to best practices." ([MASVS-CRYPTO-1](https://mas.owasp.org/MASVS/controls/MASVS-CRYPTO-1/)).
 2. **MASWE Weaknesses**: Specific weaknesses, typically also platform-agnostic, related to the controls.
-   > For example, "use of weak pseudo-random number generation" ([MASWE-0027](https://mas.owasp.org/MASWE/MASVS-CRYPTO/MASWE-0027/)).
+   > For example, "use of predictable pseudo-random number generation" ([MASWE-0027](https://mas.owasp.org/MASWE/MASVS-CRYPTO/MASWE-0027/)).
 3. **MASTG Tests**: Each weakness is evaluated by executing tests that guide the tester in identifying and mitigating the issues using various tools and techniques on each mobile platform.
    > For example, testing for "insecure random API usage on Android" ([MASTG-TEST-0204](https://mas.owasp.org/MASTG/tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0204/)).
 4. **MASTG Demos**: Practical demonstrations that include working code samples and test scripts to ensure reproducibility and reliability.

prerequisites/identify-security-relevant-contexts.md

@@ -4,7 +4,7 @@ When developing a mobile application, it's crucial to accurately identify and ha
 
 Properly distinguishing security-relevant contexts helps in minimizing false positives during security testing. False positives can divert attention from real issues and waste valuable resources. Here are some common scenarios:
 
-- **Random Number Generation**: Using weak random number generators can be a serious security flaw in contexts like authentication or encryption key generation. However, not all uses of random numbers are security-sensitive. For instance, using a less robust random number generator for non-security purposes like shuffling a list of items in a game is generally acceptable.
+- **Random Number Generation**: Using predictable random number generators can be a serious security flaw in contexts like authentication or encryption key generation. However, not all uses of random numbers are security-sensitive. For instance, using a less robust random number generator for non-security purposes like shuffling a list of items in a game is generally acceptable.
 
 - **Hashing**: Hashing is often used in security for storing passwords or ensuring data integrity. However, hashing a non-sensitive value, like a device's screen resolution for analytics, isn't a security concern.
 

rules/mastg-android-weak-encryption-algorithms.yaml

@@ -4,6 +4,6 @@ rules:
       - java
     severity: WARNING
     metadata:
-      summary: This rule looks for weak encryption algorithms.
-    message: "[MASVS-CRYPTO-1] Weak encryption algorithms found in use."
+      summary: This rule looks for risky or broken encryption algorithms.
+    message: "[MASVS-CRYPTO-1] Risky or broken encryption algorithms found in use."
     pattern-regex: Cipher\.getInstance\("?(DES|DESede|RC4|Blowfish)(/[A-Za-z0-9]+(/[A-Za-z0-9]+)?)?"?\)

rules/mastg-android-weak-encryption-modes.yaml

@@ -4,8 +4,8 @@ rules:
       - java
     severity: WARNING
     metadata:
-      summary: This rule looks for weak encryption modes.
-    message: "[MASVS-CRYPTO-1] Weak encryption modes found in use."
+      summary: This rule looks for predictable encryption modes.
+    message: "[MASVS-CRYPTO-1] Predictable encryption modes found in use."
     pattern-either:
       - pattern: Cipher.getInstance("AES")
       - pattern-regex: Cipher\.getInstance\("?[A-Za-z0-9]+/ECB(/[A-Za-z0-9]+)?"?\)

rules/mastg-android-weak-key-generation.yml

@@ -4,7 +4,7 @@ rules:
     languages:
       - java
     metadata:
-      summary: This rule looks for methods that create a weak key size in encryption algorithms.
+      summary: This rule looks for methods that create a short key size in encryption algorithms.
     message: "[MASVS-CRYPTO] Make sure that the key size is according to security best practices"
     pattern-either:
       - pattern: |

techniques/android/MASTG-TECH-0014.md

@@ -17,7 +17,7 @@ grep 'android:minSdkVersion' AndroidManifest.xml
 
 This command searches for the `android:minSdkVersion` attribute within the manifest file. Ensuring a higher `minSdkVersion` can reduce security risks, as older versions of Android may not include the latest security features and fixes.
 
-## Example: Using semgrep for Identifying Weak Cryptography
+## Example: Using semgrep for Identifying Predictable Seed
 
 semgrep is a more advanced tool that can be used for pattern matching in code. It's particularly useful for identifying complex coding patterns that might lead to security vulnerabilities. For example, to find instances where a deterministic seed is used with the `SecureRandom` class (which can compromise the randomness and thus the security), you can use a semgrep rule like:
 

techniques/generic/MASTG-TECH-0049.md

@@ -7,7 +7,7 @@ Dynamic Analysis tests the mobile app by executing and running the app binary an
 
 - Business logic flaws
 - Vulnerabilities in the tested environments
-- Weak input validation and bad input/output encoding as they are processed through one or multiple services
+- Improper input validation and bad input/output encoding as they are processed through one or multiple services
 
 Analysis can be assisted by automated tools, such as @MASTG-TOOL-0035, while assessing an application. An application can be assessed by side-loading it, re-packaging it, or by simply attacking the installed version.
 

tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0208.md

@@ -1,14 +1,14 @@
 ---
 platform: android
-title: Inappropriate Key Sizes 
+title: Insufficient Key Sizes 
 id: MASTG-TEST-0208
 type: [static]
 weakness: MASWE-0009
 ---
 
 ## Overview
 
-In this test case, we will look for the use inappropriate key sizes in Android apps. To do this, we need to focus on the cryptographic frameworks and libraries that are available in Android and the methods that are used to generate, inspect and manage cryptographic keys.
+In this test case, we will look for the use Insufficient key sizes in Android apps. To do this, we need to focus on the cryptographic frameworks and libraries that are available in Android and the methods that are used to generate, inspect and manage cryptographic keys.
 
 The Java Cryptography Architecture (JCA) provides foundational classes for key generation which are often used directly when portability or compatibility with older systems is a concern.
 
@@ -27,4 +27,4 @@ The output should contain a list of locations where insufficient key lengths are
 
 ## Evaluation
 
-The test case fails if you can find the use of inappropriate key sizes within the source code. For example, a 1024-bit key size is considered weak for RSA encryption and a 128-bit key size is considered weak for AES encryption considering quantum computing attacks.
+The test case fails if you can find the use of insufficient key sizes within the source code. For example, a 1024-bit key size is considered insufficient for RSA encryption and a 128-bit key size is considered insufficient for AES encryption considering quantum computing attacks.

tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0221.md

@@ -1,5 +1,5 @@
 ---
-title: Weak Symmetric Encryption Algorithms
+title: Symmetric Encryption Algorithms with insufficient strength
 platform: android
 id: MASTG-TEST-0221
 type: [static, dynamic]
@@ -9,16 +9,16 @@ best-practices: [MASTG-BEST-0009]
 
 ## Overview
 
-To test for the [use of weak encryption algorithms](../../../Document/0x04g-Testing-Cryptography.md#identifying-insecure-andor-deprecated-cryptographic-algorithms) in Android apps, we need to focus on methods from cryptographic frameworks and libraries that are used to perform encryption and decryption operations.
+To test for the [use of encryption algorithms with insufficient strength](../../../Document/0x04g-Testing-Cryptography.md#identifying-insecure-andor-deprecated-cryptographic-algorithms) in Android apps, we need to focus on methods from cryptographic frameworks and libraries that are used to perform encryption and decryption operations.
 
 - [`Cipher.getInstance`](https://developer.android.com/reference/javax/crypto/Cipher#getInstance(java.lang.String)): Initializes a Cipher object for encryption or decryption. The `algorithm` parameter can be one of the [supported algorithms](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#Cipher).
 - [`SecretKeyFactory.getInstance`](https://developer.android.com/reference/javax/crypto/SecretKeyFactory#getInstance(java.lang.String)): Returns a SecretKeyFactory object that converts keys into key specifications and vice versa. The `algorithm` parameter can be one of the [supported algorithms](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#SecretKeyFactory).
 - [`KeyGenerator.getInstance`](https://developer.android.com/reference/javax/crypto/KeyGenerator#getInstance(java.lang.String)): Returns a `KeyGenerator` object that generates secret keys for symmetric algorithms. The `algorithm` parameter can be one of the [supported algorithms](https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#KeyGenerator).
 
-Some weak symmetric encryption algorithms include:
+Some deprecated, risky or broken symmetric encryption algorithms include:
 
 - **DES (Data Encryption Standard)**: 56-bit key, breakable, [withdrawn by NIST in 2005](https://csrc.nist.gov/pubs/fips/46-3/final).
-- **3DES (Triple DES, officially the Triple Data Encryption Algorithm (TDEA or Triple DEA))**: Weak 64-bit blocks, [vulnerable to Sweet32 birthday attacks](https://sweet32.info/), [withdrawn by NIST on January 1, 2024](https://csrc.nist.gov/pubs/sp/800/67/r2/final).
+- **3DES (Triple DES, officially the Triple Data Encryption Algorithm (TDEA or Triple DEA))**: 64-bit with insufficient block size, [vulnerable to Sweet32 birthday attacks](https://sweet32.info/), [withdrawn by NIST on January 1, 2024](https://csrc.nist.gov/pubs/sp/800/67/r2/final).
 - **RC4**: Predictable key stream, allows plaintext recovery [RC4 Weakness](https://www.rc4nomore.com/), disapproved by [NIST](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-52r1.pdf) in 2014 and prohibited by [IETF](https://datatracker.ietf.org/doc/html/rfc7465) in 2015.
 - **Blowfish**: 64-bit block size, [vulnerable to Sweet32 attacks](https://en.wikipedia.org/wiki/Birthday_attack), never FIPS-approved, and listed under ["Non-Approved algorithms" in FIPS](https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp2092.pdf).
 

tests-beta/android/MASVS-CRYPTO/MASTG-TEST-0232.md

@@ -1,5 +1,5 @@
 ---
-title: Weak Symmetric Encryption Modes
+title: Predictable Symmetric Encryption Modes
 platform: android
 id: MASTG-TEST-0232
 type: [static, dynamic]
@@ -9,7 +9,7 @@ best-practices: [MASTG-BEST-0005]
 
 ## Overview
 
-To test for the [use of weak encryption modes](../../../Document/0x04g-Testing-Cryptography.md#weak-block-cipher-mode) in Android apps, we need to focus on methods from cryptographic frameworks and libraries that are used to configure and apply encryption modes.
+To test for the [use of predictable encryption modes](../../../Document/0x04g-Testing-Cryptography.md#weak-block-cipher-mode) in Android apps, we need to focus on methods from cryptographic frameworks and libraries that are used to configure and apply encryption modes.
 
 In Android development, the `Cipher` class from the Java Cryptography Architecture (JCA) is the primary API that allows you to specify the encryption mode for cryptographic operations. [`Cipher.getInstance`](https://developer.android.com/reference/javax/crypto/Cipher#getInstance(java.lang.String)) defines the transformation string, which includes the encryption algorithm, mode of operation, and padding scheme. The general format is `"Algorithm/Mode/Padding"`. For example:
 

tests-beta/ios/MASVS-CRYPTO/MASTG-TEST-0209.md

@@ -1,14 +1,14 @@
 ---
 platform: ios
-title: Inappropriate Key Sizes
+title: Insufficient Key Sizes
 id: MASTG-TEST-0209
 type: [static, dynamic]
 weakness: MASWE-0009
 ---
 
 ## Overview
 
-In this test case, we will look for the use inappropriate key sizes in iOS apps. To do this, we need to focus on the cryptographic frameworks and libraries that are available in iOS and the methods that are used to generate cryptographic keys.
+In this test case, we will look for the use insufficient key sizes in iOS apps. To do this, we need to focus on the cryptographic frameworks and libraries that are available in iOS and the methods that are used to generate cryptographic keys.
 
 - **CommonCrypto**: The [`CCCrypt`](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/CCCrypt.3cc.html) function is used for symmetric encryption and decryption and specifies the key size or key length in its fifth parameter `keyLength`.
 - **Security**: The [`SecKeyCreateRandomKey`](https://developer.apple.com/documentation/security/1823694-seckeycreaterandomkey) function is used to generate a random key using certain attributes including [`kSecAttrKeyType`](https://developer.apple.com/documentation/security/ksecattrkeytype) and [`kSecAttrKeySizeInBits`](https://developer.apple.com/documentation/security/ksecattrkeysizeinbits). The [`SecKeyGeneratePair`](https://developer.apple.com/documentation/security/1395339-seckeygeneratepair) function is deprecated in iOS 16.
@@ -26,4 +26,4 @@ The output should contain the disassembled code of the functions using `CCCrypt`
 
 ## Evaluation
 
-The test case fails if you can find the use of inappropriate key sizes within the source code. For example, a 1024-bit key size is considered weak for RSA encryption and a 128-bit key size is considered weak for AES encryption considering quantum computing attacks.
+The test case fails if you can find the use of insufficient key sizes within the source code. For example, a 1024-bit key size is considered insufficient for RSA encryption and a 128-bit key size is considered insufficient for AES encryption considering quantum computing attacks.