Jérôme Signouret 🌱

The @EU_Commission has released an update to patch out the issues I raised last week, v2026.04-2 (#release-notes_1" target="_blank" rel="nofollow noopener">ageverification.dev/releases/#rele…) Honestly, I don't know if I should laugh or cry. Let's review each one: 1. On-device data: database and settings encrypted at rest, with keys protected by the device’s hardware-backed key store. Sounds great, until you look closer. They introduced androidx.security:security-crypto, deprecated in 2025. Also androidx.security.crypto.EncryptedSharedPreferences, deprecated in 2025. Finally, androidx.security.crypto.MasterKeys, which were deprecated in 2020. 3 deprecated dependencies introduced following criticism over weak security. These weren't left over and missed during an update... they've added them now to "harden security". Remember, this isn't an isolated app. It's intended to lay the foundation for many production applications; all using deprecated security libraries from the outset. Worse, they already correctly use KeystoreController in their codebase. The correct answer already existed and they still got it wrong. 2. Runtime: the app checks device integrity on startup and refuses to run on rooted or jailbroken devices. Production deployments should complement it with stronger device-attestation mechanisms appropriate to their infrastructure and compliance requirements. They check for su, check package manager for root apps, run "which su" and checks if it's a custom ROM. Paths: /system/bin/su /system/xbin/su /sbin/su /system/su /data/local/su /data/local/bin/su /data/local/xbin/su /system/app/Superuser.apk /system/app/SuperSU.apk Great... in 2015. These are all trivially bypassed in 2026. 3. Passport onboarding: more stable scanning; the passport photo is stored privately and deleted as soon as it’s no longer needed. They're still not encrypted, so I'm not sure what "privately" means - but they are deleted correctly now. 4. PIN: stricter rules block easy-to-guess PINs; PINs are salted and hashed, never stored in plain form. They salt correctly (a true CSPRNG), then use PBKDF2-SHA256 - which is outdated and only recommended where FIPS compliance is required, which doesn't apply here. To make matters worse, they use just 210,000 iterations. For those of a NISTy disposition, you're likely already shaking your head. 210,000 seems oddly specific. It is. It's the @owasp minimum for PBKDF2-SHA512, not SHA256. Right number, wrong algorithm. In reality, OWASP recommended 600,000 iterations as a minimum in 2023. Worse still, 600,000 is the baseline minimum for passwords, not PINs with 1 million permutations. You could use 1B iterations, you're not measurably increasing security when there are so few attempts required to break it. At the very least, use a modern hash with reasonable brute-force resistance against a 2026 threat model. All this... cited as a "first hardening step". Again, utter security theatre. None of this negates my fundamental point. This isn't fixable through code - it's fundamentally ill-conceived and poorly implemented.

🚨 INFOS | Le gouvernement s’apprête à sortir une appli de vérification d’âge, adossée à la carte d’identité et intégrée à France Identité. Selon les infos de @emile_marzolf , elle est déjà en bêta, en phase de test, et serait proposée gratuitement aux plateformes pour rendre l’interdiction des réseaux sociaux aux moins de 15 ans “applicable”. On comprend mieux l’urgence à légiférer dès ce soir : quand l’outil est prêt, il ne manque plus qu’un cadre pour l’imposer. ❌Le point critique : l'absence de double-anonymat. Dans un système protecteur, la plateforme ne reçoit qu’un “oui/non” (15+ / 18+), et l’émetteur de la preuve ne sait pas sur quel site ou service la vérification est faite. Autrement dit, personne ne peut relier identité et usage. Sans double-anonymat, on change de registre. Le contrôle d’âge peut devenir une brique de vérification généralisée, où l’accès à des plateformes dépend d’une identité numérique. @GabrielAttal on ne parlait pas ce matin de tiers de confiance ? Vous nous aviez caché que France Identité deviendrait l'outil pour utiliser les réseaux sociaux. L'application se teste en ce moment sur un site “factice” de réservation de places de cinéma mis en place dans le cadre des tests européens. Ils avaient déjà tout prévu et la surveillance est en marche.

Hacking the #EU #AgeVerification app in under 2 minutes. During setup, the app asks you to create a PIN. After entry, the app *encrypts* it and saves it in the shared_prefs directory. 1. It shouldn't be encrypted at all - that's a really poor design. 2. It's not cryptographically tied to the vault which contains the identity data. So, an attacker can simply remove the PinEnc/PinIV values from the shared_prefs file and restart the app. After choosing a different PIN, the app presents credentials created under the old profile and let's the attacker present them as valid. Other issues: 1. Rate limiting is an incrementing number in the same config file. Just reset it to 0 and keep trying. 2. "UseBiometricAuth" is a boolean, also in the same file. Set it to false and it just skips that step. Seriously @vonderleyen - this product will be the catalyst for an enormous breach at some point. It's just a matter of time.

Bypassing #EU #AgeVerification using their own infrastructure. I've ported the Android app logic to a Chrome extension - stripping out the pesky step of handing over biometric data which they can leak... and pass verification instantly. Step 1: Install the extension Step 2: Register an identity (just once) Step 3: Continue using the web as normal The extension detects the QR code, generates a cryptographically identical payload and tells the verifier I'm over 18, which it "fully trusts". This isn't a bug... it's a fundamental design flaw they can't solve without irrevocably tying a key to you personally; which then allows tracking/monitoring. Of course, I could skip the enrolment process entirely and hard-code the credentials into the extension... and the verifier would never know.