Webbasierter Passwortmanager zum selbst hosten

[Christian Kruse]

Moin 1UnitedPower,

Oder anders formuliert, das gesamte Schlüsselpaar ist als privat einzustufen.

Auch wenn du rein sachlich recht hast, so spricht man bei symmetrischer Verschlüsselung nicht von einem Schlüsselpaar. Einerseits ist es kein echtes Schlüsselpaar (wie du bereits sagtest, man kann das eine aus dem anderen berechnen) und andererseits ist der Begriff stark mit asymmetrischer Verschlüsselung verknüpft.

Daher dachte ich daran, ein vom Nutzer eingegebenes Passwort zur Ver/Entschlüsselung zu verwenden.

Ein Passwort ist auch nur ein Schlüssel. Der Unterschied ist rein quantitativ. Unter einem Passwort verstehen wir Schlüssel, die sich menschen einfach merken können, oder die sie in akzeptabler Zeit eingeben können. Die Anschauung eines Schlüssel ist insofern etwas offener und lässt auch sehr viel längere Zeichenketten zu. In der Kryptologie spricht oft einfach von einem Geheimnis.

Das ist so nicht ganz richtig. Es existiert (in der modernen Kryptographie) durchaus ein Unterschied zwischen Passwort/Passphrase und Schlüssel (meh, es ist echt schwer die Fachbegriffe ins deutsche zu übersetzen). Der Gedanke dahinter ist, dass bei einer Verschlüsselung alle Schlüssel gleich wahrscheinlich sein müssen, denn sonst kann der Angreifer eine Abkürzung nehmen und die notwendige Arbeit, um den Ciphertext zu brechen signifikant reduzieren. Das wäre der Fall, wenn Passwörter direkt verwendet würden, allein schon durch die unterschiedliche Länge.

Deshalb schicken moderne Verschlüsselungsverfahren das Passwort/die Passphrase durch eine (Hash-)Funktion, deren Ergebnis dann der Key ist.

Weitere Maßnahmen.
Um das ganze noch etwas sicherer zu halten könnte man zum Beispiel ein Cookie auf dem Rechner oder Smartphone setzen das einen Teil des Passworts enthält. Sofern das möglich ist, wenn nur von vorher bekannten Rechnern auf das System zugegriffen werden soll.

Für die eindeutige Identifikation hat man kryptographische Signaturen erfunden. Die sollten für diesen Zweck auch verwendet werden.

Übrigens: moderne Webframeworks verwenden diese Methode, um die Validität eines Session-Cookies sicherzustellen.

Wenn man es noch etwas sicherer halten will, könnte man das Passwort um einen Zufallswert ergänzen, den man bei der Ausgabe selbstverständlich wieder abziehen muss. Z.B. 3 beliebige Zeichen anhängen. Dann hätten gleiche Passwörter verschiedene verschlüsselte Werte, wer die Datenbank sieht kann dann nicht erkennen dass mehrmals das selbe Passwort verwendet wird.

Redest du von Salting? Das ist ein Verfahren, dass man oft in Verbindung mit Hashing benutzt. Bei der Verschlüsselung kann man dadurch afaik die Sicherheit nicht erhöhen.

Das ist halb richtig. Richtig ist, dass man durch Ergänzung des plain texts nichts am Ergebnis ändert. Der cipher text ist (im Idealfall) nicht von Zufall zu unterscheiden. Wenn man zwei mal denselben plain text verschlüsselt, kommt bei modernen Verschlüsselungsvefahren nicht der gleiche cipher text dabei heraus.

Unrichtig ist, dass bei modernen Verschlüsselungsvefahren nicht ein Salting-ähnlicher(!) Mechanismus verwendet wird. Am Beispiel von AES:

Bei AES gibt es mehrere Modi. Für uns interessant ist (und das ist auch mit Abstand der am häufigsten verwendete Modus) der CBC-Modus. Hier wird der plain text in Blöcke zerlegt und jeder Block wird sequentiell verschlüsselt (also erst B1, dann B2, dann B3, …). Der erste Block wird mit einem Input Vector (IV) XORed und dann mit dem Key verschlüsselt. Jeder weitere Block wird mit dem vorherigen XORed und dann auch verschlüsselt. So sieht der cipher text aus wie Zufall.

Bei der Entschlüsselung wird dann der IV wieder gebraucht: zuerst wird der erste Block entschlüsselt und dann mit dem IV wieder XORed. Jeder folgende Block wird entschlüsselt und dann mit dem vorherigen XORed. Wenn also der IV verloren geht, ist maximal der erste Block verloren, jeder weitere kann weiterhin entschlüsselt werden.

Klar, das ist nicht Salting, aber die Mechanismen sind ähnlich.

LG,
 CK