Benutzerdaten einer Website - weg von MD5

[cware]

Zitat von negaH:

Zitat:

kurz gesagt: genau das, was bei dem vorgehen, das ich gefunden habe, auch gemacht wird... Laughing
damit ist dein vorgehen also genauso anfällig für MITM wie das andere...

Nenn mir ein Verfahren das absolut betrachtet einer MITMA widerstehen kann !

Gruß Hagen

eben...

(sorry, falls das folgende falsch ist, aber bei deiner beschreibung des vorganges verstehe ich großteilig nur bahnhof, liegt wohl teilweise an den ganzen ein-zeichen-bezeichnern
das problem an der ganzen sache ist: der MITM kann sich einfach zwischen den client und server schalten und die challenge-response-phase mitnutzen...
es sagt ja niemand, dass der MITM sich nach dir nochmal einloggt... er loggt sich einfach ein, wenn du dich einloggst... damit fällt der login-counter schonmal flach... die response zur password-challenge lieferst du automatisch beim login mit...

das wohl interessanteste szenario ist, dass der MITM sich permanent einnistet und sich auf deiner seite als server ausgibt... er könnte z.b. alle passwort-änderungen, etc. mitmachen und sogar deine anfragen an den server weiterleiten und die antworten an dich zurückgeben (allerdings würden die anfragen über die gekaperte verbindung des MITM mit seinen zugangsdaten erfolgen)...
mitkriegen würdest du nicht viel - der counter wird erhöht (das kann sogar der echte server übernehmen) und das passwort wird geändert (das macht der MITM)...
und während du eingeloggt bist (und auch danach) kann der MITM auf dem server arbeiten...
sollte er gerade arbeiten und willst dich neu einloggen, kappt er die verbindung zum server und baut sie gemeinsam mit dir wieder neu auf => der login-counter ist korrekt und alle sind glücklich...


cheers...

[gene]

Hi.

Du könntest es so Formulieren:

Da in letzter Zeit die anfälligkeit der Forensoftware durch Exploits stark angestiegen ist haben wir mit der Sicherheit stark nachgerüstet.
Wir bitten euch euer Passwort zu aktualisieren und somit eure Sicherheit zu gewährleisten.



Oder halt in die Richtung.

[Matze]

Hallo

@gene: Stimmt, das st eine gute Idee.
@alle anderen: Ich lese hier fleißig mit, muss mich aber teilweise genauer mit den angesprochenen Verfahren beschäftigen, da ich diese noch nicht ganz verstanden habe und somit auch nicht sachlich mitreden kann.
Auf jedenfall klingen einige Ansätze vielversprechend.

Diskutiert ruhig weiter, ich finde es sehr interessant.

Grüße

[generic]

Zu eurer Salt Diskusion:
ein MD5 hasht zu einer 128bit Zahl. Also gibt es 2^128 Möglichkeiten.

Wenn ihr einen Salt verwendet, bringt das keinen Unterschieden an den Möglichkeiten was aus dem MD5 rauskommt.

Richtige BF-Angriffe probieren eine Kollision zu finden.
D.h. einen Input welcher nach dem MD5 das gleiche Ergebnis hat.

Somit ist der Salt auch uninteresant, da sowieso das orginal Passwort niemals ermittelt werden kann.

Der Salt verhindert nur eines (wenn diese gut gewählt ist):
Passwörter bestehen im Normalfall auf Zeichen welche über Tastatur eingegeben werden können.
Meist sind Passwörter nur aus Buchstaben (ausgenommen Freaks welche natürlich auch Zahlen und Sonderzeichen verwenden).
Dadurch ergibt sich für ein 0815 Passwort pro Stelle 52 Möglichkeiten (26+26)

Erzeugt man nun eine Rainbowtabelle mit diesen 52 Zeichen pro Stelle is diese Tabelle kleiner als würde man eine Tabelle erzeugen, welche alle Zeichen beinhaltet.
Was ein Vorteil ist.
Diese kleine Rainbowtabelle wird ausgehebelt wenn ihr Salts mit Sonderzeichen verwendet, ggf. auch Zeichen welche NICHT eingebbar sind über Tastatur.
Diese verkürzten Tabelle werden meistens verwendet, um funktionierende Passwörter zu ermitteln.
Größere komplette Tabelle zu erzeugen, verbraucht massig Speicher und massig Zeit.

Wer mal ein einzelnes Passwort aus einen MD5 braucht, für den habe ich noch diesen Link:
http://md5.rednoize.com/

[franktron]

Also wenn ich dies Diskussion richtig verstanden hab dann wollt ihr eine Brutforce Attacke Unterbinden.

Das geht aber nicht durch ändern des Verschlüsslungs Algorithmus des PW in der DB (weil Brute Force ist das egal)

Eine RainbowTabelle hilft dabei zwar das PW schneller zu erlange.

Jetzt zu einer Lösung. Das Problem ist die Eingabe des PW's, Also wie der Hacker die Daten an die DB Schickt da müsst ihr handeln und nicht irgendwelche Algos fürs PW ändern.

[Matze]

Zitat von franktron:

Also wenn ich dies Diskussion richtig verstanden hab dann wollt ihr eine Brutforce Attacke Unterbinden.

Es geht mir nicht darum, die Bruteforce-Attacke auf der Website selbst zu verhindern, sondern darum, dass jemand, der an die Datenbankdaten gekommen ist, anhand der Hashs nicht ohne weiteres auf Passwörter schließen kann.

Bei einem MD5-Hash muss der Angreifer per Bruteforce lediglich alle möglichen MD5-Hashs erzeugen bis dieser mit dem gegebenen Passwort-Hash übereinstimmt. Dann wurde ein gültiges Passwort ermittelt.
Wenn man den Hash allerdings mit einem Salt und ähnlichem erzeugt, dann weiß der Angreifer nicht, wie der Passwort-Hash erzeugt wurde und kann so nicht ohne weiteres per Bruteforce auf ein gültiges Passwort kommen.

Das war zumindets mein Gedanke.

[franktron]

Zitat von Matze:

Zitat von franktron:

Also wenn ich dies Diskussion richtig verstanden hab dann wollt ihr eine Brutforce Attacke Unterbinden.

Es geht mir nicht darum, die Bruteforce-Attacke auf der Website selbst zu verhindern, sondern darum, dass jemand, der an die Datenbankdaten gekommen ist, anhand der Hashs nicht ohne weiteres auf Passwörter schließen kann.

Bei einem MD5-Hash muss der Angreifer per Bruteforce lediglich alle möglichen MD5-Hashs erzeugen bis dieser mit dem gegebenen Passwort-Hash übereinstimmt. Dann wurde ein gültiges Passwort ermittelt.
Wenn man den Hash allerdings mit einem Salt und ähnlichem erzeugt, dann weiß der Angreifer nicht, wie der Passwort-Hash erzeugt wurde und kann so nicht ohne weiteres per Bruteforce auf ein gültiges Passwort kommen.

Das war zumindets mein Gedanke.

Da ist doch was falsch wenn der Angreifer den MD5 für den Login nutzen kann oder ?

Er muss doch Username und PW eingeben.

[negaH]

@Matze:

Stell es dir mal so vor:

Du schützt mit Algorithmus "Fantasy" alle Passwörter und andere Daten deines Systems. Nun sagt dir einer das Fantasy nicht mehr sicher ist, er tritt den Beweis an das er gebrochen werden kann. Du weißt nicht wer in der Zwischenzeit an deine verschlüsselten Daten herangekommen ist. Du must also von der Annahme augehen das Jemand an deine Daten herangekommen ist und du hast es nicht bemerkt. Du kannst nicht von der Annahme ausgehen das keiner an deine Daten rangekommen konnte denn das musst du dann hieb&stichfest beweisen können. Das geht nicht sobald du igrend ein OS benutzt. Du must auch davon ausgehen das Derjenige der deine Daten nun hat auch weiß das Fantasy gebrochen wurde. Du kannst also davon ausgehen das dieser deine Daten hat. Nun: das bedeutet, egal wie du es drehst und wendest:

1.) die User müssen darüber informiert werden das ihre Passwörter unsicher geworden sind
2.) deine System muß einen anderen Schutz benutzen der durch Experten als sicher eingestuft wurde
3.) alle User müssen ein neues Passwort benuten für dein neues System
4.) schlaue User ändern alle Accounts usw. bei denen sie das gleiche Passwort benutzt haben

