Gehashte Passwörter erklärt: einfache Passwortsicherheit für Gründer

Warum Passwortsicherheit Ihr Problem wird

Wenn Sie eine App mit Konten betreiben, sind Sie im Passwortgeschäft. In dem Moment, in dem Sie ein Passwort sammeln, halten Sie etwas, das Angreifer wollen und Nutzer erwarten, dass Sie es schützen.

Auch kleine Apps werden angegriffen. Bots scannen das Internet ununterbrochen nach einfachen Zielen: offene Datenbanken, schwache Admin-Konfigurationen, geleakte Environment-Variablen oder Debug-Logs, die versehentlich sensible Daten enthalten. Frühphase heißt nicht sicherer. Meistens bedeutet es, dass weniger Leute ein Problem schnell bemerken und weniger Zeit zum Beheben bleibt.

Wenn Passwörter leaken, verbreitet sich der Schaden über Ihre App hinaus. Menschen wiederverwenden Passwörter, sodass ein Leak zu Einbrüchen in E‑Mail, Bankkonten und anderen Diensten führen kann. Vertrauen kann über Nacht verschwinden, Sie bekommen Chargebacks und verbringen Wochen mit Aufräumarbeiten statt mit Bauen.

Das Ziel ist einfach: Sie sollten niemals in der Lage sein, das Passwort eines Nutzers zu lesen. Weder in Ihrer Datenbank, noch im Admin-Dashboard, noch in einem Support-Ticket und nicht in einer E‑Mail. Deshalb speichern Apps gehashte Passwörter: eine einseitige Version, die beim Login geprüft werden kann, aber nicht zurück in das Originalpasswort verwandelt werden kann.

Passworthandling geht oft auf ganz gewöhnliche Weise schief:

• Passwörter im Klartext speichern, selbst „temporär“ beim Signup
• Passwörter per E‑Mail an Nutzer oder Ihr Team schicken zur Unterstützung
• Signup- oder Login-Anfragen (inklusive Passwörtern) beim Debugging loggen
• Passwörter in Analytics-Tools, Tabellen oder Chats kopieren
• Einen KI-generierten Prototypen ausliefern, der „funktioniert“, aber grundlegende Schutzmaßnahmen auslässt

Ein typisches Szenario: Eine Gründerin testet einen KI-erstellten Prototypen und bittet Nutzer, bei Login-Problemen „mit dem Passwort zu antworten, das sie verwendet haben“. Selbst wenn Sie die E‑Mail später löschen, bleibt sie oft in Postfächern, Backups und Support-Tools bestehen. Die Lösung bedeutet meist, den Auth-Flow so umzubauen, dass Passwörter niemals den richtigen Ort verlassen.

Teams wie FixMyMess sehen dieses Muster häufig bei überstürzten Builds. Der schnellste Gewinn ist, jeden Pfad zu entfernen, bei dem ein Passwort angesehen, kopiert oder wiederverwendet werden könnte.

Was „gehashte Passwörter“ einfach bedeutet

Ein gehashtes Passwort entsteht, wenn Sie ein Passwort durch eine spezielle Funktion laufen lassen, die es in eine lange, zufällig aussehende Zeichenfolge verwandelt. Stellen Sie sich vor, Sie geben Zutaten in einen Mixer und erhalten einen Smoothie. Sie können Smoothies vergleichen, aber die ursprünglichen Erdbeeren nicht zurückholen.

Wenn man sagt „wir speichern gehashte Passwörter“, meint man: Die Datenbank speichert den Smoothie, nicht die Zutaten.

Gespeichert wird üblicherweise ein Datensatz, der das Hash-Ergebnis, die verwendete Methode und zusätzliche Zufälligkeit (oft neben dem Hash gespeichert) enthält.

Hashing ist bewusst einseitig. Wenn jemand Ihre Datenbank stiehlt, sollte er die gespeicherten Werte nicht in echte Passwörter zurückverwandeln können. Auch Sie als App-Betreiber sollten Passwörter nicht lesen können.

