Vorab schon einmal Entschuldigung für den Doppelpost! Mir ist gerade nur ein neuer Ansatz für eine Verschlüsselung eingefallen, die im Grunde auf Tryndameres Idee beruht.
Und zwar gehe ich im Folgenden davon aus, dass jeder Nutzer eines Dienstes einen asymmetrisches Schlüsselpaar besitzt. Hier wurde als Hauptargument gegen diesen Ansatz gesagt, dass der Private Key nicht einfach für einen durchschnittlichen User zu handhaben sei, wenn beispielsweise ein Login von einem neuen Gerät durchgeführt werden soll.
Der Gedanke, den ich nun dazu hatte, ist, dass man ja den Private Key ebenfalls online in einer Datenbank speichern kann. Sinnvollerweise nicht im Klartext, sondern verschlüsselt. Ich dachte dabei an einen "sicheren" Schlüssel, der vom Dienst generiert wird und den sich der Nutzer dann neben seinem normalen Kennwort merken muss. Der Private Key wird sowohl mit diesem System-Schlüssel als auch mit dem selbst gewählten Kennwort des Nutzers verschlüsselt.
Ein Login von einem neuen Gerät aus erfordert un lediglich zwei Schlüssel, die immerhin besser zu handhaben sind, als ein (in der Regel) langer Private Key. Ist der Login auf einem Gerät einmal erfolgt, so kann der Private Key als Cookie oder im localStorage gesichert werden (optimalerweise natürlich auch weiterhin zumindest mit dem vom Nutzer selbst gewählten Kennwort verschlüsselt).
Der Angriffspunkte wäre im Falle eines kompromittierten Dienstes, dass ein Brute Force-Angriff auf die Kennwörter des Private Keys durchgeführt werden könnte. Dazu müsste aber neben dem Kennwort des Nutzers entsprechend auch das vom Dienst generierte uns ausreichend "sichere" Kennwort geknackt werden. Da diese beiden Passwörter nicht nacheinander per Brute Force geknackt werden können, ergibt sich daraus ein hoher Rechenaufwand. Geht man von einem Kennwort der Zeichenlänge 16 aus, das vom Dienst generiert wird und die Zeichen a-z, A-Z, 0-9, !, ", §, $, %, &, /, (, ), =, ?, {, [, ], }, ,, ., - und _ nutzt, so gibt es alleine für dieses Kennwort ~3.433.683 Quadrillion Möglichkeiten (1 Quadrillion = 1000^8)*.
Das Kennwort des Nutzers wird in den meisten Fällen wahrscheinlich einen nicht ganz so großen Zeichensatz und eine geringere Länge besitzen. Gehen wir von einem 10-stelligem Kennwort mit dem Zeichensatz a-z, A-Z, 0-9 aus (um ein relativ unsicheres Kennwort als Beispiel zu wählen), so ergeben sich daraus ~218 Billionen Möglichkeiten (1 Billion = 1000^4)**.
Kombiniert sind das dann 7,5 * 10^44 Möglichkeiten***. Das dürfte ein ausreichend sicherer Schutz für den Private Key sein. Angesichts der Tatsache, dass es nun auch nicht allzu häufig vorkommt, dass ein Login auf einem neuen Gerät erfolgen soll, halte ich das vom Dienst generierte Kennwort für zumutbar. Eine Anmerkung zum selbst gewähltem Kennwort noch: Sollten Wörter oder Sätze als Kennwort genutzt werden, so leidet natürlich die Gesamtsicherheit des privaten Schlüssels darunter, da eine Wörterbuch-Attacke deutlich effizienter durchgeführt werden kann. Daher die relativ große Länge des vom Dienst generierten Kennworts, um auch dann noch einen ausreichenden Faktor an Sicherheit zu gewährleisten.
* 3.433.683.820.292.512.484.657.849.089.281
** 218.340.105.584.896
*** 7,4971088786781623836781504145421 * 10^44