Sichere Abfrage Passwort Client -> Server

[blawen]

Zitat von vagtler:

Zitat von nuclearping:

[...] Was ist an MD5 unsicherer als an SHA-256, wenn es bis dato (selbst 2015) noch keinem gelungen ist, MD5 (ohne Dictionary) zu reversen?

Weil es in üblichen Angriffsszenarien wie Anmeldung normalerweise ausreicht, in endlicher Zeit eine Kollision zu finden.

Üblicherweise endet "endlich" nach 3 Fehlversuchen...

[Martin W]

Zitat von blawen:

Zitat von vagtler:

Zitat von nuclearping:

[...] Was ist an MD5 unsicherer als an SHA-256, wenn es bis dato (selbst 2015) noch keinem gelungen ist, MD5 (ohne Dictionary) zu reversen?

Weil es in üblichen Angriffsszenarien wie Anmeldung normalerweise ausreicht, in endlicher Zeit eine Kollision zu finden.

Üblicherweise endet "endlich" nach 3 Fehlversuchen...

Das mag sein - Anwendungen sollten jedoch so entwickelt werden, dass Daten, insbesondere bei einem Diebstahl, umfassend geschützt sind. Insbesondere wenn es um Passwörter geht, sollte man erwarten können, dass Kundendaten an dieser Stelle bestmöglich geschützt werden. Hier sind insbesondere Anwendungsentwickler in der Pflicht, den aktuellen Stand der Technik zu implementieren.

Der typische Anwender verwendet nicht selten ein Passwort für alle Programme & Services - hier wäre es fatal ein Passwort nur mit MD5 zum hashen. Rainbox-Tables gibt es für MD5 wie Sand am Meer.

Stand der Technik - das sollte Diskussionsgrundlagen sein - ist definitiv nicht mehr MD5 oder SHA1. Auch der Einsatz von zufälligen Salts ist wichtig, denn Usergenerierte Passwörter sind meistens schwach und ähneln sich nicht selten.

Algorithmen wie SHA oder MD5 werden als Standard genutzt, weil sie vor allem eins sind - schnell! Schnell bedeutet aber auch eine gewisse Anfälligkeit gegenüber verschiedenen Arten von Brute-Force Techniken. BCrypt geht den entgegengesetzten Ansatz - der Rechenaufwand ist um einiges höher als bei gängigen Hash-Technologien.

Zurück zum Thema: Wenn ich Anwendungen entwickle, entwerfe ich vor allem sicherheitskritische Teile stets auf Basis eines mehrschichtigen Ansatzes. Rund herum werden zahlreiche andere Techniken eingesetzt, angefangen bei TLS (nicht SSL) für den Transportweg, signierter & verschlüsselter Payload bis hin zu zahlreichen anderen standardisierten Möglichkeiten, Anwendungkommunikation abzusichern. Trotz allem sollte auch die "Klartext-Schicht" bereits "sicher" sein, also einen hohen Sicherheitsstandard bieten.

Dass es keinen Sinn macht, eigene Kryptosysteme zu entwerfen steht außer Frage. Aus diesem Grunde verwende ich nur Technologien, die bereits standardisiert sind. BCrypt ist nichts neues, Salts sind nichts neues, und der Challange-Response-Ansatz ist auch nicht neu.

Aber zum Schluss ist mir ein Statement wichtig: Im Fokus stehen Programmierer, Entwickler. Diese sind dafür verantwortlich, stets einen hohen Standard beim Datenschutz anzulegen. Es sollte in der heutigen Welt selbstverständlich sein, Daten und Informationen ausnahmelos nach dem aktuellen Stand der Technik abzusichern - gerade bei sensiblen Informationen wie Passwörtern.

[Sir Rufo]

Theorie ist grau und so sieht die Realität aus
http://www.heise.de/newsticker/meldu...e-2811149.html

[Martin W]

Zitat von Sir Rufo:

Theorie ist grau und so sieht die Realität aus
http://www.heise.de/newsticker/meldu...e-2811149.html

Deswegen bcrypt Zurück zum Thema, jemand noch Ideen für den Loginablauf? Wie macht ihr es denn normalerweise bei Client-Server-Logins?

[Dejan Vu]

Wie kommt der Server an [Salt 1]? Imho müsste der Client dies bei der erstmaligen Generierung des Hash mit übertragen, d.h. der Server speichert das Tupel [Hash, Salt1].

Dann funktioniert der Rest auch.