Deshalb ist das Verschicken von Passwörtern per E‑Mail ein klares Warnsignal. Wenn Sie es verschicken können, müssen Sie es irgendwo in lesbarer Form gespeichert haben.

Wie funktioniert Login, wenn Sie das Passwort nicht speichern? Beim Login hasht Ihre App das eingegebene Passwort mit derselben Methode und vergleicht das Ergebnis mit dem gespeicherten Hash.

Stimmen die Werte überein, war das Passwort korrekt. Stimmen sie nicht überein, wird der Zugriff verweigert. Niemand muss das Passwort „nachschlagen“.

Wenn Sie einen KI-erstellten App-Code geerbt haben, der Passwörter im Klartext speichert oder sie beim Signup per Mail verschickt, ist das meist schnell zu korrigieren und reduziert vor dem Launch ein großes Risiko.

Hashing vs. Verschlüsselung vs. Encoding (kurzer Vergleich)

Die Begriffe werden oft vermischt, weil sie alle Daten „verändern“. Aber sie haben unterschiedliche Aufgaben, und für Passwörter gilt eine klare Regel: Aus dem Gespeicherten darf das Originalpasswort nicht wiederherstellbar sein.

Hashing ist einseitig. Verschlüsselung ist zweiseitig. Encoding ist nur ein Formatwechsel.

• Hashing verwandelt ein Passwort in eine nicht umkehrbare Zeichenfolge. Beim Login hashen Sie das Eingetippte und vergleichen mit dem gespeicherten Hash.
• Verschlüsselung verschlüsselt Daten so, dass sie mit einem Schlüssel wieder entschlüsselt werden können. Wenn ein Angreifer den Schlüssel stiehlt, kann er die Daten lesen.
• Encoding (Base64, URL-Encoding etc.) macht Daten nur leichter speicher- oder übertragbar. Jeder kann es dekodieren. Es bietet keinerlei Sicherheit.

Wenn Ihr System sagt „wir können es später entschlüsseln“, ist das das falsche Modell für Passwörter. Die Möglichkeit, Passwörter zu entschlüsseln, ist eine Schwachstelle.

Wann Verschlüsselung nützlich ist

Verschlüsselung ist wichtig — nur nicht zur Speicherung von Passwörtern. Nutzen Sie sie für Dinge, die Ihre App später wieder lesen muss, wie API-Keys, Access-Tokens, sensible Nutzerdaten, Backups und Datenübertragungen zwischen Systemen.

Ein einfacher Test: Wenn Ihre App Nutzern „Ihr Passwort ist…“ per E‑Mail schickt, bedeutet das, dass es irgendwo in reversibler Form gespeichert ist. Beheben Sie das vor dem Launch. Ein korrekt aufgebautes System kennt das Originalpasswort nach dem Signup nicht mehr.

Wie Signup und Login funktionieren sollten (Schritt für Schritt)

Ein sicheres Login-System beruht auf einer Regel: Ihre App sollte das echte Passwort des Nutzers nach dem Moment, in dem er es eingibt, nicht mehr kennen müssen.

Sicherer Signup- und Login-Flow

Die meisten modernen Apps folgen einem langweiligen, zuverlässigen Muster:

• Signup: Der Nutzer gibt ein Passwort ein, Ihr Server hasht es und Sie speichern nur den Hash.
• Login: Der Nutzer gibt ein Passwort ein, Ihr Server hasht das Eingetippte gleich und vergleicht es mit dem gespeicherten Hash.
• Ergebnis: Stimmen die Hashes überein, ist der Login erfolgreich. Andernfalls schlägt er fehl. Nichts wird entschlüsselt.

Halten Sie Fehlermeldungen allgemein. Vermeiden Sie Aussagen wie „E‑Mail nicht gefunden“ vs. „falsches Passwort“, denn das hilft Angreifern, gültige Konten zu erraten.

Was niemals in Logs oder Analytics auftauchen darf

Viele Datenlecks beginnen mit „hilfreichem“ Logging. Protokollieren Sie keine Geheimnisse. Dazu gehören Passwörter, Passwort-Hashes, Reset-Tokens, Magic-Links, Session-Tokens, Auth-Header und vollständige Request-Bodies von Auth-Endpunkten.

