Wie wir Ihre Passwörter schützen

In den vorherigen Artikeln haben wir erkundet, wie HTTPS den Weg zwischen Ihrer App und unserem Server schützt und wie SSH den Server selbst absichert. Jetzt ist es an der Zeit, einen Blick in den Server zu werfen – darauf, wie Splync Ihr Passwort sicher aufbewahrt, sobald es dort angekommen ist. Wenn jemand Ihr Passwort erlangen würde, könnte diese Person sich in Ihr Konto einloggen und auf vertrauliche Informationen zugreifen, einschließlich Ihrer Ausgabenaufzeichnungen. Deshalb speichert Splync Passwörter nie im Klartext. Stattdessen wird jedes Passwort in eine gehashte Version umgewandelt, bevor es in der Datenbank gespeichert wird. Was bedeutet das genau? Hashing ist eine Einwegkonvertierung – einmal transformiert, kann es nie wieder in das ursprüngliche Passwort zurückverwandelt werden. Diese Methode ist im Internet Standard, von Banken bis hin zu großen Cloud-Diensten, dennoch wissen viele Menschen nicht, wie sie tatsächlich funktioniert. Lassen Sie uns dies durch ein einfaches Alltagsbeispiel erkunden.

Um zu verstehen, wie Passwortschutz funktioniert, beginnen wir mit einer einfachen Hashing-Methode namens SHA-256. Stellen Sie sich das wie einen Mixer vor, der die Zutaten immer auf die gleiche Weise mixt. Wenn Sie dasselbe Passwort in den Mixer geben und den Knopf drücken, erhalten Sie immer denselben einzigartigen Smoothie – ein wirres Gemisch aus Buchstaben und Zahlen. Der Schlüsselgedanke ist, dass der Vorgang nicht rückgängig gemacht werden kann. So wie Sie einen Smoothie nicht wieder in die ursprüngliche Banane und Milch trennen können, können Sie den wirren Hash nicht zurück in das ursprüngliche Passwort umwandeln.

SHA-256 ist eines der gängigsten Hashing-Algorithmen. Zum Beispiel hashiert es das Passwort "splync1234" in „9cdafa20d069ecfb202e5f0bc937c73071cc6cd85634cc2d95d30ddcf2a71d41“. In Millisekunden erzeugt SHA-256 jedes Mal, wenn ein bestehender Benutzer ein Anmeldepasswort eingibt, dasselbe gehashte Passwort. Die App hashiert das eingegebene Passwort einfach erneut und überprüft, ob es mit dem gespeicherten Hash übereinstimmt. Zu keinem Zeitpunkt kennt das System das ursprüngliche Passwort des Benutzers. Aber was, wenn ein Angreifer eine Liste gängiger Passwörter und deren Hashes (bekannt als Rainbow-Table-Angriff) vorab berechnet, um schnell die Passwörter der Benutzer zu erraten? Diese Sorge ist sehr real. Deshalb verlassen sich moderne Systeme, einschließlich Splync, nicht auf einfaches SHA-256.

Bcrypt verwendet ein zufälliges, benutzerspezifisches Salt und kodiert dieses Salt (und den Kostenfaktor) direkt im gespeicherten Hash-String. Stellen Sie sich bcrypt wie einen Mixer mit einem geheimen Gewürz (Salt) und einem langsamen Motor (Arbeitsfaktor) vor – er macht jeden Mix einzigartig und schwerer zu kopieren. Da das Salt 128 Bit (≈3×10³⁸ Möglichkeiten) hat, kann dasselbe Passwort auf eine astronomisch große Anzahl unterschiedlicher gespeicherter Hashes abgebildet werden. Dadurch werden vorab berechnete Rainbow-Tabellen im großen Maßstab nutzlos. Beim Login liest Splync das Salt und die Kosten aus dem gespeicherten bcrypt-String, führt bcrypt mit diesen Parametern erneut auf das eingegebene Passwort aus und vergleicht das Ergebnis mit dem gespeicherten Hash. Wenn sie übereinstimmen, ist das Passwort korrekt – aber weil bcrypt absichtlich langsam ist und Salts einzigartig sind, werden Brute-Force-Angriffe für einen Angreifer weitaus kostspieliger.

Schauen wir uns an, wie das in der Praxis aussieht. Wenn Sie das Passwort "splync1234" mit bcrypt (bei Kosten 12) hashen, erhalten Sie möglicherweise einen String wie diesen: `$2b$12$gBeouKYdue9uvvuV0HtGgeVPymnrojMqP/wcRw28HFlGEGIQbyw7O`. In diesem bcrypt-String markiert `$2b` die Algorithmus-Version, `$12` zeigt den Kostenfaktor (wie oft das Passwort verarbeitet wird), `gBeouKYdue9uvvuV0HtGgeV` ist das einzigartige zufällige Salt und `PymnrojMqP/wcRw28HFlGEGIQbyw7O` ist das endgültige gehashte Passwort. Da der Hash selbst das Salt und die Kosten enthält, kann Splync denselben Hashing-Prozess zur Verifizierung reproduzieren, indem es diese Werte aus dem gespeicherten String extrahiert und das Ergebnis vergleicht. Andererseits, wenn ein Angreifer das Salt und die Kosten nicht kennt, kann er keine einzige Rainbow-Table erstellen, die für jeden Benutzer funktioniert.

Dieser Ansatz hat einen weiteren wichtigen Vorteil. Da Splync keine Klartext-Passwörter speichert, sind Benutzer auch dann nicht sofort gefährdet, wenn die Datenbank geleakt oder gestohlen wird. Angreifer können sich nicht direkt mit den gestohlenen Daten einloggen, da sie nur wirre Zeichenfolgen haben. Dieses Design bietet den Benutzern eine zusätzliche Schutzschicht, zusätzlich zu den bereits vorhandenen Schutzmaßnahmen rund um den Server selbst. Passwort-Hashing ist nicht einzigartig für Splync; es ist der Standard in der Technologiebranche und wird von Giganten wie Google, Apple und Amazon verwendet. Splync wurde sehr sicher entwickelt und wird immer sicherer, da wir die Sicherheit mit Funktionen wie E-Mail-Verifizierung, Brute-Force-Schutz und kontinuierlicher Überwachung weiter verbessern.