Passwörter sicher speichern.

Klar - als Hash. Nun soll es ja solche Regenbogentabellen geben, die anhand eines md5-hashes vielleicht eine Möglichkeit zeigen, was das Passwort sein könnte.
Nun hab ich mir gedacht, um dem vorzubeugen:

Warum nicht das Passwort einmal md5-gehasht, einmal sha1-gehasht und einmal die Länge des originalen Passwortes speichern und dann alle 3 Werte miteinander vergleichen?
Sicherer ist es auf jeden Fall. Vorausgesetzt das Passwort ist nicht irgendwie "###" oder s n' Quatsch.
Aber sinnvoll? Oder ist es wie mit ner Kanone auf Tauben schiessen? Und ist die Wahrscheinlichkeit, dass jemand einen identischen md5-hash (oder sha1) findet so gering, dass es keinen nennenswerten Nutzen macht?

Edit:
Vielleicht etwas "genauer" erklärt was ich will:

$pwd = $_POST['password'];

if(md5($pwd) === $row['pwd_md5'] AND sha1($pwd) === $row['pwd_sha1'] AND strlen($pwd) === intval($row['pwd_len'])) {

  do_login($uname);

}

else {

  do_error();

}

naja, um genau zu sein machst du es dem angreifer nur noch VIEL einfacher.
denn um den hash knacken zu können, muss man den hash kennen. also hat er im normalfall schon den zugriff auf deine db. wenn er nun auch noch die länge des passworts kennt, was du ja auch speicherst, ist es um vieles einfacher, das passwort zu knacken...

Was immer ganz gut ist, wenn man das Paswort erweitert.

Anstelle von "hallo123" wird daraus der Wert "hallo12345".

So steht in der Datenbank der Hash für "hallo12345".
Der Angreifer, der mittels Rainbowtable das Passwort ausließt, denkt, dass das Passwort "hallo12345" ist - in Echt wird dann aber beim Passwortvergleich der Hash für "hallo1234545" geprüft -was natürlich fehlerhaft ist.

Also weißt wie ich das meine? Du speicherst immer nur den Hash des Passworts + eine bestimmte Phrase ab. Wenn der Angreifer nun das gespeicherte Passwort ausließt, dann kennt er die Phrase am Ende nicht - somit kann er das Passwort nicht erraten.

Ist zwar nun ein geringer Schutz, aber besser als nichts.

Jo

Wer Zugriff auf deine DB hat, wird da sowieso sehr viel Mist anstellen und alle Daten einsehen können. Macht es dann noch Sinn den Login in einen Hochsicherheitstrakt zu verwandeln?

Was mir noch zum speichern der Passwörter eingefallen ist:
Du kannst die Buchstaben der Username und des Passworts miteinander verwurschteln, also einen neuen String generieren mit z.B. Buchstaben je abwechselnd von Username und Passwort.

username: klaus
passwort: PASSW

-> kPlAaSuSsW

...und das speicherst du md5-verschlüsselt in die DB.
Beim Login fügst du die Userangaben auch wieder zu so einem Gewurschtel zusammen und verschlüsselst es. Naja und dann noch vergleichen, bla bla...

Eine von vielen kreativen Varianten, aber wie gesagt fraglich ob sich das lohnt.

ähm schauts doch mal andersrum an...wozu ein hash (der ja erst auf dem server generiert wird) in die db schreiben? mal ganz abgesehen von der privatsphäre ist es doch, dass man das pass nicht einfach verwenden kann. also ist die aussage mit dem "wer zugriff auf die db hat..." hinfällig.

@Snake: deinen Einwand verstehe ich nicht. Ich speichere md5 Hashs von Passwörtern in die Datenbank einzig um die Privatsphäre zu schützen. Meiner Meinung nach der einzige Grund.