Nach einem erfolgreichen Login sollten Sie das Passwort nicht weiter verschicken. Der Server erstellt ein Session-Token (eine zufällige Zeichenfolge, die beweist, dass der Nutzer eingeloggt ist) und gibt es an die App zurück. Die App verwendet dieses Token für weitere Anfragen.

Wenn Sie KI-generierten Auth-Code geerbt haben, prüfen Sie, ob er genau diesem Flow folgt. Häufig werden Passwörter geloggt, im Klartext gespeichert oder „zur Fehleranalyse“ an Analytics geschickt. Das sind hochriskante Probleme, die sich meist schnell beheben lassen.

Die richtige Passwort-Hashmethode wählen

Wenn Ihre Datenbank geleakt wird, sollten Angreifer nicht in kurzer Zeit gestohlene Passwort-Hashes in echte Passwörter umwandeln können.

Der Kern ist „langsames Hashing“. Ein guter Passwort-Hash ist absichtlich rechen- oder speicherintensiv. Ihr Server prüft einen Login nach dem anderen. Ein Angreifer probiert Milliarden von Vermutungen. Langsames Hashing schadet Angreifern viel mehr als Ihnen.

Gute Optionen (und warum sie üblich sind)

Die meisten Teams wählen eine bekannte Passwort-Hashmethode:

• Argon2id: moderner Standard, entworfen, um mit GPUs schwer knackbar zu sein.
• bcrypt: älter, weit verbreitet und gut verstanden.
• scrypt: ebenfalls speicherintensiv und eine praktikable Option, wenn Argon2 nicht verfügbar ist.

Wenn Sie kein Sicherheitsexperte sind, ist eine vernünftige Default-Regel: Wählen Sie Argon2id, falls verfügbar, andernfalls bcrypt. Starten Sie mit den empfohlenen Einstellungen der Bibliothek und passen Sie nur an, wenn ein klarer Grund besteht.

Warum SHA-256 ein schlechter Default für Passwörter ist

Allzweck-Hashes wie SHA-256 sind von Haus aus schnell. Das ist gut für File-Checks und Signaturen, aber gefährlich für Passwörter. Schnelle Hashes erlauben Angreifern, riesige Mengen von Vermutungen pro Sekunde zu testen. Auch ein „zweifaches Hashen“ bleibt meist zu schnell.

Eine praktische Regel: Basteln Sie nicht selbst. Verwenden Sie eine bekannte Auth-Bibliothek oder eine vertrauenswürdige Framework-Funktion.

Salts und Peppers ohne Fachchinesisch

Wenn Sie nur eine Sache über gehashte Passwörter behalten, dann diese: Dasselbe Passwort sollte nicht für jeden Nutzer denselben gespeicherten Wert ergeben.

Salt: ein einzigartiges Extra pro Nutzer

Ein Salt ist ein zufälliger Wert, der für jeden Account generiert wird, wenn das Passwort gesetzt wird. Das System mischt Salt und Passwort vor dem Hashen und speichert den Salt neben dem Hash.

Das ist bei einem Datenbank-Leak wichtig. Ohne Salts würden zwei Nutzer mit dem Passwort „Summer2026!“ denselben Hash erhalten. Angreifer erkennen Wiederholungen und können häufige Passwörter schneller erraten.

Mit einzigartigen Salts sehen selbst 1.000 Nutzer mit demselben Passwort alle unterschiedlich gespeicherte Werte.

Pepper: ein Geheimnis außerhalb der Datenbank

Ein Pepper ist ein zusätzlicher Wert, der vor dem Hashen gemischt wird, aber im Gegensatz zum Salt nicht in der Datenbank liegt. Er wird in der Server-Konfiguration gehalten, so dass er auch bei einer exponierten Datenbank geheim bleibt.

Peppers sind nur nützlich, wenn Sie App-Geheimnisse richtig schützen und rotieren können. Sie sind eine zusätzliche Schicht, kein Ersatz für solide Grundmaßnahmen.

