Listen to this Post
Introduction
The European Union recently unveiled its open‑source age verification app, designed to protect minors online by allowing users to prove they are over 18 without sharing personal data. Within 48 hours, security researcher Paul Moore demonstrated that the app can be completely bypassed in under two minutes by simply editing a local configuration file. The core failure: the app encrypts the user’s PIN but stores both the ciphertext and the initialisation vector (IV) in a plaintext XML file (shared_prefs), with no cryptographic binding between the PIN and the actual identity vault. This design flaw enables an attacker with physical device access to delete the PIN values, set a new PIN, and gain full access to the previously enrolled identity credentials—without any alerts, logs, or additional verification.
Learning Objectives
- Understand how insecure local storage (plaintext `shared_prefs` files) can completely break an application’s authentication mechanism.
- Learn to enumerate, modify, and exploit local configuration files on Android to bypass PIN, rate‑limiting, and biometric protections.
- Apply secure coding practices—such as using the Android Keystore system and cryptographic binding—to prevent identity vault hijacking.
You Should Know
- Anatomy of the Attack: Deleting Two Values to Take Over an Entire Digital Identity
The exploit chain is alarmingly simple. The EU age verification app stores its security settings in a standard Android `shared_prefs` XML file (e.g., eudi-wallet.xml). When a user sets a six‑digit PIN, the app encrypts it and saves the resulting ciphertext (PinEnc) and its initialisation vector (PinIV) in this file. However, the PIN is not cryptographically tied to the identity vault; the vault simply checks whether the presented PIN decrypts to a known value. Consequently, an attacker with physical access to the device can delete the two entries and restart the app. The app, finding no PIN, enters the initial setup flow, asks for a new PIN, and then—without any re‑verification—associates the new PIN with the existing identity vault. The result: the attacker can now present the victim’s identity credentials as their own.
Step‑by‑step guide to replicate (for authorised testing only):
- Enable developer options and USB debugging on the target Android device (or obtain physical access to a rooted device).
2. Use ADB to pull the configuration file:
adb pull /data/data/[bash]/shared_prefs/eudi-wallet.xml
(Replace `
` with the actual package name, e.g., <code>eu.age.verification.wallet</code>) 3. Open the XML file and locate the `PinEnc` and `PinIV` entries: [bash] <string name="PinEnc">encrypted_data_here</string> <string name="PinIV">iv_value_here</string>
4. Delete both lines and save the file.
5. Push the modified file back:
adb push eudi-wallet.xml /data/data/[bash]/shared_prefs/
6. Restart the app (or force‑stop it via adb shell am force-stop
</code>). 7. The app will re‑enter the initial setup flow; enter a new PIN of your choice. 8. The app will now grant access to the original identity vault—complete with all previously stored credentials—without any warning. Why this works: The app’s identity vault is never re‑encrypted or re‑bound to the new PIN. The vault simply assumes that if the PIN decrypts successfully (or, in this case, if a new PIN is created), the identity is valid. There is no secondary check, no cryptographic signature, and no server‑side validation. <ol> <li>Bypassing Rate Limiting and Biometric Authentication via the Same Config File</li> </ol> The `shared_prefs` file also controls other critical security mechanisms. The rate‑limiting counter (e.g., <code>attempt_counter</code>) is stored as a simple integer. An attacker can reset it to zero and continue guessing PINs indefinitely. Even more worryingly, the biometric authentication flag (<code>UseBiometricAuth</code>) is a Boolean value; setting it to `false` completely disables fingerprint or facial recognition, allowing the attacker to skip that protection entirely. Step‑by‑step guide to disable rate limiting and biometric auth: <ol> <li>Pull the configuration file as described in the previous section.</li> </ol> <h2 style="color: yellow;">2. Locate the rate‑limiting entry:</h2> [bash] <int name="attempt_counter" value="5" />
Change the value to `0` to reset the attempt counter.
3. Locate the biometric authentication flag:
<boolean name="UseBiometricAuth" value="true" />
Change the value to `false`.
- Push the file back and restart the app.
- The app will now allow unlimited PIN attempts and will not prompt for biometric verification.
Impact: An attacker can brute‑force the six‑digit PIN (1,000,000 possibilities) without any lockout, and can bypass fingerprint or face unlock entirely. This turns a “secure” wallet into a completely unprotected storage area.
- Hardening Android Local Storage: From Insecure SharedPreferences to the Android Keystore
The root cause of the EU app’s failure is the misuse of `SharedPreferences` for storing authentication secrets. `SharedPreferences` is designed for simple, non‑sensitive application preferences—not for cryptographic keys or identity tokens. When an app must store a PIN, password, or biometric‑protected key, the correct approach is to use the Android Keystore system in combination with EncryptedSharedPreferences. The Keystore ensures that cryptographic keys never leave the device’s secure hardware (if available) and are bound to the user’s authentication credentials.
Step‑by‑step secure implementation guide:
- Generate a key in the Android Keystore (requires API level 23+):
val keyGenerator = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore") keyGenerator.init( KeyGenParameterSpec.Builder( "my_auth_key", KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT ) .setBlockModes(KeyProperties.BLOCK_MODE_GCM) .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE) .setUserAuthenticationRequired(true) // Require biometric/PIN for key use .setInvalidatedByBiometricEnrollment(true) .build() ) val secretKey = keyGenerator.generateKey()
2. Create `EncryptedSharedPreferences` using the Keystore key:
val masterKey = MasterKey.Builder(context) .setKeyScheme(MasterKey.KeyScheme.AES256_GCM) .setUserAuthenticationRequired(true) .build() val encryptedPrefs = EncryptedSharedPreferences.create( context, "secure_prefs", masterKey, EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV, EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM )
- Store the PIN or authentication secret (note: always store a hash, not the raw PIN):
val hashedPin = hashPin(plainPin) // Use a strong KDF like Argon2 encryptedPrefs.edit() .putString("hashed_pin", hashedPin) .putBoolean("is_biometric_enabled", true) .apply() -
Bind the authentication secret to the identity vault by deriving a vault encryption key from the PIN (using a KDF) and storing that key in the Keystore, tied to the user’s authentication. Never store the vault key in
SharedPreferences—even encrypted.
Why this works: The Keystore enforces that the key can only be used after the user has successfully authenticated (e.g., by entering their device PIN, password, or biometric). Even if an attacker has root access to the device, they cannot extract the key or use it without the user’s live authentication. `EncryptedSharedPreferences` automatically encrypts both keys and values, so tampering with the XML file is impossible without the Keystore key.
4. Defensive Coding Against Local Storage Attacks
Developers often mistakenly believe that “encryption” alone is sufficient for local storage. The EU app’s designers encrypted the PIN but stored the IV alongside the ciphertext in a file that any process with file‑system access can read and modify. This is a textbook example of insecure data storage (OWASP Mobile Top 10: M1). Even worse, the lack of cryptographic binding between the PIN and the identity vault allowed a complete takeover.
Linux/Windows forensic commands to detect such issues:
- On Linux/macOS (for Android backups):
Extract a backup of the app's data adb backup -f app_backup.ab [bash] Convert the backup to a tar file dd if=app_backup.ab bs=1 skip=24 | python -c "import zlib,sys;sys.stdout.buffer.write(zlib.decompress(sys.stdin.buffer.read()))" > backup.tar Extract the tar and inspect shared_prefs tar -xvf backup.tar cat apps/[bash]/sp/.xml
-
On Windows (using PowerShell with Android SDK):
Pull the shared_prefs directory adb pull /data/data/[bash]/shared_prefs C:\temp\app_prefs Check for unencrypted sensitive data Select-String -Path "C:\temp\app_prefs.xml" -Pattern "PinEnc|PinIV|password|token"
What to look for: Any occurrence of PinEnc, PinIV, password, token, or `session` in an XML file should raise immediate red flags. If these values are present, the app is likely storing sensitive data insecurely.
5. Real‑World Consequences and the EU’s Response
The EU age verification app is not a toy; it is intended to be a production system for digital identity across the bloc. Six member states are already piloting the app with real passports and identity documents. Yet the discovered vulnerabilities show that an attacker with even temporary physical access (e.g., a lost phone, a malicious acquaintance, or a compromised device) can completely assume the victim’s digital identity. The EU Commission initially claimed the app is “technically ready” and that the vulnerabilities were fixed, but independent researchers confirmed that the issues were present in the latest open‑source code. French white‑hat hacker Baptiste Robert and cryptographic researcher Olivier Blazy both validated the bypasses. Telegram CEO Pavel Durov went further, suggesting the vulnerabilities might be intentional—a surveillance mechanism disguised as age verification. Regardless of intent, the practical outcome is clear: local storage is the new perimeter, and the EU app failed to secure it.
What Undercode Say
- Local storage is never a security boundary. Any data stored on a device that the user (or an attacker with physical access) can read or modify must be considered untrusted. Encryption without key binding and integrity protection is merely obfuscation.
- Authentication and identity data must be cryptographically bound. A PIN, password, or biometric should be directly tied to the identity vault via a key derivation function (KDF) and a hardware‑backed keystore. Separating the two—as the EU app did—is a catastrophic design error.
- Open source is a double‑edged sword. The EU praised the app’s transparency, but that same openness allowed attackers to find and exploit the flaws within hours. Open source is only as secure as its design; if the design is fundamentally broken, transparency only accelerates the discovery of those breaks.
Prediction
This incident will accelerate the adoption of hardware‑enforced security models (e.g., Android Keystore, iOS Secure Enclave) for all government‑issued digital identity apps. Regulators will likely mandate that any digital wallet or identity app must store cryptographic keys in secure hardware and must cryptographically bind authentication factors to the identity data. We can also expect a wave of lawsuits under GDPR, as the storage of biometric data and selfies without proper protection (as documented in this app) constitutes a clear violation of data protection principles. For developers, the lesson is unforgiving: never roll your own crypto, never store secrets in plaintext XML, and always assume that an attacker has full access to the device’s file system. The EU’s embarrassment will serve as a case study for cybersecurity courses for years to come.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Joaorebordaoneves Eu - Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