Nur das macht es sicher. Du kannst da rumdoktorn wie du möchtest es kann nicht sicherer werden, wenn du davon ausgehen musst das der Angreifer schon längst dein System im geheimen geknackt hat, also den Worstcase.

Ein gutes Loginsystem sollte komplett beweisbar anonym arbeiten. Es darf keinerlei Information die einen Zusammenhang zu einem User herstellen könnte ungeschützt gespeichert werden.

Gruß Hagen

[franktron]

Zitat von negaH:

Ein gutes Loginsystem sollte komplett beweisbar anonym arbeiten. Es darf keinerlei Information die einen Zusammenhang zu einem User herstellen könnte ungeschützt gespeichert werden.

Gruß Hagen

Genau das wollte ich auch mit meinem Thread sagen das Loginsystem muss Sicher sein dann ist der PW Algo fast völlig egal.

[Matze]

Hallo Hagen,

so ähnlich hast du das ja bereits geschildert. Ich habe nur die Ausgangssituation nochmals erläutert, um franktron klar zu machen, was ich ursprünglich meinte. Ich hatte ihn so verstanden.
Daher schrieb ich auch, es sind sehr interessante Aspekte erwähnt worden, von denen ich noch gar nicht wusste, dass es sie gibt. Sehr gut gefällt mir vor allem die Methode, das Passwort gar nicht erst zu übertragen. Ob ich das umsetzen kann, sei mal dahingestellt, aber näher auseinandersetzen werde ich mich damit auf jedenfall.