Der Mensch als Faktor in der Geheimnissicherheit

Veröffentlicht am 6. April 2026 · Lesezeit ca. 6 Minuten

Geheimnisse sind das Fundament digitaler Sicherheit. API-Keys, kryptographische Schlüssel, Passwörter — sie alle schützen Systeme, Daten und Identitäten. Doch was passiert, wenn die Menschen, die diese Geheimnisse verwalten, dabei systematisch scheitern? Diese Frage steht im Zentrum der Dissertation „Human Factors on Secret Security", die 2025 an der Leibniz Universität Hannover im Bereich Informatik eingereicht wurde.

Drei Fallstudien. Drei Arten von Geheimnissen. Ein roter Faden: Entwickler und Nutzer stehen vor Aufgaben, für die es weder ausreichende Werkzeuge noch klare Prozesse gibt.

Code Secrets: Wenn API-Keys im Repository landen

Die erste Fallstudie untersucht, wie Entwickler mit geleakten Zugangsdaten in Quellcode-Repositories umgehen. Die Methodik kombiniert eine Umfrage unter 109 Entwicklern mit 14 vertiefenden Interviews — ein Mixed-Methods-Ansatz, der quantitative Breite mit qualitativen Einblicken verbindet. Die Ergebnisse wurden auf der USENIX Security 2023 präsentiert.

30,3 % der Befragten hatten bereits mit geleakten Code Secrets zu tun. Keine Randerscheinung.

Die Studie deckt Schwachstellen auf allen Ebenen auf: Prävention, Erkennung, Reaktion. Entwickler wissen oft, dass Secrets nicht in den Code gehören — aber die Umsetzung scheitert an fehlenden Automatismen, unklaren Verantwortlichkeiten und dem Zeitdruck des Alltags. Besonders die Risikoeinschätzung nach einem Leak fällt schwer. Wie kritisch ist ein exponierter API-Key? Wurde er bereits missbraucht? Viele können das nicht beantworten.

Ein zentrales Ergebnis betrifft die Werkzeugakzeptanz: Damit Entwickler Secret-Scanner tatsächlich einsetzen, müssen die Adoptionshürden minimal sein. Komplizierte Konfigurationen oder hohe False-Positive-Raten führen dazu, dass Tools schlicht ignoriert werden. Die Studie zeigt, dass der Erfolg von Sicherheitswerkzeugen weniger von deren Erkennungsrate abhängt als davon, wie reibungslos sie sich in bestehende Workflows einfügen.

Kryptographische Updates: Ein jahrelanges Geduldsspiel

Die zweite Fallstudie widmet sich einem Thema, das in der Forschung bisher kaum Beachtung fand: Wie aktualisieren Entwickler kryptographische Komponenten in produktiven Systemen? 21 Interviews mit erfahrenen Entwicklern liefern ein ernüchterndes Bild. Die Ergebnisse werden auf der USENIX Security 2025 vorgestellt.

Strukturierte Prozesse? Gibt es nicht.

Stattdessen herrscht Improvisation. Entwickler stolpern über veraltete Algorithmen, wenn externe Audits darauf hinweisen oder Abhängigkeiten plötzlich Warnungen auslösen. Ein systematisches Monitoring kryptographischer Komponenten existiert in den wenigsten Organisationen. Drei Kernprobleme kristallisieren sich heraus:

• Wissenslücken: Kryptographie ist ein Spezialgebiet. Viele Entwickler wissen zu wenig über die eingesetzten Algorithmen, um fundierte Update-Entscheidungen zu treffen. Welcher Algorithmus ist veraltet? Was ist ein sicherer Ersatz? Solche Fragen bleiben oft unbeantwortet.
• Dokumentationsmängel: Wo welche kryptographischen Primitiven eingesetzt werden, ist selten dokumentiert. Das macht allein die Bestandsaufnahme zum Kraftakt.
• Abwärtskompatibilität: Bestehende Daten müssen weiterhin lesbar bleiben. Verschlüsselte Datenbanken, signierte Dokumente, gespeicherte Tokens — ein kryptographisches Update darf nichts davon zerstören. Dieser Spagat zwischen Sicherheit und Funktionalität ist der Hauptgrund, warum Updates so lange dauern.

Die Zeitspannen sprechen für sich: Manche Updates sind in wenigen Tagen erledigt. Andere ziehen sich über ein Jahrzehnt. Die bevorstehende Post-Quantum-Kryptographie-Migration (PQC) zeichnet sich als besondere Herausforderung ab. Quantencomputer bedrohen etablierte Verfahren wie RSA und ECC, doch die Umstellung auf quantensichere Algorithmen erfordert Änderungen auf allen Ebenen — von der Netzwerkschicht bis zur Datenpersistenz. Ohne klare Migrationspfade und bessere Werkzeuge wird dieser Übergang für viele Organisationen zum Blindflug.

Passwort-Updates: Das Chaos der 111 Websites

Die dritte Fallstudie wechselt die Perspektive. Statt Entwickler zu befragen, analysiert sie die Passwortänderungsprozesse von 111 der meistbesuchten Websites. Fünf Forscher bewerteten die Seiten zwischen September 2024 und Februar 2025 systematisch.

Die Ergebnisse sind frustrierend.

Schon die Navigation zum Passwortänderungsformular gerät zur Herausforderung. Es gibt keine einheitliche Benennung — „Passwort ändern", „Sicherheitseinstellungen", „Konto verwalten", „Anmeldedaten" — jede Plattform erfindet eigene Begriffe. Für Nutzer bedeutet das: suchen statt finden. Für Passwort-Manager und automatisierte Werkzeuge wird die Lage noch schwieriger.

