Single Sign On ist in weiten Bereichen immer noch ein frommer Wunsch, und so kommt es, dass immer noch jede neue Anwendung eine Log On Maske benötigt, und zu einer solchen Log On Maske gehört natürlich das Eingabefeld für das Passwort.

Mit dieser Aufgabe befinden sich wohl die allermeisten Entwickler auf ganz dünnem Eis. Wir sprechen von IT-Sicherheit und Verschlüsselung und damit von Dingen die schwer zu verstehen sind und die richtig unangenehm werden, wenn sie schief gehen.

Wie schwierig das zu sein scheint sieht man, wenn man danach googelt.

Denn dort ist zumindest zur Zeit fast nur Blödsinn zu finden, dabei ist eine sinnvolle Lösung oft einfacher, als das was da so vorgeschlagen wird:

1. jBCrypt herunterladen und mit in den Sourcepfad mit aufnehmen
2. Passwort hashen:

   String hashed = BCrypt.hashpw(password, BCrypt.gensalt());

   
   Das Ergebnis dieses Aufrufes kann dann entspannt in der Datenbank oder wo auch immer gespeichert werden.
3. Wenn ein Benutzer sich anmeldet, kann mit folgendem Aufruf, dass eingegebene Passwort überprüft werden:

   if (BCrypt.checkpw(candidate, hashed))
   
       System.out.println("It matches");
   
   else
   
       System.out.println("It does not match");

   
   

Viel einfacher geht es ja nun wirklich nicht. Bleibt noch die Frage:

Warum so und nicht anders?

Ich gehe einfach die Varianten durch, die ich bisher zu Gesicht bekommen habe:

• "Wir müssen die Passwörter nicht verschlüsseln, so wichtig sind die Daten nicht und da kommen ja eh nur interne Mitarbeiter dran."

Na dann lasst die Passwortabfrage ganz weg. Wenn der Benutzer genötigt wird ein Passwort einzugeben, wird er mit großer Wahrscheinlichkeit ein Passwort verwenden, dass er auch wo anders verwendet. Und er wird es im Zweifelsfall nicht witzig finden, wenn der DBA das im Klartext in der Datenbank vor findet.

• Base64 Encoding, ROT13

Man denkt es ist ein Scherz, aber ist es aber leider nicht. Beides sind keine Verschlüsselungsverfahren, bzw. können von einem intelligenten Grundschüler mit Papier und Bleistift "entschlüsselt" werden.

• Echte Verschlüsselungsverfahren (DES, AES ...)

Schon nicht schlecht. Aber haben diese Verfahren haben einen Nachteil: Man kann das Passwort wieder entschlüsseln. Das ist aber gar nicht notwendig, da es reicht beim Login, das eingegebene Passwort auch zu verschlüsseln und das Ergebnis mit dem gespeichertem verschlüsseltem Passwort zu vergleichen. Die Möglichkeit das Passwort wieder zu entschlüsseln stellt nur ein unnötiges Sicherheitsrisiko dar. Verfahren die nicht umkehrbar sind heißen Hash oder Digest.

• MD5

MD5 ist ein solcher Digest. Aber er hat mehrere Probleme. Erstens gilt er seit geraumer Zeit nicht mehr als sonderlich sicher, auch nicht für den Bereich für den er prinzipiell geeignet und gedacht ist, die Signatur von Dokumenten. Zweitens und das ist das Entscheidende: Er ist schnell. Das ist gut, für Server die Dokumente mit Hilfe von MD5 verarbeiten wollen, und es ist gut, für den Angreifer, der eine Liste von verschlüsselten Passworten per Brute Force angreifen will.

Was wir brauchen ist ein langsamer Algorithmus. Der einen solche Brute Force Angriff unmöglich macht. Um einen Algorithmus langsam zu machen gibt es ein einfaches Mittel: Man wendet ihn sehr oft hintereinander an. Es bleibt aber immer noch ein Problem: Sogenannte Rainbowtables. Der Angreifer berechnet einfach für alle möglichen Passwörter bis zu einer gewissen Maximallänge den entsprechenden Hashwert und speichert das Ergebnis in einer Tabelle. Um ein bestimmtes Passwort zu ermitteln muss er nur den Hashwert in der Tabelle nachschlagen. Um dies zu verhindern, muss das Passwort lang genug sein. Um dies sicherzustellen wird es vom Algorithmus zunächst umeine beachtliche Anzahl zusätzliche Zeichen verlängert, bevor es gehasht wird, dies nennt man "salzen". Das Salz wir mit abgespeichert, da sein Wert an sich irrelevant ist und nur dazu dient, dass keine Standard Rainbowtables verwendet werden können, sondern dass jeder Angriffsversuch jedes Passwort einzeln angreifen muss.

Dies haben andere natürlich auch schon wesentlich genauer und auf englisch beschrieben.

Mann kann nun anfangen dies alles selbst zu implementieren. Das sollte nicht so schwierig sein, aber man kann auch einfach einen fertig implementierten Algorithmus nehmen.

Zu guter letzt noch eine Warnung: Ich bin kein Kryptologe oder dergleichen. Ich habe nur ein wenig Internetrecherche betrieben als ich den letzten Log On Dialog gebaut habe. Wenn ihr etwas baut, was wirklich sicherheitskritisch ist, konsultiert jemanden, der sich damit auskennt.