Sichere Abfrage Passwort Client -> Server
Hi,
ich möchte für den Login mit Hilfe eines Benutzernamens + Passwort einer Client/ Serveranwendung ein möglichst hohes Maß an Sicherheit erreichen. Alternative Methoden, z.B. mit Zertifikaten, seien hier außen vor gelassen. Als Idee habe ich folgende Möglichkeit ermittelt: Passwort speichern
User authentifizieren
Habe ich etwas übersehen? Viele Grüße |
AW: Sichere Abfrage Passwort Client -> Server
Vorteile:
Mögliche Schwachstellen:
|
AW: Sichere Abfrage Passwort Client -> Server
Wenn du sowieso mit "Hashes" arbeitest, warum nicht gleich einfach MD5 oder SHA1 nehmen? So überträgst du auch nie das Passwort im Klartext und es liegt auch nie im Klartext auf dem Server.
|
AW: Sichere Abfrage Passwort Client -> Server
Zitat:
https://de.wikipedia.org/wiki/Bcrypt Sicher, es wäre möglich das ganze vorher noch mal mit Sha256 / Sha512 zu hashen, aber daraus ergibt sich imho kein wirklicher Gewinn. (Zumal: Bitte heutzutage nicht mehr Passwörter einfach nur als MD5 speichern.. Wenn es etwas aus der SHA Familie sein soll, dann bitte Salted SHA256+) |
AW: Sichere Abfrage Passwort Client -> Server
MD5 und SHA1 sind AFAIK immernoch ungeknackt. Daher ist "höherer Sicherheitsstandard" in dem Fall relativ. Ob du nun was sicheres mit was sicherem vergleichst, es kommt aufs selbe raus.
Ob das aber den erhöhten Mehraufwand (und damit auch wieder Fehleranfälligkeit) einer komplexeren Implementation rechtfertigt, sollte man abklären. Wenn du Attacken durch Trafficmitschnitte befürchtest, dann hilft dir meiner Meinung nach auch kein noch so ausgeklügelter Algorithmus. Dann ist im Vorfeld schon was schiefgelaufen, wenn der Angreifer an eine Stelle kommt, wo er deinen (oder den Server-)Traffic loggen kann. MD5 / SHA1 bieten zwar keinen Schutz gegen simple Replay-Attacken, aber wenn du vorher einen Salt beim Server abfragst, wird das ein findiger Angreifer auch rausfinden. Vielleicht kann man hier auch was mit RSA machen? |
AW: Sichere Abfrage Passwort Client -> Server
Mal was zum Nachdenken: http://www.christian-rehn.de/2012/06...machen-sollte/
Verwende SSL. Alles andere ist Spielkram. Und den Vorschlag md5 für Passwörter zu verwenden, hab ich mal geflissentlich überhört. |
AW: Sichere Abfrage Passwort Client -> Server
Zitat:
|
AW: Sichere Abfrage Passwort Client -> Server
Zitat:
Einziger Verwendungszweck (mit gutem Gewissen) ist m.E. sowas wie Datei-Duplikate finden bzw. in ner Datenbank speichern. Für Passwörter ist von SHA-1 inzwischen auch abzuraten. Das BSI sagt zu Hashfunktionen:: Zitat:
|
AW: Sichere Abfrage Passwort Client -> Server
Die einzig mir bekannte Möglichkeit, um MD5 (oder ähnliches) zu "knacken", ist über Dictionaries oder Bruteforce. Das Problem hat aber jedes System.
Ich will hier keine Diskussion anfangen und zu konservativ klingen. Aber wenn man sagt, MD5 / SHA1 wäre unsicherer als SHA-256 oder ähnliches, impliziert das doch, dass es praktische und zeitnahe Wege und Möglichkeiten gibt, es zu knacken. Oder nicht? Was ist an MD5 unsicherer als an SHA-256, wenn es bis dato (selbst 2015) noch keinem gelungen ist, MD5 (ohne Dictionary) zu reversen? |
AW: Sichere Abfrage Passwort Client -> Server
Zitat:
|
AW: Sichere Abfrage Passwort Client -> Server
Zitat:
|
AW: Sichere Abfrage Passwort Client -> Server
Zitat:
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. |
AW: Sichere Abfrage Passwort Client -> Server
Theorie ist grau und so sieht die Realität aus
http://www.heise.de/newsticker/meldu...e-2811149.html |
AW: Sichere Abfrage Passwort Client -> Server
Zitat:
|
AW: Sichere Abfrage Passwort Client -> Server
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 05:29 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz