![\"EU-Flagge\"](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2026\/01\/image-92.png\")
Die EU-Kommission hatte vor einer Woche eine App zur Altersverifikation ver\u00f6ffentlicht. Diese wurde von einem Sicherheits-Konsultant zerlegt und binnen 2 Minuten gehackt. Nun haben die Entwickler eine \u00fcberarbeitete und \"besser abgesicherte\" Version der App nachgereicht. Ob es dieses Mal der perfekte Wurf ist? Oder kann man ein kaputtes Konzept \u00fcberhaupt retten?<\/p>\n
<\/p>\n
Die EU-Kommission die Altersverifikation f\u00fcr den Zugriff auf Internetinhalte durchsetzen, um den Jugendschutz im Internet gew\u00e4hrleisten zu k\u00f6nnen. Dazu hatte die EU eine App zur Altersverifikation entwickeln lassen. Diese Alterspr\u00fcfung soll per App anonym erfolgen k\u00f6nnen \u2013 die App halte die weltweit h\u00f6chsten Datenschutzstandards ein, hie\u00df es k\u00fcrzlich von EU-Kommissionspr\u00e4sidentin von der Leyen bei der Vorstellung.<\/p>\n
Abgesehen vom Umstand, dass vollj\u00e4hrige Dritte den Altersnachweis f\u00fcr die Daten f\u00fcr einen Jugendlichen auf dessen Ger\u00e4t per App bereitstellen k\u00f6nnten, hatte die vorgelegte App haarstr\u00e4ubende Schwachstellen.\u00a0Ein Sicherheits-Konsultant ben\u00f6tigte laut eigenen Angaben knapp zwei Minuten, um die App zu hacken und das Konzept zu zerlegen. Ich hatte einige Details im Blog-Beitrag\u00a0EU-App zur Altersverifikation in 2 Minuten gehackt<\/a> aufbereitet.<\/p>\n Ich bin bereits zum 22. April 2026 auf den Tweet<\/a> von Paul Moore (Security Consultant) gesto\u00dfen. Die EU-Kommission habe ein Update der App auf V2026.04-2 ver\u00f6ffentlicht, dass die Sicherheitsprobleme der ersten Version beheben soll, hei\u00dft es.\u00a0Moore hatte bereits die obigen Sicherheitsprobleme in der ersten App-Version \u00f6ffentlich gemacht. Nun fragt er sich nach einem Blick auf die gepatchte App, ob er lachen oder weinen soll? Er bezeichnet den \"ersten H\u00e4rtungsschritt\" als Sicherheitstheater.<\/p>\n Im Tweet legt er dann los und plaudert aus dem N\u00e4hk\u00e4stchen, was die Entwickler als \"H\u00e4rtungsma\u00dfnahmen\" da abgeliefert haben.<\/p>\n In der revidierten App-Version werden ger\u00e4teinterne Daten, also Datenbank und Einstellungen im Ruhezustand verschl\u00fcsselt. Die Schl\u00fcssel sind sogar durch den hardwaregest\u00fctzten Schl\u00fcsselspeicher des Ger\u00e4ts gesch\u00fctzt. Klingt doch richtig professional, die Entwickler haben verstanden?<\/p>\n Paul Moore st\u00f6ren bei diesem Ansatz nur ein paar Kleinigkeiten – kann man sicher patchen. Es wurden drei Abh\u00e4ngigkeiten zu folgenden Libraries:<\/p>\n benutzt, die laut Moore bereits veraltet seien. Moore meint: Es wurden drei Abh\u00e4ngigkeiten zu veraltete Sicherheitsbibliotheken, nach Kritik an der schwachen Sicherheit der ersten App-Version, neu eingef\u00fchrt. Also keine \u00dcberbleibsel von altem Zeugs, die bei einem Update \u00fcbersehen wurden. Schlimmer noch, meint Moore, die Entwickler h\u00e4tten den KeystoreController<\/em> in ihrem Code bereits korrekt verwendet. Die richtige L\u00f6sung habe es bereits gegeben, und trotzdem h\u00e4tten die Entwickler es falsch gemacht. Ein anderer Nutzer meint in einer Antwort auf X: \"solche Abh\u00e4ngigkeiten sind ein klarer Hinweis auf Vibe-Coding\".<\/p>\n Es wurde bereits in meinem oben erw\u00e4hnten Blog-Beitrag von Lesern in Kommentaren erw\u00e4hnt: Die Manipulation von Konfigurationsdaten in der Version 1.0 der App seit nur bei gerooteten Ger\u00e4ten m\u00f6glich. Haben sich die Entwickler auch gedacht, und der App eine Integrit\u00e4tspr\u00fcfung spendiert. Die App \u00fcberpr\u00fcft beim Start die Integrit\u00e4t des Ger\u00e4ts und weigert sich, auf gerooteten oder jailbroken Ger\u00e4ten zu laufen.<\/p>\n Die Entwickler \u00fcberpr\u00fcfen nach dem Befehl \"su\", suchen im Paketmanager nach Root-Apps, f\u00fchren \"which su\" aus und pr\u00fcfen, ob es sich um ein Custom-ROM handelt, hei\u00dft es von Moore. Der Consultant meint:\u00a0Bei Produktivbereitstellungen sollte dies durch strengere Mechanismen zur Ger\u00e4te\u00fcberpr\u00fcfung erg\u00e4nzt werden, die den jeweiligen Infrastruktur- und Compliance-Anforderungen entsprechen. Im Tweet gibt Moore noch Pfade von Android-Verzeichnissen an, die gepr\u00fcft werden. Im Jahr 2015 sei dies noch sinnvoll gewesen, mein Moore, in 2026 lie\u00dfe sich das leicht umgehen. Also \"wei\u00dfe Salbe\" dr\u00fcber geschmiert.<\/p>\n In der ersten Version blieb der Ausweis zur Altersverifikation bei Fehlern w\u00e4hrend des Scans als .png-Datei auf dem Ger\u00e4t zur\u00fcck. Hier gab es einen echten Fortschritt, das Scannen ist jetzt stabiler, und die Ausweis-Scans werden jetzt ordnungsgem\u00e4\u00df gel\u00f6scht. Das gescannte Passfoto soll, laut Entwickler, vertraulich gespeichert und gel\u00f6scht werden, sobald es nicht mehr ben\u00f6tigt wird. Dummerweise wird das Passfoto immer noch nicht verschl\u00fcsselt auf dem Ger\u00e4t gespeichert, was zur Frage, was \"vertraulich\" bedeutet, f\u00fchrt.<\/p>\n Inzwischen enth\u00e4lt die App strengere Pr\u00fcfregeln, die leicht zu erratende PINs verhindern. PINs werden salted und hashed, und niemals im Klartext gespeichert. Das ist richtig gut, und das Salten wird laut Moore auch korrekt durchgef\u00fchrt (ein echter CSPRNG).<\/p>\n Dummerweise haben die Entwickler dazu PBKDF2-SHA256 verwendet, was veraltet ist und nur empfohlen wird, wenn FIPS-Konformit\u00e4t erforderlich ist, was hier nicht zutrifft, schreibt Moore. Der Consultant erweist sich als echte Spa\u00dfbremse, weilst er doch zus\u00e4tzlich darauf hin, dass die Entwickler im Code nur 210.000 Iterationen verwenden (die OWASP-Empfehlung aus 2023 lautet f\u00fcr Passw\u00f6rter mindestens 600.000 Iterationen zu verwenden). Moore h\u00e4tte erwartet, dass 2026 zumindest ein moderner Hash mit angemessener Brute-Force-Resistenz verwendet wird.<\/p>\n Das Fazit, welches der Sicherheitsexperte zieht: Die \"H\u00e4rtungsma\u00dfnahmen\" seien Sicherheitstheater. Die grunds\u00e4tzlichen Kritikpunkte lassen sich nicht durch Programmcode beheben. Das ganze Vorhaben sei von Grund auf schlecht konzipiert und mangelhaft umgesetzt.<\/p>\n In einem Folge-Tweet<\/a> (siehe obiges Bild) zieht er den Schluss, dass die App-Entwickler, einmal davon abgesehen, dass sie eine sechs Jahre alte, veraltete Bibliothek verwendet haben, das Problem eigentlich \u00fcberhaupt nicht gel\u00f6st h\u00e4tten. Ein Angreifer kann Chiffretext genauso leicht l\u00f6schen wie Klartext. Ironischerweise haben die Entwickler versucht, ein Problem zu l\u00f6sen, das sie nicht wirklich verstehen, \u00e4hnlich wie das Konzept selbst. Also doch Vibe Coding?<\/p>\n Auf X gibt es dann eine Diskussion mit anderen Nutzern, wo Moore schlie\u00dflich den Punkt setzt und meint, dass es nur\u00a0zwei M\u00f6glichkeiten zur L\u00f6sung gibt:<\/p>\n Er meint abschlie\u00dfend, beide M\u00f6glichkeiten scheinen es wert zu sein, daf\u00fcr zu k\u00e4mpfen. Mal schauen, was wird.<\/p>\n","protected":false},"excerpt":{"rendered":" Die EU-Kommission hatte vor einer Woche eine App zur Altersverifikation ver\u00f6ffentlicht. Diese wurde von einem Sicherheits-Konsultant zerlegt und binnen 2 Minuten gehackt. Nun haben die Entwickler eine \u00fcberarbeitete und \"besser abgesicherte\" Version der App nachgereicht. Ob es dieses Mal der … Weiterlesen Neue App-Version, neues Gl\u00fcck?<\/h2>\n
![\"EU](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2026\/04\/EU-Age-App03.jpg\")
<\/a><\/p>\nDaten auf Ger\u00e4t und Einstellungen werden verschl\u00fcsselt<\/h3>\n
\n
Integrit\u00e4t des Ger\u00e4ts wird gepr\u00fcft<\/h3>\n
Ausweis-Onboarding verbessert<\/h3>\n
Strengere PIN-Pr\u00fcfregeln<\/h3>\n
Fazit des Sicherheitsexperten<\/h2>\n
![\"EU-Age-App\"](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2026\/04\/EU-Age-App04.jpg\")
<\/a><\/p>\n\n