Softwareentwickler / Software Developer
Mauspfeil auf einem Button mit der Aufschrift "Security"

Passwörter in einer Datenbank | Alternativen zur Klartext-Speicherung

Möchte man eine Anwendung entwickeln, bei der sich Benutzer anmelden können, muss man sich auch Gedanken darüber machen, wie man diese Passwörter in der Datenbank abspeichern kann. Wie man dies möglichst sicher machen kann, möchte ich in diesem Artikel erläutern.

Dass man Passwörter nicht im Klartext in einer Datenbank ablegen darf, sollte eigentlich jedem klar sein. Eine noch unsichere Variante gibt es logischerweise nicht, ein Angreifer wird sich bedanken.

Verschlüsselung mit einem Schlüssel

Am naheliegendsten wäre es nun, sich einen Schlüssel zu generieren und jedes Passwort mit diesem zu verschlüsseln und dann erst in der Datenbank abzulegen. Problematisch daran wäre nun aber, dass man diesen Schlüssel auch irgendwo ablegen müsste und sobald der Angreifer Zugriff auf die Datenbank hat, könnte auch dieser Schlüssel abgegriffen werden. Außerdem kann nicht unbedingt sichergestellt werden, dass der verwendete Schlüssel tatsächlich lang genug ist, dass eine Entschlüsselung von Dritten nicht möglich ist.

Gehashte Passwörter

Deswegen wäre es wünschenswert, wenn es ein Verfahren gibt, welches diese Sicherheit gewährleistet. Und genau dieses finden man beim Hashen. Diese Verfahren benutzen als Grundlage die Annahme, dass man 127*7843 sehr schnell berechnen kann, es jedoch viel länger dauert, um herauszufinden, welche Zahlen miteinander multipliziert wurden, um die Zahl 996061 zu erhalten. Ein bekanntes und bisher noch sicheres Hash-Verfahren ist SHA-2.

Bei einem selbst erzeugten Schlüssel hätte jemand, der diesen kennt, jederzeit alle Passwörter entschlüsseln können. Diese Möglichkeit besteht nun jetzt nicht mehr. Hash-Verfahren beruhen darauf, dass dieselbe Zeichenkette immer denselben Hash erhält und immer nur eine Richtung möglich ist. Mit heutiger Rechenleistung ist eine Entschlüsselung noch unmöglich. So werden bei einem Login-Versuch nicht die Passwörter verglichen, sondern die jeweiligen Hashes. So ist das Passwort nie im Klartext zu sehen.

Hinzufügen von Salz

Jedoch ist ein Hash-Verfahren noch nicht des Rätsels Lösung. Denn selbst wenn man nun den Hash nicht mehr zurück verwandeln kann, gibt es zwei Probleme. Die Kollisionswahrscheinlichkeit bei guten Hash-Verfahren lässt sich vernachlässigen, also dass zwei verschiedene Zeichenkette in demselben Hash resultieren. Findet man also zwei gleiche Hashen in der Datenbank, kann man sich sicher sein, dass zwei verschiedene Benutzer das gleiche Passwort verwenden.

Hinzu kommt, dass Passwörter trotz Hash ganz einfach abgegriffen werden können. Besteht ein Zugriff auf die Datenbank, kann man die sichtbaren Hashes mit den Hash-Werten von oft genutzten Passwörtern vergleichen, was Recht schnell geht.

Um diesem entgegenzuwirken, fügt man einen sogenannten Salt hinzu. Dieser besteht aus einer für jeden Benutzer zufällig generierten Zeichenkette, die im Klartext zusätzlich zu dem gehashten Passwort in der Datenbank gespeichert wird. Wird nun ein Passwort vergeben oder findet ein Anmeldeversuch statt, so wird zuerst der Salt zu der Eingabe hinzugefügt und erst dann der Hash berechnet. So entstehen auch bei Nutzern mit dem gleichen Passwort unterschiedliche Hash-Werte.

Zwar kann man noch immer für jeden Nutzer überprüfen, ob dieser ein gängiges Passwort benutzt, da der Salt im Klartext zur Verfügung steht. Der Aufwand dafür wird aber sehr viel höher, da nun für jedes bekannte Passwort der Hash mit dem nutzerspezifischen Salt berechnet werden muss und nicht mehr nur ein einziges Mal für die gesamte Datenbank.

Auch Pfeffer darf nicht fehlen

Möchte man noch einen Schritt weitergehen, so ist eine Verfeinerung mit Pfeffer möglich. Der sogenannte Pepper funktioniert dabei grundsätzlich wie der eben beschriebene Salt. Jedoch steht der Pepper nicht in der Datenbank, sondern wird an einem geheimen Ort abgelegt. Zusätzlich zu dem Salt wird auch dieser Wert vor dem Salt der Eingabe hinzugefügt, bevor der Hash berechnet wird. Anstatt für die gesamte Anwendung denselben geheimen Pepper-Wert zu verwenden, ist es auch möglich, für jeden Benutzer einen eigenen Wert zu generieren.

Fazit

Man kann nie eine hundertprozentig sicher sein, dass eine Entschlüsselung nicht doch möglich ist. Befolgt man aber die genannten Schritte, macht man es einem potentiellen Angreifer sehr schwer. Für den Benutzer ist es nun viel sicherer, die Anwendung zu benutzen und selbst bei unberechtigtem Zugriff sind nicht zwingend alle Anmeldedaten in Gefahr. Wichtig zu beachten ist aber, dass eigentlich die ganze Sicherheit auf dem Hash-Verfahren beruht. Und nur weil ein Verfahren heutzutage noch sicher ist, heißt es nicht, dass es sich in Zukunft ändert.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

2 Gedanken zu “Passwörter in einer Datenbank | Alternativen zur Klartext-Speicherung”