Passwortsicherheit in einer Webanwendung

[Tryndamere]

Hallo Leute,

Immer wieder hört man "Portal XY geknackt Datenbank mit Passwörtern geklaut" usw. NAtürlich werden die HAshes mit SALTS gesichert, aber diese sind ja meist auch mit unter dem Diebesgut und damit dürfte die Sicherheit des Salts weg sein.

Das optimale wäre doch, wenn ich als Betreiber doch das Passwort gar nicht kennen würde, aber trotzdem die User verifizieren kann. Dies gibt es ja bereits in der Form von zero knowledge verfahren.
Mir stellt sich die Frage, warum diese nicht für Login Scripts erwendet werden.

Ich als Betreiber kenne nur den Public Key des Users und damit ist bei einem "Hack" die Passwörter der User sicher.

Konkrete Idee:

Init:

User Server
1: -------Account erstell Request-----> //Benutzername wird übergeben, Eingaben geprüft etc
2: User berechnet Private key h(Passwort) (Zahlenwert errechnen
3: User berechnet Public Key
4: -----------sende Public Key------->
5: Server legt den Account an mit {Benutzername,Public Key}

Login dann ganz einfach "das Zero Knowledge Verfahren (z.b. Schnorr)

Vorteile:

1. Login wäre sicher
2. Schutz vor Replay
3. Bei Hack gehen "keine Daten" verloren, da die Sicherheit des Passwortes durch ein hashverfahren + die komplexität des diskrten Log. geschützt

Warum wird dies also nicht verwendet in der Webumgebung?

MfG

 

[Cyperfriend]

Schau mal hier. Meinst du sowas?

 

[Tryndamere]

Ähm nein

Mir geht es um ein anderes Verfahren der Identifikation als zu prüfen InputPW==DBPW

Das hat nichts mir Passworterzeugung oder sonstiges zu tun

 

[aNtiCHrist]

NAtürlich werden die HAshes mit SALTS gesichert, aber diese sind ja meist auch mit unter dem Diebesgut und damit dürfte die Sicherheit des Salts weg sein.

Wie kommst du darauf? Selbst wenn es für alle Konten ein gemeinsames Salt gibt, müsste man zur zur Erhöhung der Effizienz (um die Anzahl der Konten) zunächst passende Rainbow-Tables berechnen. Wird für jedes Konto ein eingenes Salt genutzt, sind Rainbow Tables sogar nutzlos.

Kritisch ist in solch einem Fall eigentlich nur, dass die Passwörter oftmals zu kurz sind bzw. der Hash-Algorithmus zu effizient ist, um die Kürze zu kompensieren.

Das optimale wäre doch, wenn ich als Betreiber doch das Passwort gar nicht kennen würde,

Stimmt, das ist doch bei einer Speicherung als Hash aber auch nicht der Fall. Bei einem sinnvoll gewählten Passwort bzw. einem ausreichend ineffzienten Hash-Algorithmus besteht auch keine realisitische Chance, das Passwort zu erraten.

Vorteile:

1. Login wäre sicher
2. Schutz vor Replay
3. Bei Hack gehen "keine Daten" verloren, da die Sicherheit des Passwortes durch ein hashverfahren + die komplexität des diskrten Log. geschützt

Durchaus korrekt. Als Nachteil würde ich anführen, dass kaum ein Nutzer in der Lage ist, seinen privaten Schlüssel zu exportieren, um ihn z. B. in einem anderen Browser, auf einem anderen Rechner zu nutzen. Auch gibt es AFAIK keine standardisierte Schnittstelle, die man zum Erzeugen von Schlüsselpaaren für ein X.509-Zertifikat nutzen könnte. Zudem stellt sich die Problematik, dass dann zwingend eine SSL-Verbindung möglich sein müsste, bei der das Client-Zertifikat verifiziert wird. Viele bestehende große Systeme werden vermutlich HTTPS-Reverse-Proxys nutzen, die bisher keine solche Authentifizierung durchführen können. Bei kleinen Systemen ohne dedizierten Server hat man hingegen häufig das Problem, dass HTTPS nicht einmal verfügbar ist, bzw. man bei fehlender Kontrolle über die Webserver-Konfiguration eine Client-Authentifizierung auch nicht einrichten kann.

Sicherlich könnte man etwas komplett eigenes entwickeln, aber zum einen stellt sich dann wieder die Frage nach der Sicherheit der Implementierung, zum anderen müsste man dann auch noch selbst eine Möglichkeit zum Exportieren implementieren und dem Nutzer erklären, wie das funktionert. Auch müsste man sicherstellen, dass der private Schlüssel nicht so einfach verloren geht. Die von den Browsern angebotenen Möglichkeiten wie Cookies und DOM Storage bieten das nicht, da ist neben dem Cache dann auch schnell mal der Schlüssel gelscht. Außerdem besteht dort die unschöne Möglichkeit, dass man per Script (also auch XSS) auf den privaten Schlüssel zugreifen kann, bzw. dass er bei Cookies sogar mit jeder Anfrage an den Server gesendet würde. Darüber hinaus würde man mit solch einer Implementierung auch Besucher ohne JavaScript ausschließen.

Da die von dir dargestellten Schwächen der Speicherung von Passwörtern als gesalzene Hashes so nicht vorliegen bzw. auch einfacher zu beheben sind und asymmetrische Kryptografie für den Nutzer eben nicht so einfach zu verstehen ist und serverseitig deutlich aufwändiger zu handhaben wäre, wird die von dir beschriebene Technik vermutlich zumindest in naher Zukunft weiterhin sehr selten bleiben. Es ist allerdings nicht so, dass so etwas überhaupt nicht genutzt wird. Mir fallen z. B. CAcert und StartSSL sein, wo man die Authentifizierung mit einem X.509-Zertifikat durchführen kann. Beide Anbieter sind allerdings auch selbst Zertifizierungsstellen und besitzen somit eh die nötigen Voraussetzungen und das nötige Wissen, um so etwas zu implementieren.

 

[Tryndamere]

Naja Beispiel PHPBB.

Der Salt leigt gleich neben dem Passwort mit MD5 gehashed.

Wenn ich den SALT kenne(Was ich ja tue, wenn der SALT neben den Passwort liegt) kann ich mein Dictonary so verändern, das es für den Eintrag nach PHPBB Manier den Salt an mein Dictonary ransetzt. Nahcdme ich slebst für eine Prüfung "Webhacking Contest" das Admin PW genau so geknackt habe halte ich SALTs nur als kleines "Hindernis".

Mit Tools wie Hashcat bekommt man so ruckzuck das Passwort im Klartext.

Das Beispiel damals war eine imaginäre Bankanwendung die halt mit Absicht offen war.

Naja wie ich oben beschrieben habe, muss kein privater Key exportiert werden, sondern der private Key soll aus dem Passwort errechnet werden.

Ich werde das ganze einfach einmal exemplarisch implementieren und präsentieren (wird vermutlich dann aber noch abgesichert werden usw.).

 

[Kugelfisch]

Wenn ich den SALT kenne(Was ich ja tue, wenn der SALT neben den Passwort liegt) kann ich mein Dictonary so verändern, das es für den Eintrag nach PHPBB Manier den Salt an mein Dictonary ransetzt.

Das ist sicherlich korrekt, allerdings kannst du dann - wie aNtiCHrist bereits erwähnte - keine vorberechneten Rainbow-Tables mehr nutzen, sondern musst direkt eine Dictionary- oder Brute-Force-Attacke durchführen. Dagegen hilft ein gezielt ineffizienter Hash-Algorithmus wie z.B. bcrypt, der dafür sorgt, dass jede Hash-Erzeugung mit signifikantem Rechenaufwand verbunden ist. Zumindest Angriffe auf Hashes nicht-trivialer Passwörter werden so zuverlässig verhindert, sofern der Angreifer nicht eine Möglichkeit findet, den Algorithmus wesentlich effizienter zu implementieren (was bei getesteten und analysierten Verwahren wie bcrypt unwahrscheinlich ist).

Naja wie ich oben beschrieben habe, muss kein privater Key exportiert werden, sondern der private Key soll aus dem Passwort errechnet werden.

Prinzipiell eine interessante Idee, allerdings wird die Implementierung selbst ausserhalb des Browsers nicht trivial sein. Ein entscheidendes Problem ist, dass übliche asymmetrische Verfahren nicht mit beliebigen privaten Schlüsseln umgehen können, so müssen z.B. im Falle von RSA die öffentlichen und privaten Exponenten sowie der Modulus in einem spezifischen Zusammenhang stehen, damit das Verfahren funktioniert. Du wirst demnach nicht trivial einen privaten Schlüssel aus dem Passwort ableiten können, insbesondere nicht einfach das Ergebnis einer Hash-Funktion nutzen können - und selbst wenn du das korrekt implementierst und einen kryptografischen PRNG mit dem Passwort initialisierst, wäre der private Schlüssel bei bekanntem öffentlichem Schlüssel ebenso über einen Brute-Force- oder Wörterbuch-Angriff angreifbar, da das Passwort als einzige Entropiequelle dienen müsste, und dieses in vielen Fällen weit weniger Entropie hat, als der private Schlüssel bei einer ernsthaften Schlüssellänge aufnehmen könnte.

 

[aNtiCHrist]

Mit Tools wie Hashcat bekommt man so ruckzuck das Passwort im Klartext.

Das ist nur dann korrekt, wenn der Hash-Algorithmus zu schnell und damit zu schwach ist (oder das Passwort extrem kurz ist). Prinzipiell ist es nicht einmal problematisch, wenn das Salt bzw. die Salts öffentlich bekannt ist/sind. Es würde einem Angreifer lediglich bei einem einzigen Salt für alle Konten ermöglichen, die Berechnung der Rainbow-Tables vorab durchzuführen.

Naja wie ich oben beschrieben habe, muss kein privater Key exportiert werden, sondern der private Key soll aus dem Passwort errechnet werden.

Stimmt, das hatte ich überlesen. Allerdings ist es wie von Kugelfisch bereits erwähnt auch keine gute Idee, den privaten Schlüssel deterministisch allein aus dem Passwort abzuleiten. Dadurch reduzierst du die Vorteile deines Verfahrens auf den Schutz vor Replay-Angriffen. Das kann man durch die Nutzung von HTTPS aber auch viel einfacher und ohne die anderen erwähnten Nachteile haben.

 

[Tryndamere]

Für Die Berechnung des privaten schlüßels müsste ein passendes Verfahren gewählt werden. Das ist auch der Grund warum ich das Schnorr erwähnt habe, hier ist der private Schlüßel eine beliebige Zahl zwischen 1 und q-1 und muss nicht prim sein. Die Primzahlen in diesem Verfahren sind öffentliche Domainvariablen.

Und ja der Schlüßel wäre "brutforcebar" jedoch gilt hier das selbe wie beim El Gamal Verfahren. Der diskrete Log zu berechnen ist nicht gerade trivial bzw nicht in effizenter Zeit berechenbar.

Das einzige Problem bei der Implementierung ist jedoch, das JS relativ schnell an seine Grenzen stößt mit der größe der Zahlen.

//BTW. ich mach das ganze nicht weil ich glaube das bisherige Verfahren sein "mist" oder so etwas, ich war eigentlich nur neugierig warum man es veruscht auf andere Art und Weiße zu lösen. z.B. Damals beim PSN HAck wurden ja ~80% der PWs enthashed und damit Passwortstudien betrieben. Und wenn meine billige Nvidia 9600 m GT das Passwort (Hallo!Admin!.1234!) (5 fach angewandter md5) mit Salt innerhalb von 2-3 Minuten rauskriegt möchte ich nicht wissen wie effizent das in Grafikkartenclustern geht.

MfG

 

[aNtiCHrist]

Mit "das Schnorr" meinst du die Schnorr-Identifikation? Meine Mathematikkenntnisse reichen leider nicht aus, um das Verfahren vollständig zu verstehen, aber alleine schon die Patentierung dürfte mit ein Grund sein, warum man es nicht für den von dir genannten Zweck verwendet.

Wenn sich zu Passwort-Hashes passende Passwörter finden lassen, liegt das wie erwähnt ganz einfach daran, dass das Passwort entweder zu einfach war, oder die Hash-Funktion zu schnell realisierbar ist. Das ist sowohl für das genannte Passwort als auch für MD5 sicherlich der Fall, da hilft bei einem offenbar wörtbuchgestützten Angriff auch ein geradezu niedlicher Versuch, die Komplexität um den Faktor 5 zu steigern, nichts mehr. Aber versuch mal bcrypt-Hashes auf deiner Grafikkarte zu berechnen ...

 

[Tryndamere]

Ja das Verfahren meinte ich.

Es ist mathematisch gar nicht so schwer bis auf die Bedingung von g.
Es gibt aber auch Abwandlungen vom Schnorr die nicht Patentgeschützt sind(bzw. ich dachte eig das das Patent von Schnorr für eine Verwendung inzwischen offen ist).

Und ja ich werde mal in näherer Zukunft einmal den gleichen Input bei bcrypt verwenden und schauen wie lang er damit braucht.

MfG

 

[Lex]

Ich erinnere mich da an eine Webseite, wo du anhand eines Zertifikates erkannt wirst, das du im Browser haben musst, um die Webseite betreten zu können. Problem nur, ist das Zert weg, is Schluss
mit Lustig, und wie schwer/leicht man heutzutage ein Zert aus einem Browser klauen kann weiß ich nicht direkt, aber das wäre eine Methode, wo der Betreiber selbst das PW nicht kennt, speichert, sondern der User den Key bei
sich hat, und sich damit authentifiziert. Bevor sich einige Programmierer damit jedoch befassen, sollten sie sich zuerst die Themen form-session und input-hijack ansehen. Damit hat man um einiges mehr "risiko" als mit abgelegten
Salts in der Datenbank.

Lg Lex

 

[aNtiCHrist]

Ich erinnere mich da an eine Webseite, wo du anhand eines Zertifikates erkannt wirst, das du im Browser haben musst, um die Webseite betreten zu können.

Ja, so etwas gibt es wie erwähnt durchaus:

Mir fallen z. B. CAcert und StartSSL sein, wo man die Authentifizierung mit einem X.509-Zertifikat durchführen kann. Beide Anbieter sind allerdings auch selbst Zertifizierungsstellen und besitzen somit eh die nötigen Voraussetzungen und das nötige Wissen, um so etwas zu implementieren.

Problem nur, ist das Zert weg, is Schluss mit Lustig

Naja, was ist bei einem Passwort anders? Gut, den Schlüssel wird man sich eher nicht merken können, aber in beiden Fällen gibt es die Möglichkeit, ein neues Passwort bzw. einen neuen Schlüssel festzulegen.

wie schwer/leicht man heutzutage ein Zert aus einem Browser klauen kann weiß ich nicht direkt

Mit einem Keylogger wird man natürlich nicht weiterkommen, aber mit Zugriff auf den laufenden Browser kann man das Zertifikat ganz offiziell exportieren. Möglicherweise Fragt der Browser an der Stelle noch einmal nach dem Masterpasswort, aber da könnte dann der Keylogger wieder ins Spiel kommen.

Bevor sich einige Programmierer damit jedoch befassen, sollten sie sich zuerst die Themen form-session und input-hijack ansehen. Damit hat man um einiges mehr "risiko" als mit abgelegten
Salts in der Datenbank.

Mir ist nicht klar, was du damit genau meinst. Wenn du XSRF und Clickjacking meinst, so stimme ich dir durchaus zu, dass das zumindest für gezielte Angriffen gegenüber einem Angriff auf einen gesalzenen, geeigneten Hash oft der einfachere Weg sein dürfte. Es wird jedenfalls nicht sinnvoll sein, die Authentifizierung selbst so extrem abzusichern, wenn ein Angreifer auch einfach durch Schwachstellen an anderer Stelle Anfragen in dem Authentifizierungskontext an den Server senden kann. Typische Schwachstellen in Webanwendungen und zu ergreifende Gegenmaßnahmen sind unter https://www.owasp.org/index.php/Top_10_2013-Top_10 gelistet. Bevor man die Schwachstellen aus dieser Liste nicht mit guter Sicherheit ausgeschlossen hat, braucht man sich IMHO einer wie hier beschriebenen Authentifizierung nicht zuzuwenden.

 

[evillive]

vom Client wird der Username an den Server geschickt.
Server nutzt nun den öffentlichen Schlüssel vom User zum verschlüsseln von "4+65" (Zufällige Mathe Aufgabe). Geheimtext sieht dann so aus "xyz"
der Client entschlüsselt "xyz" mit seinem privaten Schlüssel und schickt dem Server "69" als Antwort unverschlüsselt zurück

sowas müsste doch mit Ajax problemlos machbar sein

 

[p3Eq]

Diese Methode ist nicht gegen Man in the Middle-Angriffe geschützt. Schaltet sich ein Angreifer zwischen Client und Server, so kann er den verschlüsselten Text des Servers an den Client weiterleiten, jedoch die Antwort vom Client unterdrücken und selbst verschicken, um seine eigene Identität zu verifizieren. Eine Unterscheidung nach IP-Adresse als Gegenmaßnahme ist ungünstig, da sich der Angreifer beispielsweise bei öffentlichen WLANs in die Kommunikation einklinken könnte und die genannte Gegenmaßnahme damit ungültig wird. Oder habe ich den Einsatz von der dir beschriebenen Methode missverstanden?

Prinzipiell sinnvoller fände ich - sofern man etwas Ähnliches wie ein Public Key-Verfahren nutzen möchte -, dass du einen Key für ein symmetrisches Verfahren generierst und per Public Key verschlüsselst und zum Nutzer sendest. Von nun an läuft jede weitere Kommunikation symmetrisch verschlüsselt über diesen Key. Sofern sichergestellt ist, dass kein User dasselbe Key-Paar bekommt, sehe ich hier kein Angrifsszenario (davon ausgehend, dass die Schlüssel schon generiert und sicher übertragen wurden).

 

[N8wolf]

ich glaube nicht das ein man in the middle Attacke besonders effektiv ist.

Ohne Kenntnis des privaten Schlüßels, der ja am Client leigen soll in Form des passwortes kann der Angreifer sich ncht verifizieren. Das ist ja der Sinn und zweck eines solchen Verfahrens, denn der Schlüßelaustausch war ja schon bei Accountanlegung.

Das ist ja der Trick bei asynchroner Kryptographie.

 

[p3Eq]

N8wolf, mein Post bezog sich auf die Idee von evillive. Dort soll scheinbar eine Verifizierung stattfinden, indem der Server verschlüsselte Botschaften an den Clienten sendet und dieser antwortet mit der unverschlüsselten Botschaft, um zu zeigen, dass er den zugehörigen Private Key besitzt (mit dem die verschlüsselte Botschaft wieder entschlüsselt werden kann). Diese Antwort ist evillives Idee zufolge unverschlüsselt - d.h. weder signiert, noch verschlüsselt. An dieser Stelle wäre ein Man in the Middle-Angriff also möglich, um zumindest die Verifizierung zu verfälschen. Die weitere Übertragung von verschlüsselten Botschaften ist davon natürlich nicht betroffen, sofern nicht durch andere Gegebenheiten der Angreifer an den Private Key kommt, oder aber eine andere Verschlüsselung für die Kommunikation verwendet wird (asymmetrische Verfahren sind sehr rechenlastig - daher empfiehlt es sich, rechtzeitig zu einem symmetrischem Verfahren zu wechseln, dessen Schlüssel nur für eine Sitzung gültig ist und mittels asymmetrischen Verfahren ausgetauscht wird.

 

[N8wolf]

ja korrekt, die Methote evillive st natürlich nciht sicher gegen einen Man in the Middle Angriff.
Ich dachte du beziehst dich auf die Startidee

Tut mir leid für die "Unterstellung"/Missverständnis.

MfG

 

[evillive]

wieso ist meine idee nicht sicher?

öffentlicher Schlüssel = public Key


Server verschlüsselt mit public Key vom User
nun kann nur mit dem privat Key des Users die Entschlüsselung erfolgen ...


von mir aus ist auch die Antwort vom Client an den Server verschlüsselt.. aber wenn man https verwendet... dann sind die Nachrichten doch sowieso verschlüsselt.

 

[p3Eq]

Server verschlüsselt mit public Key vom User
nun kann nur mit dem privat Key des Users die Entschlüsselung erfolgen ...

Das ist soweit richtig. Der Angreifer kann daher auch nicht die Nachricht mitlesen, die der Server an den Client sendet.

von mir aus ist auch die Antwort vom Client an den Server verschlüsselt..

Genau das ist nämlich wichtig: Würde die Antwort nicht verschlüsselt werden, so könnte ein Angreifer, der zwischen Client und Server geschaltet ist, die Antwort vom Client unterdrücken und selbst die Antwort senden. Ist die Antwort jedoch auch verschlüsselt (beispielsweise über den Public Key des Servers oder einen Key, der zuvor verschlüsselt vom Server zum Client gesendet wurde), dann sehe ich kein Angriffsszenario (davon ausgehend, dass die Schlüsselgenerierung "sicher" ist).

aber wenn man https verwendet... dann sind die Nachrichten doch sowieso verschlüsselt.

Ja und nein. Die Nachrichten sind nur dann wirklich "sicher", wenn das Zertifikat für die SSL-Verbindung echt ist. Sollte ein Angreifer mittels eines Man in the Middle-Angriffs und optional eines gefälschten Zertifikats sich selbst zwischen Client und Server schalten, so können alle Nachrichten mitgelesen werden. Ohne ein gefälschtes Zertifikat würde der Nutzer im Browser eine Sicherheitswarnung angezeigt bekommen - doch wer keine Ahnung von Technik hat, wird in den meisten Fällen die Warnung ignorieren.

 

[evillive]

ja du hast recht.. eigentlich ging es ja primär um Passwörter in der Datenbank bzw. keine mehr dort zu speichern. http://www.heise.de/open/meldung/Ubuntu-Foren-nach-Einbruchanalyse-wieder-Online-1927074.html -- hier haben die jetzt auch keine PWs mehr in der DB, weil der Login bei Ubuntu One erfolgt.

Wenn du dich bei ngb.to einloggst dann kann man auch einen MITM-Angriff machen um an das Passwort zu kommen