nicht angemeldet
meine Passwortverschlüsselungsidee
3 2 
MudGuard
3
meine Passwortverschlüsselungsidee
Moin,
seit einigen Wochen beschäftige ich mich mit der Sicherheit von Passwort Speicherungen. Um genauer zu sein um das Rekonstruieren eines Passwortes. Früher hat ein MD5 ja gereicht zum Passwort verschlüsseln. Heute gelingt aufgrund der Rechenleistung und Rainbowtabelles das Rekonstruieren eines verschlüsselten Passwortes recht einfach, so dass man am Ende per Klartext das Passwort (oder ein Synonym) sehen und verwenden kann.
Als Lösung wird ein mehrfaches Verschlüsseln per MD5 vorgestellt. In PHP gibt es dazu z.B. die Funktion bcrypt(). Beim verschlüsseln des Passwortes kostet das pro Aufruf ein paar Milisekunden, soll später bei einem Angriff die Zeit des Rekonstruierens sehr hochtreiben.
Und ich stell mir die Frage, wieso so kompliziert? Meine Lösung wäre da etwas einfacher. Ich würde das Passwort per md5 verschlüsseln und diese md5 Stringkette nochmals manipulieren z.B. könnte man den kompletten String einfach umdrehen. Der Angreifer weiß nicht dass der MD5 umgedreht wurde und versucht den umgedrehten md5 zu entschlüsseln. Selbst wenn ihm das gelingt bekommt er nicht das richtige Passwort raus.
Gute Idee?
Gruß
xeR-T
-
Als Lösung wird ein mehrfaches Verschlüsseln per MD5 vorgestellt. In PHP gibt es dazu z.B. die Funktion bcrypt(). Beim verschlüsseln des Passwortes kostet das pro Aufruf ein paar Milisekunden, soll später bei einem Angriff die Zeit des Rekonstruierens sehr hochtreiben.
Und ich stell mir die Frage, wieso so kompliziert?
Weil das im Gegensatz zu MD5 und darauf basierendes Gebastel sicher ist. Standard sind längere salted hashes mit einem sichereren Hash-Algorithmus wie eben Blowfish oder neuere SHA-Versionen. Siehe etwa http://www.openwall.com/phpass/ oder http://net.tutsplus.com/tutorials/php/understanding-hash-functions-and-keeping-passwords-safe/. Etwas besseres wirst du nicht erfinden.
Ich würde das Passwort per md5 verschlüsseln und diese md5 Stringkette nochmals manipulieren z.B. könnte man den kompletten String einfach umdrehen.
Das erhöht die Sicherheit nicht oder nur minimal.
Der Angreifer weiß nicht dass der MD5 umgedreht wurde und versucht den umgedrehten md5 zu entschlüsseln.
Wenn der Angreifer das Know-How hat, um an deine MD5-Hashes zu kommen und einen Angriff gegen diese startet, wird er sich von deiner weiteren winzigen Hürde nicht beeindrucken lassen.
Wenn deine Datenbank kompromittiert wird, ist deine Webanwendung und deren Code wahrscheinlich schon vorher kompromittiert worden.
Lass die Finger von selbstgebauten Methoden, vor allem simple »Security by Obscurity«. Es existieren hinreichend performante und sichere Methoden.
Mathias
-
Wenn der Angreifer das Know-How hat, um an deine MD5-Hashes zu kommen und einen Angriff gegen diese startet, wird er sich von deiner weiteren winzigen Hürde nicht beeindrucken lassen.
Der Angreifer mag vielleicht über technisches Know-How verfügen, aber hellsehen kann er nicht. Er kann doch niemals wissen, dass ich den md5 nochmals manipuliert habe. Selbst wenn er es wissen würde, weiß er noch lange nicht den zweiten Algorithmus. Die einfache Frage die ich mir stelle ist, wieso du so sicher bist, dass das nicht sicher ist?
Gruß
sicherer
T-Rex-
Der Angreifer mag vielleicht über technisches Know-How verfügen, aber hellsehen kann er nicht.
Wie schon gesagt: jemand der deinen Datenbank auslesen kann, hat vermutlich schon dein komplettes System kompromittiert. Alternativ gibt es auch Angreifer aus den eigenen Reihen kommt - oder was ist, wenn du selbst der "Angreifer" bist?
Die einfache Frage die ich mir stelle ist, wieso du so sicher bist, dass das nicht sicher ist?
Weil es hinlänglich bekannt ist, dass Security Through Obscurity nicht funktioniert. Siehe oben.
-
Das ist allerdings ein Argument...
Gruß
Geheimdienstverschlüsselungsparameterzuweiser
T-Rex
-
-
Der Angreifer mag vielleicht über technisches Know-How verfügen, aber hellsehen kann er nicht. Er kann doch niemals wissen, dass ich den md5 nochmals manipuliert habe.
Selbst wenn er nicht deinen Code hat, was wie gesagt unwahrscheinlich ist:
Darauf kommt er doch innerhalb kürzester Zeit. Er sucht nach dem Hash in Rainbow-Tables und findet nur Einträge, die nicht nach üblichen Passworten aussehen. Also schließt er, dass eine Verschleierung oder eine synchrone Verschlüsselung aktiv sein muss, weil er in deiner Datenbank auch keine Salts findet.Dann ist es nur noch eine Frage der Zeit. Er probiert die einfachsten Verschleierungen durch. Vielleicht ist die Spiegelung einer der Verschleierungen, die er ausprobiert.
Mathias
-
Dann ist es nur noch eine Frage der Zeit. Er probiert die einfachsten Verschleierungen durch. Vielleicht ist die Spiegelung einer der Verschleierungen, die er ausprobiert.
Die Spiegelung war ja nur ein Beispiel. Man könnte auch alle Zeichen um eins nach rechts verschieben und das letzte Zeichen nach vorne holen. Und genau hier fängt es an wo man Hellseherische Kräfte haben muss.
Außerdem denke ich kommt man nicht sooo leicht an Quellcode ran. An Datenbankeinträge schon eher. Viele Programmieren für Ihre Mitarbeiter eine schöne XML Schnittstelle, welche die Daten in ein Excelschönes Format transformiert und schwups hat man einen Datenbankexport geöffnet.
Gruß
geht jetzt zum Zug und fährt nach Hause
T-Rex-
Die Spiegelung war ja nur ein Beispiel. Man könnte auch alle Zeichen um eins nach rechts verschieben und das letzte Zeichen nach vorne holen.
Genau das war die Verschleierungsmethode, die mir als zweites eingefallen ist. Hätte ich es besser mal geschrieben, dann hätte ich dir bewiesen, dass ich ein Hellseher bin. ;)
Nein, nein, das ist alles dermaßen trivial, dass jemand, der in deine Webanwendung eingebrochen ist, innerhalb von 20 Minuten deinen Verschleierungsalgorithmus knackt. Solche Techniken findet man in Lernprogrammen, die absolute Anfänger an das Thema Verschlüsselung heranführen sollen. Oder bei Hack-Wettbewerben, wo man Level für Level schwierigere Codes knacken muss. Das wäre dann Level 1.
Mathias
-
Das wäre dann Level 1.
Level 1 ist den Klartext mittels ROT13 zu verschlüsseln oder das Klartextpasswort in der Anmelderoutine (JavaScript) als Variable hinterlegen.
Ein Passwort zu hashen und dann den Hash zu verschleiern ist mindestens Level 2 :p
-
[latex]Mae govannen![/latex]
Das wäre dann Level 1.
Level 1 ist den Klartext mittels ROT13 zu verschlüsseln oder das Klartextpasswort in der Anmelderoutine (JavaScript) als Variable hinterlegen.
Ein Passwort zu hashen und dann den Hash zu verschleiern ist mindestens Level 2 :p
Und ich dachte, Level 2 sei doppelte ROT13-Verschlüsselung...
Stur lächeln und winken, Männer!
Kai--
It all began when I went on a tour, hoping to find some furniture
Followed a sign saying "Beautiful Chest", led to a lady who showed me her best)
SelfHTML-Forum-Stylesheet-
Ein Passwort zu hashen und dann den Hash zu verschleiern ist mindestens Level 2 :p
Und ich dachte, Level 2 sei doppelte ROT13-Verschlüsselung...
Das wird durch meine Aussage ja nicht ausgeschlossen :p
-
-
-
-
Die Spiegelung war ja nur ein Beispiel. Man könnte auch alle Zeichen um eins nach rechts verschieben und das letzte Zeichen nach vorne holen. Und genau hier fängt es an wo man Hellseherische Kräfte haben muss.
Die braucht man nicht, wenn man den Code rankommt :)
Außerdem denke ich kommt man nicht sooo leicht an Quellcode ran.
Ein tolles Argument, wenn du Open-Source-Software verwendest es reicht, einfach mal nachzufragen, wenn man den Quelltext haben will :)
An Datenbankeinträge schon eher.
Ich würde behaupten man kommt leichter an die Scripte als an einen vollständigen Datenbankdump - besonders unter dem Gesichtspunkt, dass viele Systeme einfach auf Open-Source-Software setzen, deren Quelltext öffentlich einsehbar ist.
Viele Programmieren für Ihre Mitarbeiter eine schöne XML Schnittstelle, welche die Daten in ein Excelschönes Format transformiert und schwups hat man einen Datenbankexport geöffnet.
Viele legen die Backups ihrer Datenbank in Form eines SQL-Dumps im DocumentRoot ab.
Wenn du solche Argumente ins Feld führst, kannst du gleich die Daten im Klartext speichern und auf der Startseite als Download verlinken ...
-
Moin Moin!
Außerdem denke ich kommt man nicht sooo leicht an Quellcode ran. An Datenbankeinträge schon eher.
Wie viel Cent möchtest Du darauf wetten?
gzip_cnc hatte mal einen wunderschönen Bug, der sämtliche Sicherungsmaßnahmen des Webservers umging und jede beliebige, für den Webserver-User lesbare Datei an jeden beliebigen Browser liefern konnte, inklusive gzip_cnc selbst, wenn auch GZIP-komprimiert. Daher der dekorative rote Balken am oberen Rand der Seite.
Übrigens können diverse Datenbanken auch Dateien aus dem lokalen Dateisystem einlesen und ihren Inhalt per SQL-Select abliefern. Eine SQL-Injektion-Lücke auf einem System, bei dem Webserver und Datenbank auf der selben (virtuellen oder realen) Maschine laufen, reicht dann unter Umständen aus, um alle Quelltexte *UND* die gesamte DB abzusammeln.
Ach ja, wenn ich mich recht erinnere, kann der MS SQL Server auch von sich aus Mails versenden, gesteuert komplett über SQL. Eine Lücke und Dein Server verschickt selbständig alle Quelltexte und Daten an eine Wegwerf-Mailadresse. Die Lücke muß also gar nicht so groß sein, dass die Daten in einem brauchbaren Format aus der Datenbank bis zum Browser weitergereicht werden, dank Mail-Funktionen geht's auch im Blindflug.
Und ich hab noch nicht einmal angefangen, über Sicherheitslücken im Betriebssystem, in Libraries, im Webserver und im Script-Interpreter nachzudenken.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
-
-
-
-
Tach,
Standard sind längere salted hashes mit einem sichereren Hash-Algorithmus wie eben Blowfish oder neuere SHA-Versionen.
ja, allerdings sollte man auch hier vorallem im Ausblick auf die Zukunft auf spezielle Algorithmen wie das bereits erwähnte bcrypt setzen, die absichtlich langsam sind. SHA, Blowfish und ähnliche Krypto-Hashes sind ausdrücklich für Geschwindigkeit optimiert und deshalb auch für Rainbow-Tables deutlich leichter angreifbar.
mfg
Woodfighter-
ja, allerdings sollte man auch hier vorallem im Ausblick auf die Zukunft auf spezielle Algorithmen wie das bereits erwähnte bcrypt setzen, die absichtlich langsam sind. SHA, Blowfish und ähnliche Krypto-Hashes sind ausdrücklich für Geschwindigkeit optimiert und deshalb auch für Rainbow-Tables deutlich leichter angreifbar.
Die Geschwindigkeit des Algorithmus hat keinen direkten bezug zu Rainbow-Tables. Die sind ja gerade dafür da, das Datenaufkommen und den Zeitaufwand zu minimieren - ob das generieren einer Rainbow-Table jetzt eine Tag oder drei Wochen dauert ist unterm Strich egal.
-
Tach,
Die Geschwindigkeit des Algorithmus hat keinen direkten bezug zu Rainbow-Tables. Die sind ja gerade dafür da, das Datenaufkommen und den Zeitaufwand zu minimieren - ob das generieren einer Rainbow-Table jetzt eine Tag oder drei Wochen dauert ist unterm Strich egal.
ob es auf verteilten Systemen 3 Wochen oder 10 Jahre dauert, macht schon einen erheblichen Unterschied.
mfg
Woodfighter
-
-
-
-
Hi,
seit einigen Wochen beschäftige ich mich mit der Sicherheit von Passwort Speicherungen. Um genauer zu sein um das Rekonstruieren eines Passwortes. Früher hat ein MD5 ja gereicht zum Passwort verschlüsseln.
Nein, MD5 hat noch nie gereicht, um ein Passwort zu verschlüsseln, denn MD5 ist keine Verschlüsselung, sondern eine Hash-Funktion.
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
Früher hat ein MD5 ja gereicht zum Passwort verschlüsseln.
Ein Streuwert/Hash ist keine Verschlüsselung :)
Heute gelingt aufgrund der Rechenleistung und Rainbowtabelles das Rekonstruieren eines verschlüsselten Passwortes recht einfach, so dass man am Ende per Klartext das Passwort (oder ein Synonym) sehen und verwenden kann.
Das hat weniger mit Rechenleistung zu tun sondern eher mit der Tatsache, dass viele Benutzer ein dummes Passwort wählen :)
Als Lösung wird ein mehrfaches Verschlüsseln per MD5 vorgestellt. In PHP gibt es dazu z.B. die Funktion bcrypt(). Beim verschlüsseln des Passwortes kostet das pro Aufruf ein paar Milisekunden, soll später bei einem Angriff die Zeit des Rekonstruierens sehr hochtreiben.
Ja - und zwar signifikant.
Der Angreifer weiß nicht dass der MD5 umgedreht wurde und versucht den umgedrehten md5 zu entschlüsseln. Selbst wenn ihm das gelingt bekommt er nicht das richtige Passwort raus.
Security by Obscurity funktioniert nicht, das sagte molily bereits :)
Weil es für dich als Mensch ggf. "schwer nachzuvollziehen" ist, muss das für einen Computer nicht zutreffen.
http://xkcd.com/936/
http://suit.rebell.at/artikel/passwoerter-richtig-und-sicher-speichern