Ich gehe davon aus, dass niemand Zugriff auf meine Datenbank hat - das wäre aber eine Sicherheitslücke, die nichts mit PHP oder allgemein Webscripten zu tun hat.
Wenn es so katastrophal aussieht ist es auch nur noch ein kleiner Schritt zum Ansehen der PHP Dateien und dann sieht man eventuelle zusätzliche Sicherheitsmaßnahmen eh (wie das Passwort modifizieren etc.

Sinnvoller als solche Anhängsel an Passwörter sind dann meiner Meinung nach, Schutzfunktionen, die eine IP nach mehrmaligen Fehlversuchen für x Minuten sperren

Passwörter sind allgemein nur so sicher, wie die Personen, die sie benutzen. Im Netz kann man zumindest halbwegs sicher sein, dass Brute-Force Angriffe nicht richtig machbar sind. (da man es immer über einzelne Requests machen muss).

Original von user-210
Eine von vielen kreativen Varianten, aber wie gesagt fraglich ob sich das lohnt.

Ich bin mir ziemlich sicher, dass es nicht lohnt.

Original von user-251el
@Snake: deinen Einwand verstehe ich nicht. Ich speichere md5 Hashs von Passwörtern in die Datenbank einzig um die Privatsphäre zu schützen. Ich gehe davon aus, dass niemand Zugriff auf meine Datenbank hat - das wäre aber eine Sicherheitslücke, die nichts mit PHP oder allgemein Webscripten zu tun hat.

na also, warum dann "sicherer" verschlüsseln?

aber unter dem fall, DASS jemand zugriff bekommt, erleichtert man das erraten durch die angabe der länge nur ungemein!

Wenn du das meintest, stimme ich dir vollkommen zu. Solche "sicherer" Verschlüsselungen sind Humbug und vollkommen sinnfrei (egal ob Längenangaben, Buchstabenpermutationen, angehängte Zeichenkette,...).

jo jetzt beim durchlesen merk ich selber, dass mich meine gedanken wohl nicht ganz beim thema waren...bei den obrigen posts...sry

Und wenn man die Länge nun selbst noch verhasht? ^^
Mh. Okay. Das mit der Länge war vielleicht doof. Bleiben wir bei den zwei verschiedenen hashs *g*

Es geht mir in keinem Fall nur um den Schutz der Privatsphäre.

Es geht eher darum wie ich relativ sicher Nutzerdaten mit einer "offenen" Schnittstelle übers Web transferieren kann (Die ganze Idee dahinter hier zu erklären würde wohl alle langweilen ^^) ohne dass man "per Zufall" den Loginnamen und den hash sehen kann. Wenn zum Beispiel ne schwäche in der Authentifizierung ist, die nicht auffällt. Oder so ^^

was bringen die 2 hashs?

Das ist natürlich erst einmal prinzipiell keine so gute Idee, da du auf diesem Wege sensible Daten - auch die verschlüsselten zähle ich hierzu - potentiell sichtbar machst.

Unter diesen Bedingungen würde ich vorschlagen:
1. Auch den user-129utzernamen zu verschlüsseln. So muss der potentielle Angreifer schon zwei Hashs entschlüsseln
2. Hier machen angehängte Buchstaben, insbesondere Sonderzeichen, natürlich Sinn. Am besten nicht nur hinten oder vorne einfügen. Damit minimierst du die Wahrscheinlichkeit, dass dieses Passwort in verschlüsselter Form irgendwo verfügbar ist.

// edit
Nachtrag:
Es hätte vieles vereinfacht, wenn den späteren Verwendungszweck schon einmal angesprochen hättest

// edit 2
Besser wäre natürlich, den ganzen Transfer über verschlüsselte Leitungen zu machen.

Nun ja. hashes haben ja nur eine bestimmte Anzahl von Möglichkeiten zur Darstellung. Wenn man nun ein ziemlich langes Passwort mit verschiedensten Zeichen hat dann gibt es vielleicht eine einfachere Zeichenkette mit dem genau gleichen hash.
Nun denk ich aber mal, dass die beiden Wörter, die md5-gehasht den gleichen hash haben, mit sha1 nicht unbedingt gleich sein müssen.

Mh. Aber wenn ich so überlege.. Die Wahrscheinlichkeit ist trotzdem ziemlich gering. Mit sha1 sinds ja etwa 1.4615e+48 Möglichkeiten.

nunja, wenn jemand dein code sieht, ist die ganze sache mit dem salz auch hinfällig, weil dann deine sonderzeichen ja bekannt sind

(wieder davon ausgehend, jemand kommt an die db. dann hat er bestimmt auch deine php datei)

Ja, aber er will ja nur die Daten öffentliche transferieren, dadurch sieht man noch nicht seinen Code.

Du könntest du zusätzlich (neben user-129utzernamen und Passwort) verstückelte Teile als dritten Hash mitübergeben.
Allgemein kann man hier sicherlich sagen: je mehr verschiedene Hashs, die ein potentieller Angreifer entschlüsseln muss, desto sicherer wird der Transfer. Irgendwann begegnest du dem Herrn abnehmendem Grenznutzen. Aber selbst das ist nicht schlimm

So. Kurz ausgerechnet: Ein 20-Stelliges Passwort mit bis zu 256 verschiedenen Zeichen schöpft einen sha1-hash vollkommen aus (Sofern ich das richtig in Erinnerung habe, dass auch sha1 zeichen 0-9 und a-f hat).
Bei md5 reichen sogar schon 16 Stellen.

Nun ja. Das Problem mit der verschlüsselten Leitung: Hier könnte wieder jemand "einfach so" die Schnittstelle abfragen. Auch wenns https ist.
Mh. Okay. Mal das Thema in eine etwas andere Richtung schieben: Den Transfer selbst. Irgendwie vergess ich immer wieder n' Punkt der alles zunichte macht (Länge des Passwortes.. ^^"".

Voraussetzung: Jeder kann den Code des Empfängers sehen, niemand den Code des "Zentralservers".

Client A piept Zentralserver an "Will Account zum Zentralserver verschieben".
Server nimmt die Anfrage entgegen, piept zurück "Okay, schick die Daten".
Client A sendet die Daten (Mh. HTTPS über POST wohl) direkt danach an den Server.

User A will dann seinen Account auf Client B sehen:
Server schickt pieps an registrierten Client B. Client B piepst zurück. Server schickt die Daten weiter.

Könnte man nun hier irgendwo "abfangen"? Oder ist das soweit sicher genug, als dass man auf den Rainbowtable-Schutz verzichten könnte?

...
Mir fällt grad was anderes ein. Wenn das Passwort nie den Zentralserver verlässt und nur da gespeichert ist wird das ganze überflüssig... o.o

Klar, das stimmt schon, aber wenn der Angreifer keinen Zugriff auf die DB hat ists es in gewisser Weise schon sinnnvoll.

Beispielsweise stehen Passwörter häufig in Cookies. Wenn so jemand sich diese Daten kopiert, dann kann er ohne Probleme mit etwas Zeitaufwand das Passwort bekommen.

Wenn es irgentwie etwas verwurstelt ist, dann nicht.


Jo

wenn er das cookie hat und dieses einen automatischen login ermöglicht, braucht er das pw garnihctmehr entschlüsseln.
man schickt einfach unverändert das cookie und ist drin

An fremde Cookies zu gelangen sollte doch noch schwerer sein, als an Datenbank etc. Immerhin liegen sie auf einem fremden PC und können nur von einer Seite gelesen werden...
Und sein eigenes Passwort muss man selten entschlüsseln.

wir streiten und noch, wenns so weiter geht
hab nur auf den kommentar von user-209 geantwortet

Ohne das jetzt fundieren zu können, rein intuitiv:

Nicht nur die Zeichenlänge des Passwortes ist eine zusätzliche Information für den Angreifer: Auch jede weitere Verschlüsselung neben dem MD5- Hash ist das. Da ja die Funktionsweise dieser Einwegverschlüsselungen jeweils bekannt ist, ist nicht auszuschließen, dass es gewisse Überlappungen gibt, die bei synchroner user-129utzung verschiedener "Verschlüsselungsalgorithmen" irgendwelche Rückschlüsse auf das Passwort zulassen.
Oder kurz: Du erhöhst durch zwei unterschiedlich verschlüsselte Hashs schlicht und ergreifend auch die Angriffsmöglichkeiten.

Ich halte MD5 Hashs für völlig ausreichend, die Wahrscheinlichkeit, dass jemand in *meine* DB eindringen kann (und überhaupt will) und dann auch noch die passenden Hashs in Regenbogentabellen findet ist wohl eher gering.
Das Hinzufügen einer vorher definierten Zeichenkette (aus dem hohen ASCII- Bereich) zum Passwort ist m.E. eine recht gute Möglichkeit, derartige Tabellen auszutricksen. Da ist es dann auch egal, ob der Angreifer diese hinzugefügte Zeichenkette kennt...

brb

Original von user-303
wir streiten und noch, wenns so weiter geht
hab nur auf den kommentar von user-209 geantwortet

Nein, auch ich habe mich auf user-209s Post bezogen. Nur aus einer anderen Perspektive.
Dein Einwand ist genauso treffend.

sorry, ich muss zu diesem Thema unbedingt nochmal sagen, dass bei Pnyyzbovyr nach Aussage eines Mitarbeiters die Passwörter generell völlig unverschlüsselt gespeichert werden. Ich musste mich direkt als Klugscheißer beschimpfen lassen, als ich darauf hinwies, dass die Verschlüsselung eigentlich üblich ist.
So gesehen seid ihr mit einem einfachen ROT 13 schon direkt Vollprofis und um ein Vielfaches sicherer als dieser Konzern, der auch noch Kohlen für seinen Dienst haben will.

Original von user-124
Nicht nur die Zeichenlänge des Passwortes ist eine zusätzliche Information für den Angreifer: Auch jede weitere Verschlüsselung neben dem MD5- Hash ist das.

Dem ersten Teil stimme ich zu dem zweten eher nicht. Vielleicht verstehe ich aber auch deinen Punkt nicht.
Auch wenn ich kein Freund von Beispielen bin:
Wenn ich sowohl den benötigten user-129utzernamen (oder einen beliebigen benötigten zusätzlichen Teil des Logins) als auch das dazugehörige Passwort per md5 verschlüsselt übertrage, muss der böse Angreifer zumindest zwei Hashs entschlüsseln.
Da es bisher keine Entschlüsselung von md5 Hashs gibt (Brute Force ist keine Entschlüsselung ja nicht einmal eine Methode. Genauso wenig Übersetzungstabellen), braucht er schon viel Glück entweder richtig zu raten oder eine Lösung für beide Hashs irgendwo zu finden. Hier sehe ich keinerlei nützliche zusätzliche Information für den Lauscher.

Allgemein würde mich folgendes interessieren (Wasili hatte es in einem Post glaube ich schon angedeutet): Ein md5-Hash hat eine Länge von 32 und benutzt nur bestimmte Zeichen. Rein numerisch gesehen, kann es also nur eine feste Anzahl (sagen wir x) verschiedener disjunkter Verschlüsselungen geben. Die direkte Folge die x+1.te Zeichenkette ist verschlüsselt identisch mit einer der ersten x verschlüsselten Zeichenfolgen. Stimmt das so?
Wenn ja: Kennt jemand den Algorithmus gut genug, um klar zustellen, wie die Informationsreduktion (bei beispielsweise zu langen Passwörtern) funktioniert? Sollte es Überschneidungen mit "kurzen" Passwörtern geben, wäre das ja wirklich doof. Es existieren laut Wikipedia ja bereits vollständige gegenüberstellende Tabellen bis zu einer Länge von 8 Zeichen.
Könnte man dem einfach durch eine zweifache user-129utzung von md5 entgehen. Auch wieder ein Beispiel unter der Prämisse, ich habe vorher keinen logischen Fehler gemacht:
1) Ich habe ein Passwort x mit der Verschlüsselung y
2) Die Verschlüsselung von y ist y2
3) y2 wird als verschlüsseltes Passwort übertragen
4) Auch wenn y2 mit der verschlüsselten Form eines kurzen Passworts kollidiert und y2 so "entschlüsselt" werden kann, hilft es nichts, da von der kastrierten Lösung keinerlei eindeutiger Rückschluss auf das ursprüungliche Passwort x möglich ist?