Kurze Gründer-Checkliste:

• Salt sollte zufällig und einzigartig pro Nutzer sein und automatisch generiert werden.
• Salt kann zusammen mit dem Hash in der Datenbank gespeichert werden.
• Pepper, falls verwendet, muss außerhalb der Datenbank liegen und wie ein hochsensibles Geheimnis behandelt werden.

Ein häufiger Audit-Fehler in KI-generiertem Auth-Code ist ein hartcodierter „Salt“, der für alle Nutzer gleich ist. Das sieht nach Salting aus, unterläuft aber seinen Zweck.

Häufige Fehler, die sofort technische Schulden erzeugen

Die meisten Passwort-Desaster sind kein „Hacker-Zauber“. Sie entstehen als Abkürzungen bei einem überstürzten Build und werden dann Teil des Produkts und der Support-Gewohnheiten.

Das größte Warnzeichen ist, Passwörter irgendwo im Klartext zu speichern: Datenbank, Tabellen, Admin-Panels, Notizen oder „temporäre“ Tabellen. Wenn jemand es lesen kann, wird es irgendwann geleakt.

Ein weiterer häufiger Fehler ist, Passwörter per E‑Mail oder DM zu verschicken, selbst wenn sie „temporär“ genannt werden. Postfächer werden weitergeleitet, geteilt und über Geräte synchronisiert. Das trainiert Nutzer außerdem darauf, riskante Nachrichten anzunehmen, die wie Ihre Marke aussehen.

Debugging kann dasselbe Problem still und leise erzeugen. Wenn Ihre App während Signup oder Login vollständige Request-Bodies loggt, speichern Sie womöglich Passwörter in Server-Logs, Analytics-Tools, Crash-Reports oder Support-Tickets. Diese Systeme haben oft weiten Zugriff innerhalb eines Teams.

Muster, die schnell Schulden schaffen: lesbare Passwortspeicherung, „Admin kann Nutzerpasswort sehen“-Features, Passwörter beim Testen in Logs drucken, Passwörter in Support-Chats kopieren und Nutzer bitten, ihr Passwort „zur Verifikation“ zu senden.

Eine einfache Regel hilft: Ihre App sollte niemals das Originalpasswort eines Nutzers anzeigen können, weil sie nur gehashte Passwörter speichern sollte.

Wenn Sie Support leisten müssen, setzen Sie auf Tools, die kein Passwort erfordern: Passwort-Reset-Links, redigierte Logs und Tickets sowie Aktionen wie Session-Entzug oder erneutes Senden eines Resets.

Passwort-Resets und grundlegender Schutz, der wirklich funktioniert

Ein „Passwort vergessen“-Flow soll nicht das alte Passwort zurückschicken. Bei gehashten Passwörtern kann der Server nur prüfen, nicht wiederherstellen.

Ein sicherer Reset nutzt ein einmaliges, zeitlich begrenztes Token. Der Nutzer beweist, dass er Zugriff auf die verknüpfte E‑Mail (oder Telefonnummer) hat und setzt dann ein neues Passwort.

Ein Standardablauf sieht so aus:

• Der Nutzer gibt seine E‑Mail ein und fordert einen Reset an.
• Ihre App generiert ein zufälliges Token, speichert nur eine gehashte Version davon und setzt eine Ablaufzeit (z. B. 15–60 Minuten).
• Sie senden eine Reset-Nachricht mit dem Token.
• Wenn der Nutzer das öffnet, verifizieren Sie Token und Ablauf und lassen ihn ein neues Passwort setzen.
• Sie machen das Token nach Gebrauch ungültig und melden optional andere Sessions ab.

Leaken Sie nicht, ob ein Account existiert. Zeigen Sie immer dieselbe Nachricht, z. B.: „Wenn ein Konto für diese E‑Mail existiert, erhalten Sie einen Reset-Link.“ Das verhindert Account-Enumeration-Attacken.

