在Android应用Shared Preferences中发现IV和salt key：用途及安全发现判定问询

Great question—let’s break this down clearly for you, as someone who’s dealt with plenty of Android security audits:

1. What are IV and Salt used for? #

Let’s cover each one separately since they serve distinct purposes:

Salt #

• Thwarts rainbow table attacks: Rainbow tables are precomputed lists of hash values for common passwords. Adding a unique, random salt to each password before hashing ensures identical passwords produce different hash outputs, making rainbow tables useless against your stored credentials.
• Ensures hash uniqueness: Even if two users pick the same password, their unique salts will create distinct hashes. This prevents attackers from identifying duplicate passwords in your storage.
• Works hand-in-hand with hashing algorithms: It’s typically paired with algorithms like SHA-256, bcrypt, or Argon2 when storing passwords. Important note: Salt doesn’t need to be kept secret—it just needs to be unique per user and stored alongside the hash.

IV (Initialization Vector) #

• Enables secure symmetric encryption: For block ciphers like AES, an IV ensures that identical plaintext blocks encrypt to different ciphertexts. Without an IV, repeating plaintext patterns would show up as repeating ciphertext, letting attackers guess the underlying content.
• Requires randomness/uniqueness: The IV must be generated randomly (or at least uniquely) for each encryption operation. Like salt, it doesn’t need to be secret—but it must be provided during decryption to correctly recover the plaintext.
• Stored with ciphertext: You’ll almost always see the IV stored alongside the encrypted data, since decrypting without it is impossible.

2. Is finding these in Shared Preferences a valid security finding? #

This depends on context, but in most cases, yes—especially if the Shared Preferences aren’t encrypted or if sensitive data is stored alongside them:

• Salt alone: Salt doesn’t need to be secret, so storing it in Shared Preferences isn’t inherently a critical flaw. However, if the hashed passwords are also stored in the same unencrypted Shared Preferences, an attacker with root/debug access could combine the salt and hash to brute-force the original password. That’s a valid concern.
• IV alone: Similarly, IVs don’t need to be secret, but if the encrypted data and encryption keys are also in unencrypted Shared Preferences, an attacker can use the IV + ciphertext + key to decrypt all sensitive content. That’s a major security issue.
• Core risk with Shared Preferences: By default, Shared Preferences are stored as plaintext XML files in /data/data/<your-package>/shared_prefs/. Any user with a rooted device or access to debug tools can read these files easily. So if IV/salt are paired with keys, hashes, or encrypted data here, this is a clear security gap that needs fixing.

Best practice: Move sensitive keys to Android Keystore, use Encrypted Shared Preferences for storing IVs, salts, or encrypted content, and avoid storing raw hashed passwords in unencrypted storage.

内容的提问来源于stack exchange，提问作者Gayatri Rachakonda