8
Sichere Passwort-Verschlüsselung
Hallo zum Sonntag!
Man liest ja aller Orten, daß MD5 inzwischen nicht mehr sicher ist da es nun Verfahren gibt, einen String zu generieren der den selben MD5-Hash hat wie das originale Passwort. Welche Hash-Funktion (soll am besten destruktiv, also nicht wiederherstellbar sein) ist denn im Moment State of the Art? Idealerweise gibt es Implementierungen für PHP und Pascal-Delphi
Grße
Cody
Man liest ja aller Orten, daß MD5 inzwischen nicht mehr sicher ist da es nun Verfahren gibt, einen String zu generieren der den selben MD5-Hash hat wie das originale Passwort. Welche Hash-Funktion (soll am besten destruktiv, also nicht wiederherstellbar sein) ist denn im Moment State of the Art? Idealerweise gibt es Implementierungen für PHP und Pascal-Delphi
Grße
Cody
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 113254
Url: https://administrator.de/forum/sichere-passwort-verschluesselung-113254.html
Ausgedruckt am: 06.04.2025 um 16:04 Uhr
8 Kommentare
Neuester Kommentar
SHA-256, Whirlpool (wobei es da wenig Praxiserfahrungen gibt),...
Naja - "sicher" ist da so eine sache... Ich würde behaupten das auch MD5 heute noch "State of the Art" ist - je nachdem wo man es verwendet... Grad bei Web-Logins dürfte das heute noch relativ unproblematisch mit MD5 sein - solange es noch genug Datenbanken gibt in denen das Passwort eh im Plain-Text gespeichert wird ... (Was nützt die sicherste Passwort-Verschlüsselung wenn der dämliche Admin das PW im Plain-Text abspeichert und dann mal die ganze DB oder nen Dump davon unerlaubt kopiert wird?)
Ich würde da eher auf ein PHP-Script setzen welches eine Kombination aus der Anzahl der Fehlversuche und der Zeit macht. Einfach die letzten 5-10 Login-Versuche getrennt abspeichern (mit Uhrzeit). Nach dem 3ten Versuch wird min. 1 Min. zwischen jedem weiteren Versuch verlangt, nach dem 6ten Versuch 2 Min, nach dem 9ten 5 Min - und nach dem 12ten wird das ganze erstmal für 30 Min. ruhig gestellt... Dann wird man mit einer solchen String-Attacke nicht weit kommen - da es zu lange dauern würde um den passenden String zu finden...
Ich würde da eher auf ein PHP-Script setzen welches eine Kombination aus der Anzahl der Fehlversuche und der Zeit macht. Einfach die letzten 5-10 Login-Versuche getrennt abspeichern (mit Uhrzeit). Nach dem 3ten Versuch wird min. 1 Min. zwischen jedem weiteren Versuch verlangt, nach dem 6ten Versuch 2 Min, nach dem 9ten 5 Min - und nach dem 12ten wird das ganze erstmal für 30 Min. ruhig gestellt... Dann wird man mit einer solchen String-Attacke nicht weit kommen - da es zu lange dauern würde um den passenden String zu finden...
Vom Prinzip her ist es völlig egal, welche Methode du anwendest, du kannst dir auch eine eigene stricken.
Passwort-Verschlüsselung heißt nicht automatisch SICHERES PASSWORT, sondern heißt nur,
dass ein Passwort verschnickschnackelt abgelegt und nicht wieder ausgelesen
werden kann, und vor allen Dingen nicht ausgelesen werden darf!
Ein sicheres Passwort vergeben kannst du nur selber, indem du es vermeidest,
Namen, Daten, Ereignisse etc. als Passwort zu verwenden, die irgendwie mit
deiner Person, deiner Familie, ja selbst mit deinem Haustier zu tuen haben bzw.
Begriffe, die irgendwo in Wörterbüchern, Lexikas etc. zu finden sind.
Als Beispiel, immer wieder in Thrillern beliebt:
Der "Computerexperte" des F.B.I. sitzt tagelang vor dem sichergestelletem LapTop
eines Verdächtigen. Ergebnis: ACCESS DENIED.
Dann wendet der Experte, Kippe im Mund, Hand an der Kaffeetasse, sich einem Kollegen zu:
"Wie ist der Name seiner Tochter?" Der Kollege:"Melissa". Der Experte tippt Melissa als Passwort
ein, und: OH WUNDER, er hat das Passwort "geknackt" und erfreut sich allgemeiner Bewunderung, die
er allerdings nur der Naiivität des LapTop-Benutzers zu verdanken hat.
Und ob du es glaubst, oder nicht . . . genauso habe ich das Passwort beim Provider meines
ehemaligen Chef's "geknackt".
Ohne böse Absicht habe ich einfach mal versucht, mich mit Domainnamen als Benutzer und Spitzname seiner Frau als Passwort bei
seinem Provider anzumelden. Ergebnis: ACCESS!!! So einfach ist das.
Und genau das machen Algorythmen, die Passworte generieren: Sie verwenden Wörterbücher, Lexikas, persönliche Daten
eines Benutzers etc., verdrehen Buchstaben, Zahlen bekannter Daten solange, bis ein Treffer erzielt wurde: ACCESS!
Nicht die Verschlüsselung, sondern die Wahl des Passworts bietet Sicherheit.
Gruß
Günni
Passwort-Verschlüsselung heißt nicht automatisch SICHERES PASSWORT, sondern heißt nur,
dass ein Passwort verschnickschnackelt abgelegt und nicht wieder ausgelesen
werden kann, und vor allen Dingen nicht ausgelesen werden darf!
Ein sicheres Passwort vergeben kannst du nur selber, indem du es vermeidest,
Namen, Daten, Ereignisse etc. als Passwort zu verwenden, die irgendwie mit
deiner Person, deiner Familie, ja selbst mit deinem Haustier zu tuen haben bzw.
Begriffe, die irgendwo in Wörterbüchern, Lexikas etc. zu finden sind.
Als Beispiel, immer wieder in Thrillern beliebt:
Der "Computerexperte" des F.B.I. sitzt tagelang vor dem sichergestelletem LapTop
eines Verdächtigen. Ergebnis: ACCESS DENIED.
Dann wendet der Experte, Kippe im Mund, Hand an der Kaffeetasse, sich einem Kollegen zu:
"Wie ist der Name seiner Tochter?" Der Kollege:"Melissa". Der Experte tippt Melissa als Passwort
ein, und: OH WUNDER, er hat das Passwort "geknackt" und erfreut sich allgemeiner Bewunderung, die
er allerdings nur der Naiivität des LapTop-Benutzers zu verdanken hat.
Und ob du es glaubst, oder nicht . . . genauso habe ich das Passwort beim Provider meines
ehemaligen Chef's "geknackt".
Ohne böse Absicht habe ich einfach mal versucht, mich mit Domainnamen als Benutzer und Spitzname seiner Frau als Passwort bei
seinem Provider anzumelden. Ergebnis: ACCESS!!! So einfach ist das.
Und genau das machen Algorythmen, die Passworte generieren: Sie verwenden Wörterbücher, Lexikas, persönliche Daten
eines Benutzers etc., verdrehen Buchstaben, Zahlen bekannter Daten solange, bis ein Treffer erzielt wurde: ACCESS!
Nicht die Verschlüsselung, sondern die Wahl des Passworts bietet Sicherheit.
Gruß
Günni
Ich denke ihr geht von einer falschen Annahme aus. Ich habe eine Delphi-Anwendung als Frontend und ein PHP-Script als Backend. Die beiden kommunizieren über das Internet. Meine Sorge sind Man-in-the-Middle-Angriffe, bei denen das recht oft als MD5-Hash übertragene Passwort mitgeschnitten werden kann. Der Angreifer könnte dann mit den gängigen Tools (einschließlich CUDA-Beschleunigung) ein alternatives Plaintext-Passwort mit dem selben MD5-Hash generieren und sich einloggen. Die Stärke vom ursprünglichen Passwort spielt dabei überhaupt keine Rolle, das könnte theoretisch 1000 Zeichen lang sein und wäre bei MD5 immernoch angreifbar.
Darum will ich von MD5 weg und zu einem anderen Verfahren, das noch sicher ist.
Darum will ich von MD5 weg und zu einem anderen Verfahren, das noch sicher ist.
Besteht denn die Möglichkeit einen Tunnel vorher aufzubauen? Denn wenn ich den Passwort-String so mitlesen kann -> was sollte mich daran hindern einfach denselben String nochmal zu übertragen.
Würdest du dagegen vorher einen Tunnel (VPN o.ä.) aufbauen ist das mitschneiden schon generell nicht mehr möglich da ich in den Tunnel nicht reingucken kann...
Würdest du dagegen vorher einen Tunnel (VPN o.ä.) aufbauen ist das mitschneiden schon generell nicht mehr möglich da ich in den Tunnel nicht reingucken kann...
Ich hab auch schon daran gedacht. Ganz so einfach ist es zwar nicht, die Daten einfach nochmal zu schicken, denn da werden Session-Token, MAC-Adressen usw. mit einbezogen aber letztendlich ist das für geübte Hacker kein Problem.
Zwar möchte ich kein VPN einsetzen, denn das würde den Supportaufwand zu sehr erhöhen. Aber die Daten die zwischen meinen Anwendungen ausgetauscht werden könnte ich per Rijndael verschlüsseln.
Generell ist aber das Thema MD5 ein heißes Eisen, siehe http://www.heise.de/security/artikel/121148 Da geht inzwischen einiges in Sachen Dekodierung. Wenn man es genau nimmt ist nicht mehr das Passwort die Schwachstelle sondern der Hash an sich. Denn sobald man Strings erzeugen kann die den selben Hash haben ist es egal, wie das ursprüngliche Passwort aussah.
Zwar möchte ich kein VPN einsetzen, denn das würde den Supportaufwand zu sehr erhöhen. Aber die Daten die zwischen meinen Anwendungen ausgetauscht werden könnte ich per Rijndael verschlüsseln.
Generell ist aber das Thema MD5 ein heißes Eisen, siehe http://www.heise.de/security/artikel/121148 Da geht inzwischen einiges in Sachen Dekodierung. Wenn man es genau nimmt ist nicht mehr das Passwort die Schwachstelle sondern der Hash an sich. Denn sobald man Strings erzeugen kann die den selben Hash haben ist es egal, wie das ursprüngliche Passwort aussah.
Ich find's traurig, dass ich immer ignoriert werde :'(
Abgesehen davon: Bevor du hier die lustigsten Hash-Salt-Konstrukte baust nimmt lieber gleich SSL, dass ist dann auch wirklich sicher (wenn du die Zertifikate auch überprüfst)...
Grüße
Max
Abgesehen davon: Bevor du hier die lustigsten Hash-Salt-Konstrukte baust nimmt lieber gleich SSL, dass ist dann auch wirklich sicher (wenn du die Zertifikate auch überprüfst)...
Grüße
Max
Ups, das war so klein, hab ich übersehen...
nimmt lieber gleich SSL, dass ist dann auch wirklich sicher
(wenn du die Zertifikate auch überprüfst)...
(wenn du die Zertifikate auch überprüfst)...
Wohl wahr aber gar nicht so einfach zu realisieren, SSL mit Delphi-Proggi als Client und Indy 9 als Transport-Lib, das ist ne Menge Coderei bis das stabil läuft.