Grundlegende Schutzmaßnahmen müssen nicht fancy sein. Rate-Limiting, kurze Sperren nach wiederholten Fehlern, Nutzerwarnungen bei Resets oder neuen Logins sowie Session-Ablauf nach einem Reset stoppen viele Missbräuche.

In KI-generierten Apps ist ein häufiger Reset-Bug ein Token, das nie abläuft, mehrfach verwendet werden kann oder im Klartext geloggt wird. Kleine Fixes hier verhindern oft schwere Vorfälle.

Praktisches Beispiel: Defekten Auth-Aufbau vor dem Launch reparieren

Eine Solo-Gründerin bringt einen KI-erstellten Prototypen mit einem funktionierenden Login-Formular live. Unter der Haube hat die Datenbanktabelle eine password-Spalte mit dem genauen Passwort-Text. Die App mailt das Passwort beim Signup sogar zurück „damit Nutzer es nicht vergessen“. Das fühlt sich hilfreich an, ist aber gefährlich.

Das Risiko zeigt sich auf normale Weise. Ein Nutzer fragt den Support: „Können Sie mir mein Passwort sagen?“ Jemand öffnet ein Admin-Panel und sieht Passwörter im Klartext. Oder ein Datenbanksnapshot wird an einen Auftragnehmer weitergegeben, und plötzlich haben mehr Leute Zugriff auf echte Passwörter. Manchmal ist es schlimmer: Passwörter landen beim Debugging in Server-Logs.

Die Lösung ist nicht „die Spalte verstecken“. Die Lösung ist das Umstellen auf gehashte Passwörter, sodass das System nur noch einen einseitigen Fingerabdruck des Passworts speichert. In der Praxis heißt das: ein Feld password_hash hinzufügen, Signup so ändern, dass vor dem Speichern gehasht wird, Login so aktualisieren, dass es den Hash verifiziert, Code entfernen, der Passwörter mailt, und Logs säubern, die sie enthalten könnten.

Der Umgang mit bestehenden Nutzern ist der heikle Teil. Die meisten Teams wählen eine der folgenden Optionen:

• Erzwungener Reset: Markieren Sie jedes Konto als reset-pflichtig, senden Sie einen Reset-Link und akzeptieren Sie keine alten Passwörter mehr.
• Schrittweise Umstellung: Behalten Sie das alte Feld vorübergehend, und wenn sich ein Nutzer erfolgreich anmeldet, ersetzen Sie den Klartext durch einen Hash und löschen den Klartext.
• Hybrid: Erzwingen Sie Resets für Admins und hochriskante Accounts, und aktualisieren Sie andere Accounts beim nächsten Login.

Nach der Wahl testen Sie echte Nutzerwege (Signup, Login, Reset, Logout) und bestätigen, dass nichts kaputtgeht.

Ein sicheres Endziel sieht so aus:

• Keine Klartextpasswörter mehr irgendwo (Datenbank, Logs, Admin-Ansichten, E‑Mails).
• Neue Konten speichern nur Hashes; Login verifiziert sicher.
• Reset-Flow funktioniert und verrät nicht, ob eine E‑Mail existiert.
• Alte Passwortdaten werden nach der Migration gelöscht.
• Grundlegende Schutzmaßnahmen sind aktiv (Rate-Limits, Sperren, sichere Fehlermeldungen).

Kurze Checkliste vor dem Launch

Führen Sie diese Prüfungen einmal durch, bevor Sie echte Nutzer einladen. Sie fangen die meisten „Wir wollten das später reparieren“-Passwortprobleme, besonders in schnell gebauten oder mit KI erstellten Apps.

• Datenbank: Bestätigen Sie, dass Sie nur gehashte Passwörter (plus einzigartigen Salt) speichern. Es darf keine Sicherung, „temporäre“ Tabelle oder übriggebliebene Spalte geben, die Klartextpasswörter enthält.
• Logs und Fehlerberichte: Lösen Sie absichtlich einen fehlgeschlagenen Login und einen Signup-Fehler aus und prüfen Sie Request-Logs und Crash-Reports. Passwortfelder müssen redigiert sein.
• Passwort-Reset: Testen Sie den kompletten Reset-Flow. Tokens sollten ablaufen, einmalig sein und nach Passwortänderung ungültig werden.
• Admin- und Support-Tools: Stellen Sie sicher, dass keine interne UI Passwörter anzeigen oder exportieren kann. Wenn ein Support-Screen „aktuelles Passwort“ zeigt, behandeln Sie das als kritischen Bug.
• Geheimnisse und Keys: Scannen Sie Ihr Repo und Ihre Deployment-Einstellungen nach exponierten API-Keys, Datenbank-URLs oder JWT-Secrets. Diese sollten in Environment-Variablen leben, nicht im Code oder in Dashboards, die mit Auftragnehmern geteilt werden.

Ein praktischer Start: Suchen Sie im Code nach password, reset, token, log und debug. Wenn Sie sehen, dass die App ein Passwort speichert, es mailt oder loggt, behandeln Sie es als Stop-Ship-Problem.

Wenn Auth wackelig wirkt (kaputte Resets, exponierte Secrets, seltsames Session-Verhalten), kann ein fokussiertes Audit Sie vor einem Launch-Tag-Problem bewahren.

Nächste Schritte, wenn Ihre App schnell gebaut wurde (oder von KI erstellt wurde)

Wenn Ihre App schnell gebaut wurde, gehen Sie davon aus, dass Authentifizierung und Passworthandling falsch sein könnten, bis das Gegenteil bewiesen ist. Das gilt besonders für KI-generierten Code, in dem oft Passwörter geloggt, im Klartext gespeichert oder beim Testen in E‑Mails kopiert werden. Selbst wenn Sie bereits gehashte Passwörter verwenden, können Fehler bei Resets, Sessions und Geheimnissen Nutzer gefährden.

Ein guter Zeitpunkt für eine externe Prüfung ist kurz vor dem Einladen echter Nutzer, dem Verbinden von Zahlungen oder dem Launch unter einer öffentlichen Domain. Ein weiterer Auslöser ist chaotischer Auth-Code: mehrere Login-Routen, selbstgebaute Kryptographie oder „temporäre“ Admin-Hintertüren, die nie entfernt wurden.

Eine praktische Sicherheitsprüfung umfasst in der Regel:

• Signup, Login, Sessions, Logout und Passwort-Reset
• Secret-Scanning (API-Keys, Datenbank-URLs, Tokens, versehentliche Commits)
• Härtung (Rate-Limits, Sperren, sichere Fehlermeldungen, CSRF-Schutz wo nötig)
• Datenhandhabung (was geloggt, gemailt oder in Analytics gespeichert wird)
• Eine kurze Fix-Liste, priorisiert nach Risiko und Aufwand

Wenn Sie einen fehlerhaften KI-Prototypen geerbt haben, konzentriert sich FixMyMess auf die Diagnose des Codebestands und das Beheben von Problemen wie unsicherer Passwortspeicherung, exponierten Geheimnissen und fragilen Auth-Flows, damit die App produktionsreif wird.

Zeiten können schneller sein, als Sie denken. Viele Projekte lassen sich in 48–72 Stunden diagnostizieren und reparieren, je nachdem wie verflochten die Auth-Logik ist und ob es versteckte Probleme wie exponierte Geheimnisse oder fehlerhafte Autorisierungsprüfungen gibt.

Wenn Sie zwischen Patchen und Neuaufbau entscheiden, nutzen Sie eine einfache Regel: Patchen, wenn die App-Struktur stimmig ist; neu aufbauen, wenn das Fundament instabil ist.

Anzeichen, dass ein Neuaufbau sicherer ist:

• Auth-Logik ist über viele Dateien verteilt und inkonsistent
• Passwort-Reset-Flows sind custom und schwer zu verstehen
• Geheimnisse sind im Frontend oder in der Repo-Historie eingebettet
• Es gibt keine klare Trennung zwischen Nutzern, Rollen und Berechtigungen
• Fixes verursachen ständig neue Fehler in anderen Teilen der App