Michael

ich glaube brb meinte eher, dass das SELBE passwort 2x mit verschiedenen hasharten gespeichert wird.

nunja, ich fühle mich mit md5 schon lange nicht mehr sicher. bsp: http://freerainbowtables.com/

also ich geb keinem mein md5 pw. schlimm genug dass es in so vielen dbs steht...


muss nun in die schule viel spaß beim weiter diskutieren

Original von user-303
ich glaube brb meinte eher, dass das SELBE passwort 2x mit verschiedenen hasharten gespeichert wird.

Genau das meinte ich. Ist doch klar, dass man dadurch evtl. vorhandene Sicherheitslücken addiert. Das Argument der Angriffsfläche sozusagen .

Ich stelle soeben fest, dass mein "sicheres" - 8stelliges PWD - mit verschiedenen Sonderzeichen etc. auf alle Fälle in Rainbowtables erfasst ist (weil halt bis zu 8 Zeichen alle durchgebruteforced wurden), mein "unsicheres" - 11stelliges PWS - das eine Aneinanderreihung gewisser Worte mit der Auslassung einiger Vokale ist, allerdings nicht. Na toll.

Gut, dass ich seit ein paar Wochen KeePass benutze. Ich weiß zwar noch nicht, wie ich mich auf fremden Rechnern z.B. in StudiVZ einloggen soll, dafür habe ich momentan ein Passwort, das nach allen Regeln der Kunst sicher sein dürfte (ich kenne es ja selbst nichmal).

Unter der Dusche kam mir eine Idee:
Könnte man anstelle des Passwortes nicht den md5 Hash manipulieren. Also beispielsweise Zahlen vertauschen etc.
Solange dies eine feste Regel ist (die nur beiden Skripten bekannt sein muss) kann das schnell rückgängig gemacht werden und ein eventueller Angreifer erwischt nur einen unbrauchbaren Hash. user-158n wäre auch die Länge des Passwortes vollkommen egal.

Nein. 1) Ist dein Vorschlag auch nur eine Variante des Saltenz und auf dem ersten Blick dem einfachen Anhängen eines bestimmten Strings gleichwertig. 2) Kann ein Angreifer mit Vollzugriff auf dein System aber nachvollziehen, wie der Hash verändert wurde (muss ja irgendwo gecoded sein), was er nicht kann, wenn der String erst verändert und dann gehashed wird (bzw. nachvollziehen kann er das dann natürlich auch aber eben nicht mehr rückgängig machen, da es ja bereits gehashed ist)




Eine etwas andere - aber für den User kompliziertere - Möglichkeit wäre folgende: Bei der Registrierung wird das Passwort des user-129utzers mit einem von ihm gewählten Sicherheitskennwort verlängert und "gesalted". Der Hash davon kommt in die DB.

Das Sicherheitskennwort wird nicht gespeichert.

Bei der Anmeldung muss er nun user-129utzernamen, Passwort und Sicherheitskennwort eingeben. Diese werden wie zuvor zusammengefügt und gehasht. Stimmen generierte und gespeicherter Hash- Wert überein, war die Anmeldung erfolgreich.

Vorteil dieser Methode:
* Durch das Salten werden Rainbowtable- Angriffe (quasi) ausgeschlossen
* Durch das nicht gespeicherte Sicherheitskennwort entfällt die Schwäche, dass ein potenzieller Angreifer die Art, in der das Passwort verändert wird (z.B. Anhängen eines konstanten Strings), nachvollziehen kann: Er kann das Sicherheitskennwort nicht in Erfahrung bringen.

Nachteil:
* Mehraufwand für den user-129utzer.


Allgemein ist das ganz normale Salten von Passwörtern völlig ausreichend - denke ich. Selbst wenn der Angreifer weiß, wie genau das Passwort verändert wurde, kann er aus dem MD5 Hash nicht das ursprüngliche PWD ableiten.



Thema: Kollisionen: Sie sind zwar prinzipiell Möglich, ich halte sie aber für mehr als unwahrscheinlich: Ich glaube, MD5 nutzt a-z, 0-9, oder? Das sind 36^32 Möglichkeiten. Selbst wenn ich davon ausgehe, dass 256^6 MD5 Hashes bereits in Rainbowtables erfasst sind - und somit zur Berechnung eventueller Kollisionen herangezogen werden könnten - bleibt noch ein ausreichend großer Restbestand an unbekannten Hashes.
Soweit ich weiß wird ja auch empfohlen eher SHA1 einzusetzen als MD5 - was für den Programmierer keinerlei Unterschied macht... bei SHA1 gibt es letztendlich aber die gleichen Probleme. Man könnte auch einen höherbittigen MD5 Algo benutzen.

brb

Original von user-124
Kann ein Angreifer mit Vollzugriff auf dein System aber nachvollziehen, wie der Hash verändert wurde (muss ja irgendwo gecoded sein), was er nicht kann, wenn der String erst verändert und dann gehashed wird (bzw. nachvollziehen kann er das dann natürlich auch aber eben nicht mehr rückgängig machen, da es ja bereits gehashed ist)

Da hast du vollkommen recht, allerdings gehen wir hier von der Annahme/Aufgabenstellung aus, dass ein verschlüsseltes Passwort über eine nicht sichere Leitung übertragen werden muss/soll. Und da macht es meiner Meinung nach einen Unterschied, ob der Hash oder das Passwort verändert wird.
Fraglos ist jede Manipulation des Passworts/Hashs sinnlos, wenn der Angreifer Zugang zum System hat.

Ich finde es allgemein eine gute Idee, zum Beispiel das Registrierdatum in einem user-129utzerpasswort unterzubringen und erst danach zu verschlüsseln. Ein Angreifer, welcher nur über den Hash verfügt, hat so - auch aufgrund der Passwortlänge - kaum eine Chance mit einer Rainbowtable etwas zu erreichen.
Falls jemand schlimmstenfalls vollen Zugriff auf meinen Server erlangen würde, wäre es wohl nur eine Frage der Zeit, bis er auch Schreibrechte hat. Somit könnte er ja gleich die Daten in der Datenbank selber ändern und würde sich vermutlich gar nicht mehr mit fremden Passwörtern einloggen wollen

ich denke nicht, dass es hier nur ums einloggen geht.
die meisten passwörter werden in mehr als einem portal benutzt...