Passwortsicherheit in einer Webanwendung

[N8wolf]

@evillive Ja das ist korrekt, würde funktionieren. VBulletin hashed das Passwort zwar vor dem Absenden aber meines Wissens auch nur mit md5.

Natürlich einen Login über einen externen dienst kann man auch machen, ahlte ich aber nciht für den richtigen Weg. Hier muss man z.B. nun ein Ubuntu One Konto besitzen um sich einloggen zu können.
Es gibt ja aber auch OpenID, wobei man einfach die Problematik auf ein anderes Medium verlegt.

LG

 

[p3Eq]

Selbst ein zuvor gehashtes Passwort kann abgefangen und vom Angreifer für einen Login missbraucht werden. Der Angreifer muss schließlich nur dieselben Daten senden wie der User. Je nachdem, ob auch ein Salt für diesen Hash genutzt wird, muss der Angreifer zudem sicherstellen, dass die Anfrage des Users den Server nicht erreicht (denn ggf. könnte sowas wie ein "Sitzungs-Salt" für den Hash genutzt worden sein, der für nur genau eine Anfrage gültig ist).

 

[p3Eq]

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

 

[aNtiCHrist]

Letztendlich vereinfacht man es so doch auch Unbefugten, an den privaten Schlüssel zu kommen. Das Hauptproblem sehe ich eben auch nicht unbedingt in der Portabilität des Schlüssels sondern in dem Schutz des Schlüssels vor unbefugten Zugriffen. Solch ein Gebastel mit Cookies oder DOM Storage und selbst implementierten Authentifizierungsalgorithmenhat hat eben wie erwähnt viele Nachteile. Zudem benötigt man in dem von dir propagierten System neben dem Schlüssel auch noch zwei(!) Passwörter, wobei das System nur so sicher ist wie die beiden Passwörter. Einfacher zu verstehen wird das Verfahren dadurch sicherlich nicht.

Wer den Aufwand durch die Nutzung von Client-Zertifikaten nicht scheut, kann sie auch heute schon ohne solche Bastelei nutzen, für den Rest gibt es eben die Authentifizierung mit die mit einem ausreichend komplexen Passwort, von dem serverseitig lediglich ein Hashwert vorhanden ist, der über einen ineffizienten Hash-Algorithmus bestimmt wurde. Anders als von Tryndamere angenommen, lässt sich solch ein Passwort auch bei Bekanntwerden von Hashwert und Salt eben nicht mit vertretbarem Aufwand ermitteln. Problematisch wird solch ein Verfahren erst dann, wenn entweder signifikante Schwachstellen im Hash-Algorithmus bekannt sind oder aber die verfügbare Rechenleistung enorm angestiegen ist. Dieser Situation kann man natürlich mit komlexeren/besseren Hash-Algorithmen und längeren Passwörtern begegnen, allerdings entsteht mit der steigenden Länge ein immer größeres Problem, sich diese Passwörter auch zu merken. Eine alternative Lösung zu diesem Problem sehe ich in dem von dir beschriebenen Verfahren jedoch auch nicht. Mir stellt sich daher die Frage, wo nun konkret der Vorteil liegen soll, der diesen Aufwand rechtfertigen könnte. Letztlich nutzt du ja offenbar doch wieder ein klassisches Authentifizierungsverfahren mit Passwort, um den privaten Schlüssel abzurufen.