Die Mindestanforderungen an neue Passwörter fallen teils erschreckend niedrig aus. Einige Websites akzeptieren Passwörter ab sechs Zeichen — deutlich unter den NIST-Empfehlungen. Die Erkennung kompromittierter Passwörter existiert praktisch nicht: Nur eine einzige der 111 untersuchten Websites blockierte Passwörter, die in bekannten Datenlecks aufgetaucht waren.

Der W3C-Standard .well-known/change-password, der Browser und Passwort-Manager direkt zur Passwortänderungsseite führen soll, hat kaum Verbreitung gefunden. Und ein weiteres Problem betrifft die Automatisierung: Dynamisch generierte Feldbezeichner (id- und name-Attribute, die sich bei jedem Seitenaufruf ändern) brechen Autofill-Funktionen und Passwort-Manager-Integrationen. Was als Sicherheitsmaßnahme gegen Bots gedacht sein mag, schadet letztlich den Nutzern.

Warum sind Entwickler die zentrale Schwachstelle?

Alle drei Studien zeigen dasselbe Muster aus unterschiedlichen Blickwinkeln. Entwickler stehen im Zentrum sicherheitskritischer Prozesse — und sind dabei systematisch überfordert. Nicht aus Inkompetenz, sondern weil ihnen die richtigen Werkzeuge, Prozesse und Wissensbasis fehlen.

Bei Code Secrets fehlt die Automatisierung. Bei kryptographischen Updates fehlt das Fachwissen. Bei Passwort-Prozessen fehlen die Standards. Drei Domänen, ein Defizit: Die Lücke zwischen Sicherheitsforschung und Entwicklerpraxis.

Usability erweist sich dabei als entscheidender Hebel. Sicherheitsmechanismen setzen sich nur durch, wenn sie sich in bestehende Arbeitsabläufe integrieren lassen, ohne Reibung zu erzeugen. Ein Secret-Scanner, der 90 % der Leaks findet, aber den Build-Prozess um zwei Minuten verlangsamt, wird deaktiviert. Ein kryptographisches Update, das theoretisch sinnvoll ist, aber die Abwärtskompatibilität bricht, wird aufgeschoben. Eine Passwortrichtlinie, die zwar sicher wäre, aber den Nutzer durch ein Labyrinth aus Einstellungsseiten schickt, wird umgangen.

Welche Konsequenzen ergeben sich daraus?

Die Dissertation identifiziert mehrere Handlungsfelder:

Bessere Werkzeuge mit niedrigen Einstiegshürden. Secret-Scanner, kryptographische Inventarisierungstools und standardisierte Passwort-APIs müssen so einfach sein, dass ihre Nutzung weniger Aufwand verursacht als der Verzicht darauf.

Standardisierung. Die fehlende Einheitlichkeit bei Passwortänderungsprozessen zeigt exemplarisch, wie mangelnde Standardisierung Sicherheit untergräbt. Standards wie .well-known/change-password existieren, werden aber nicht adoptiert. Ähnliches gilt für kryptographische Migrationspfade — ohne standardisierte Vorgehensweisen bleibt jedes Update ein Einzelkämpfer-Projekt.

Wissenstransfer zwischen Forschung und Praxis. Die Erkenntnisse der Sicherheitsforschung erreichen Entwickler oft nicht. Wissenschaftliche Publikationen erscheinen auf Konferenzen, aber die Ergebnisse fließen selten in Dokumentationen, Frameworks oder IDE-Plugins ein, wo Entwickler sie tatsächlich wahrnehmen würden.

Organisatorische Verankerung. Weder Secret Management noch kryptographische Wartung dürfen vom Engagement einzelner Entwickler abhängen. Es braucht klare Zuständigkeiten, dokumentierte Prozesse und regelmäßige Überprüfung.

Blick nach vorn

Die PQC-Migration steht bevor, und sie wird die Probleme der zweiten Fallstudie potenzieren. Organisationen, die heute schon nicht wissen, welche kryptographischen Verfahren in ihren Systemen stecken, werden beim Übergang zu quantensicheren Algorithmen massive Schwierigkeiten haben.

Gleichzeitig wachsen die Angriffsflächen. Mehr Code, mehr APIs, mehr Secrets, mehr Möglichkeiten für Leaks. Die Automatisierung der Softwareentwicklung durch KI-gestützte Codegeneratoren könnte das Problem weiter verschärfen — oder Teil der Lösung werden, wenn diese Werkzeuge Sicherheitsaspekte von Anfang an mitdenken.

Die Dissertation liefert die empirische Grundlage für diese Diskussionen. Sie zeigt, wo die Hebel liegen — und dass technische Lösungen allein nicht genügen, solange der menschliche Faktor außer Acht bleibt.

Die vollständige Dissertation ist frei verfügbar: Krause, A. (2025). „Human Factors on Secret Security: Case Studies on Code Secret Leakage, Cryptographic Updates, and Password Update Procedures." Leibniz Universität Hannover.

Dieser Artikel ist eine KI-generierte Zusammenfassung der Dissertation „Human Factors on Secret Security: Case Studies on Code Secret Leakage, Cryptographic Updates, and Password Update Procedures" (Leibniz Universität Hannover, 2025). Die Inhalte wurden redaktionell geprüft.

Sie möchten den menschlichen Faktor in Ihrer IT-Sicherheit stärken? Kontaktieren Sie mich für eine Beratung — von Secret Management über Kryptografie bis hin zu Passwort-Richtlinien.