Unsere offizielle Quellcode-Analyse – und was sie für heylogin bedeutet

Unser Quellcode ist heylogins Bauplan – mit all seinen Winkeln, Türen, Aufgängen und Räumen. Die Architektur im Hintergrund. Und ihre Architekten sind unsere Programmierer, die tagtäglich alles dafür geben, dass heylogin reibungslos funktioniert, zukunftsfähig und in höchstem Maße sicher ist.

Doch wie jeder Bauplan kann auch der Quellcode in seiner Realisierung Schwachstellen aufweisen. Schwachstellen, die nicht immer auf den ersten Blick erkennbar sind. Manchmal braucht es dafür also ein Team aus Fachkräften, die genau diese wunden Punkte ausfindig machen.

Wir haben unser gesamtes Monorepo (kurz für monolithic repository: eine Zusammenfassung aller Teile des Quellcodes in einem Versionskontrollarchiv) daher im Zeitraum von September bis November 2025 einer Quellcode-Analyse unterzogen.

Durchgeführt wurde diese von der secuvera GmbH – einer vom BSI zertifizierten IT-Sicherheitsdienstleisterin und anerkannten Prüfstelle für IT-Sicherheit mit Sitz in Deutschland.

Der Prüfbericht ergab drei Schwachstellen

secuvera kam im November 2025 zu dem Schluss, dass unser Quellcode lediglich drei Schwachstellen mittlerer Schwere aufwies. Kritische oder gar hohe Schwachstellen blieben aus.

Wir machten uns dementsprechend in den Folgemonaten daran, jene Schwachstellen systematisch zu beheben.

1. Schwachstelle – Hartkodierte Zugangsdaten

Zugangsdaten für interne Betriebs- und Entwicklungswerkzeuge waren direkt in Konfigurationsdateien hinterlegt, statt über Umgebungsvariablen bereitgestellt zu werden.

Konfigurationsdateien

Dies sind Einstellungsdateien, die zusammen mit dem Quellcode abgelegt werden. Die Zugangsdaten sind sozusagen innerhalb des Quellcodes “angeheftet”.

Umgebungsvariablen

Bei diesen werden die Zugangsdaten hingegen separiert aufbewahrt und der Software beim Start “zugeflüstert”.

Bildlich gesprochen: Die Zugangsdaten liegen somit nicht mehr im Bauplan selbst, sondern in einem separaten Tresor, und nur die Maschine, die ihn braucht, bekommt sie im richtigen Moment.

Das Risiko blieb trotz Konfigurationsdateien überschaubar gering, denn ein Angreifer würde Zugriff auf den Quellcode benötigen, um besagte Zugangsdaten überhaupt einzusehen.

Dies berücksichtigte secuvera in der Bewertung mit “Privileges Required: High” (auf Deutsch: “Benötigte Privilegien: Hoch”).

Schlüssel, mit denen sich Kundendaten entschlüsseln ließen, waren nicht darunter und können es architektonisch auch nicht sein: Durch unsere Zero-Knowledge-Architektur liegen diese Schlüssel ausschließlich auf Ihren Geräten und nie auf unseren Servern.

2. Schwachstelle – unsichere postMessage Konfiguration

Unser Passwortmanager unterstützt Sie vor allem als Erweiterung im Browser Ihrer Wahl. Das heylogin-Overlay erscheint, sobald Sie sich in Ihrem Browserfenster auf einer Website einloggen möchten.

Um dies möglich zu machen, müssen unsere Browser-Erweiterung und das Overlay miteinander kommunizieren. Dafür nutzen sie eine eingebaute Funktion des Browsers namens postMessage(). Im Grunde funktioniert dies wie ein digitaler Briefversand.

Laut secuveras Prüfbericht enthielten diese Nachrichten drei Arten von Informationen.

• Fingerprinting: Eine Website hätte die Möglichkeit, zu erfassen, dass Sie heylogin installiert haben. Mehr jedoch auch nicht.
• Client-Parameter: Dies sind die technischen Einstellungen Ihrer Browsererweiterung – etwa, welche Version von heylogin sie nutzt.
• Anwendungszustand: Dieser gibt Auskunft darüber, wo Ihre Browsererweiterung gerade aktiv ist. Zeigt sie beispielsweise gerade ein Login-Fenster an?

Unberührt davon blieben jedoch zu jedem Zeitpunkt Ihre verschlüsselten Daten. Diese wurden durch unsere Zero-Knowledge-Verschlüsselung geschützt.

3. Schwachstelle – Schwache Keychain-Konfiguration unter iOS

Jedes iPhone besitzt einen besonders geschützten Speicherbereich namens Keychain – übersetzt “Schlüsselbund”.

Dort werden Passwörter und andere Anmeldedaten für Ihre genutzten Apps sicher hinterlegt. Jene Apps, auch heylogin, können aus verschiedenen Zugriffsstufen wählen, die von iOS vorgegeben sind.

Wir nutzten im September 2025 noch die Stufe kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly.

Wo ergab sich hier das Problem? “Accessible After First Unlock” bedeutet so viel wie “Zugänglich nach dem ersten Entsperren”. Sobald Sie Ihr iPhone das erste Mal durch Fingerabdruck oder Face ID entsperrt haben, bleibt der “Tresor” des Keychains für heylogin geöffnet.

“This Device Only” wiederum begrenzt die Datenverarbeitung auf Ihr Gerät. Alle Zugangsdaten verbleiben ausschließlich auf Ihrem iPhone.

Es existieren jedoch strengere Zugangsstufen, die den Keychain für heylogin bei jedem Sperren Ihres Gerätes wieder schließen, weshalb die von uns gewählte Stufe als geringfügig unsicherer bemängelt wurde – auch wenn Hacker vor einem tatsächlichen Angriff noch auf diverse andere Hürden treffen würden.

Wir wechselten im Verlauf des letzten Jahres zur Stufe kSecAttrAccessibleWhenUnlockedThisDeviceOnly, welche die Daten nur zugänglich macht, wenn das Gerät im selben Augenblick entsperrt (engl. “Accessible When Unlocked”) ist.

Nach Quellcode-Optimierungen: Ein überragendes Ergebnis

Genau ein Jahr später, im September 2026, veranlassten wir einen Nachtest. Wir hatten bis dato alle genannten Schwachstellen gefixt und den Quellcode optimiert.

secuvera attestiert unserem Quellcode nun ein sehr hohes Sicherheitsniveau – die höchste Stufe im verwendeten Bewertungsschema.

Das offizielle Testat der secuvera GmbH mit seinem Prüfungsergebnis sehen Sie hier:

Unser Fazit

Die Quellcode-Analyse zahlt sich aus, insbesondere um Schwachstellen aufzudecken, bevor sie Außenstehende entdecken. Wir setzen auf hochgradige Sicherheit – für Sie und für uns.

Unsere Architektur – der Quellcode – hat diese Sicherheit nun auch attestiert. Auch wenn das Risiko verschwindend gering blieb und Ihre Daten zu keinem Zeitpunkt zugänglich waren, sind nun auch kleinste Lücken für Angreifer geschlossen.

‍