PHP verständnisfrage salt wert

[adblue]

hi

ich bin gerade dabei ein sicherer login system zu bauen. dabei bin ich auf die möglichkeit mi dem salt-wert gestoßen.
ich erzeuge mit per php befehle eine zufallsstring mit 6 zeichen. (möglichst kompliziert: d.h. klein und groß schreibung und sonderzeichen)

wenn sich ein user registiert und sein persönliches passwort speichert, hänge ich einfach diesen zufallswert an und speichere es dann in der datenbank:

md5($passwort.$zufall);

wenn sich der user dann wieder einloggen will, hänge ich wieder den salt wert an das eingegebene passwort und kontrolliere dann ob es mit dem md5-hast in den datenbank übereinstimmt.
probleme ist nur, dass ich den zufallswert ($zufall) auch in der datenbank speichern muss.

aber im klartext will ich den zufallswert auch nicht speichern. wie macht ihr das?

 

[d82dennis]

Wenn ich deine art richtig verstehe heisst es $zufall wird nur intern erzeugt.

Was soll das dann aber bringen? Wenn man ein pw mit MD5 speichert ist es anfürsich sicher, wenn jetzt jemand dieses PW sich iwo erschlichen hat, kann er sich ja trotz dem $zufall einloggen oder etwa nicht?

edit: Habe verstanden was der sinn ist, google helps

 

[adblue]

ob md5 sicher ist oder nicht da kann man sich streiten. es gibt bereits md5 suchmaschinen die das klartextpasswort sofort ausgeben können. siehe: https://md5.rednoize.com/
brutal force programme gibt es ja auch noch.


der sinn vom salt wert ist doch der, dass man das passwort "verlängert". oder?

ich dachte schon das ich den zufallswert durch eine konstante in der php datei ersetze. also so:


$konst = "65;.t4()AAkfB§E";
md5($passwortUSER.$konst)

bei jedem login versuch setze ich an das ende des eingegebene passwortes diese konstante wieder an.

bringt das was? besser ist doch der zufallswert. aber wie kann ich das umsetzen?

 

[XadreS]

brutal force programme gibt es ja auch noch.

Brutal Force? Ich kenne nur Brute Force

Die Konstante ist eine Möglichkeit, die auch schon zur Sicherheit beiträgt. Schließlich gibt es ja User die immernoch Passwörter wie "123456" oder sowas nehmen.

Wenn ich das richtig verstanden habe, willst du ansonsten lieber einen Zufallswert generieren, den du bei der Registrierung mit in die Datenbank speicherst?!

Wäre auch ne Möglichkeit.

Was ich gerade noch im Kopf habe:
Du könntest auch einen Pool von sagen wir mal 5-10 Zufallswerten in ein Array schreiben und einen davon zufällig an das PW hängen. Nur müsstest du beim Login eben auch die 5-10 Zufallswerte prüfen, ob einer davon passt.

Ich würd das aber aus Performancegründen nicht machen. Wobei dass ja pro Login ne einmalige Sache ist und nicht auf jeder Unterseite gemacht wird.

 

[ice-breaker]

aber im klartext will ich den zufallswert auch nicht speichern. wie macht ihr das?

doch der wird im Klartext gespeichert, gibt auch keine Sicherheitsbedenken, denn der Wert ist sowieso nur ein weiterer Faktor um das Hashing sicherer zu machen.

Nutze aber für jeden User einen eigenen Salt, sonst funktioniert Brute Force weiterhin, falls jemand an deine Passwort-Hashes und deinen festen Salt kommt.
Bei einem eigenen Salt für jeden User, muss für jedes Passwort ein neuer Bruteforce-Durchlauf gestartet werden, nimmst du den gleichen Salt muss man nur einen Durchlauf machen und gegen alle Hashes vergleichen.

 

[marac]

wenn jetzt jemand dieses PW sich iwo erschlichen hat, kann er sich ja trotz dem $zufall einloggen oder etwa nicht?

Wenn jemand an dein Passwort kommt, kann er sich immer einloggen, da kann kein serverseitiger Mechanismus helfen.

Das Anhängen eines salt ist ja - wenn ich das richtig verstanden habe - dafür gedacht, dass - sollte jemand an den md5-Hash aus der Datenbank kommen - man per Rainbow-Table nicht auf das (bzw. ein funktionierendes) zurückschließen kann, da man eben nicht ein Passwort an den Server schicken muss, dass md5-verschlüsselt den gespeicherten Wert ergibt, sondern ein Passwort, das mit angehängtem salt und dann verschlüsselt dem gespeicherten Wert entspricht. Eine Rainbow-Table würde in diesem Fall dann eben nicht weiterhelfen.

Das Speichern des salt in der Datenbank ist so gesehen aber trotzdem unproblematisch.
Gehen wir mal davon aus, das Passwort wäre "h1JH9+s3", der salt "%12nF<" und der daraus generierte md5-hash "a52c7116be3" (völlig beliebige Werte). Dann würde der böse Junge, der irgendwie an Hash und Salt gekommen ist, vielleicht in einer Rainbow-Table feststellen, dass ein passendes Passwort für den Hash "a52c7116be3" zum Beispiel "ameisenbär" wäre. Und? Was hilft ihm das? Wenn er nun versucht, sich mit dem Passwort "ameisenbär" einzuloggen, hängt der Server den Salt an ("ameisenbär%12nF<") und baut daraus einen Hash. Dieser passt nicht mehr zum gespeicheten Hash, und die Anmeldung schlägt fehl. Erfolg hätte er nur dann, wenn er in einer Rainbow-Table zufällig ein passendes Passwort für den Hash findet, das auf "%12nF<" endet. Dann könnte er sich mit dem Teil vor dem "%12nF<" anmelden. Aber wie hoch ist dafür die Wahrscheinlichkeit?

Die andere Frage ist doch, wenn es ein Hacker geschafft hat, an deine Datenbank ranzukommen, ist es ihm wahrscheinlich egal, ob er sich auch auf "normalem" Weg an deinem Server anmelden kann, denn reingekommen ist er ja sowieso schon. Die ganze Verschlüsselei von Passwörtern auf Servern dient eigentlich nur dazu, die Dummheit der User ungefährlicher zu machen. Deinen Server hat der Hacker schon offen, der Zugang dazu ist für den Hacker also nicht mehr wirklich interessant. Wenn er nun aber über die Daten, die du in deiner Datenbank gespeichert hast, an das Klartext-Passwort kommt, könnte er damit unter Umständen an Konten dieses Benutzers auf anderen Servern kommen, weil nunmal viele User aus Bequemlichkeit Passwörter mehrfach verwenden.

 

[tobomator]

der md5 Link von adblue ist mal nur schnurz:

Wenn man ein wort eingibt, generiert er ein MD5 hash (wow)
Wenn ich dann den Hash dort eingebe, gibt er den alten Text aus (WOW)
Wenn ich im Hash zahlen ändere (PENG - Hash not found)

Wo is da denn reverse engeniring ???
Und Brute Force is es auch nciht

 

[Graccem]

der md5 Link von adblue ist mal nur schnurz:

Wenn man ein wort eingibt, generiert er ein MD5 hash (wow)
Wenn ich dann den Hash dort eingebe, gibt er den alten Text aus (WOW)
Wenn ich im Hash zahlen ändere (PENG - Hash not found)

Wo is da denn reverse engeniring ???
Und Brute Force is es auch nciht

adblue hat nicht behauptet, dass es Brute Force ist und von "reverse engeniring" war nie die Rede.
Die Seite wird mit einer Rainbow-Table arbeiten, die Hashes von gängigen Zeichenketten enthält. Das reicht meistens auch aus, da zu selten sinnvolle Passwörter genutzt werden.

 

[tobomator]

diese seite ist nur ein schlechtes beispiel für sowas...
jedenfalls in meinen Augen

 

[acid]

Die Seite wird mit einer Rainbow-Table arbeiten, die Hashes von gängigen Zeichenketten enthält. Das reicht meistens auch aus, da zu selten sinnvolle Passwörter genutzt werden.

Es ist einfach nur ne Suchseite, die nach bereits eingetragenen Hashes sucht.
Wenn du nen Wort suchst, wird der Hash gespeichert. Wenn jemand danach den Hash sucht, kriegt er das Wort. So entsteht über die Zeit ne große Datenbank. Mit ner Metasuche hat man so gute Chancen gängige/einfache Passwörter zu finden und auch nen paar komplizierte. Es ist aber nichts weiter als ne sehr lange Wordlist.

 

[DaxDony]

der sinn vom salt wert ist doch der, dass man das passwort "verlängert". oder?

Nein, das Passwort wird nicht verländert. Schließlich loggst du dich am Ende ja auch noch mit "123456" ein, und nicht mit "123456$///§&&"&§".

Stell dir mal vor, du hast eine Website mit 10.000 Usern und ein Hacker schafft es, ein Dump von deiner Datenbank zu erstellen.
Nun wird er sicherlich einen großen Teil der Passwörter knacken können, denn Rainbowtables gibt es im Internet genug.
Nun verwenden viele User ein Passwört für viele Dienste - und schon hat man gehackte PayPal Accounts.

Um das zu verhindern, versuchst du das knacken der Passwörter durch Rainbowtables zu verhindern / erschweren.
Dabei gibt es drei Methoden beim salten, die beliebig miteinander kombiniert werden können:

1. Statisches Salt
Du definierst im Script einen Wert, der dann beim hashen immer hinzugegeben wird. Gewöhnliche Rainbowtables fallen somit weg - und da ein Hacker oft nicht an das Script rankommt, kann er auch keine eigene Rainbow-Tabelle erstellen.

2. Dynamisches Salt
Bei 10.000 Usern gibt es sicherlich 25 User, die das selbe Passwort verwenden - und der hash wäre dann (auch mit einem statischen Salt) der selbe, was man leicht mit dynamischen Salts verhindern kann.
Einfach beim hashen zusätzlich noch den Usernamen benutzen, dann wirst du selbst bei 10.000.000 Usern keinen doppelten Hash haben.

3. Salt aus der Datenbank
Jeder User hat seinen eigenen Salt-Wert, der in der Datenbank gespeichert wird. Finde ich persöhnlich zu Heavy. Ich verwende immer Methode 1 & 2.

 

[tobomator]

Wenn ein Hacker ein Abbild von einer Datenbank anfertigen kann, warum sollte er dann nicht an das Script herankommen, wo der statische oder dynamischer Saltwert drin steht ?
Wenn ein Hacker zugriff auf ein System hat, dann auf das ganze und nicht nur aufs halbe...

Also kann man sich das getrost sparen, etwas nicht in der DB abzuspeichern.
Nur weil ein Hacker Code über POST einschleusen kann (SQL Injection), wer sagt denn, das der Rest des Systems dann nicht genauso sicher ist, wie diese Lücke ???

...

Nachsatz:
Selbst ohne einen Saltwert wird mit dem Hash(PW + LOGIN) keine zwei gleiche Ausgabewerte erzeugt, auch wenn 25 Leute das gleiche PW nutzen, aber der LOGIN unterschiedlich ist.
Und wer nicht darauf achtet, das ein LOGIN einmalig sein sollte, begeht schon hier den ersten Fehler...

 

[flaschenkind]

Es gibt keine Garantie, dass ein Hash einmalig gibt. Je nach Hashing-Verfahren gibt es mehr oder weniger mögliche Kollisionen.
Bei md5 haste ja z.B. nur 16^32 Möglichkeiten. Die sind irgendwann ausgeschöpft und dann kann es passieren, dass zwei Klartext werte den selben Hash-Wert ergeben.

 

[tobomator]

ich schrieb deswegen auch a) nur Hash und b) ist mir bekannt, das Hashing nichts sicheres ist, weil Kollisionen vorkommen.
Nunja, eine gewöhnliche Seite wie der Author des Threads es wohl vor hat, schafft es keine 16^32 ( 3,4028236692093846346337460743177e+38 ) User auf seiner Seite zu fesseln.
Man kann auch Methoden nutzen um "künstliche" Hash Kollisionen zu erzeugen, was leider bei MD5 sehr schnell geht...

Saltwert würde ich nicht nutzen.

Wer von einem Hacker gesniffed wird, kann seine Passwörter auf dem Server mittels einem Script so viel Hashen wie er will, es wird halt auf dem Weg zum Server im Klartext übermittlet !

 

[ice-breaker]

Man kann auch Methoden nutzen um "künstliche" Hash Kollisionen zu erzeugen, was leider bei MD5 sehr schnell geht...

Wir sprechen hier jedoch nur von einer einfachen Kollision, man also 2 spezielle Nachrichten m1 und m2 so konstruiert, dass sie die den gleichen Hashwert ergeben: h(m1) = h(m2)

Der Fall eine Kollision mit dem Passwort-Hash zu finden, also eine Nachricht m2 zu finden, die nur unter bekanntem Hash des Originalpasswortes h(m1) den gleichen Wert ergibt (first preimage attack), also h(m1) = h(m2), ist bei md5* noch immer nicht geknackt[1].

Nur weil jemand sagt, man kann Kollisionen in einem Hashing-Algorithmus finden, sagt dies noch nichts über die Güte der Kollision aus, denn i.R. wird nur die einfache Kollision gefunden, die so gut wie nutzlos ist. Erst die first und second preimage attack ist ein realer Angriff auf die Hashfunktion, die ausgenutzt werden kann und somit das Verfahren als gebrochen und unsicher ansehen lassen.

* Es werden heute sowieso sichere Verfahren wie sha-256 oder sha-512 empfohlen, denen das BSI eine Sicherheit für die nächsten 10 Jahre zuschreibt.

[1] All currently known [...] attacks on MD5 [...] are collision attacks. In general, a collision attack is easier to mount than a preimage attack.

Wer von einem Hacker gesniffed wird, kann seine Passwörter auf dem Server mittels einem Script so viel Hashen wie er will, es wird halt auf dem Weg zum Server im Klartext übermittlet !

für solche Dinge wurde SSL erfunden...

 

[DaxDony]

Man kann auch Methoden nutzen um "künstliche" Hash Kollisionen zu erzeugen, was leider bei MD5 sehr schnell geht...

Das bringt einem Hacker absolut nichts. Außerdem wird in den meisten Fällen SHA256, SHA384 oder SHA512 benutzt.

Saltwert würde ich nicht nutzen.

Erklären kannst du es aber nicht, oder?

Wer von einem Hacker gesniffed wird, kann seine Passwörter auf dem Server mittels einem Script so viel Hashen wie er will, es wird halt auf dem Weg zum Server im Klartext übermittlet !

Total am Thema vorbei. Wenn sich jemand das Passwort auf einen Zettel aufschreibt, und der Zettel dann geklaut wird, kommt man auch in den Accout rein, doch was hat das mit dem salten von Passwörtern zu tun?

Wenn ein Hacker ein Abbild von einer Datenbank anfertigen kann, warum sollte er dann nicht an das Script herankommen, wo der statische oder dynamischer Saltwert drin steht ?

Datenbankserver != PHP-Server. Wenn ich einen VW kurzschließen kann, heißt es nicht, dass ich das selbe bei einem A4 schaffe.

Es gibt keine Garantie, dass ein Hash einmalig gibt. Je nach Hashing-Verfahren gibt es mehr oder weniger mögliche Kollisionen.
Bei md5 haste ja z.B. nur 16^32 Möglichkeiten. Die sind irgendwann ausgeschöpft und dann kann es passieren, dass zwei Klartext werte den selben Hash-Wert ergeben.

Richtig, deshalb kann man auf andere Methoden zurückgreifen, die weitaus mehr mögliche Kombinationen bieten.
Außerdem könnte man ja theoretisch das Passwört auf maximal 50 Zeichen beschränken. Da wäre die Frage, ob es möglich wäre eine Kollision zu finden, die weniger als 50 Zeichen lang ist.
Wobei man sich mit den Kollisionen nicht verrückt machen lassen sollte.

 

[tobomator]

Schon mal darüber nachgedacht, dass es mathematische Umkehrfunktionen für jede Funktion gibt ?
Sicher nur sind sie nicht einfach aus dem Hut zu zaubern...

Nehmen wir mal etwas theoretisch an, was wir normal sterblichen nicht bezahlen können, aber jeder Geheimdienst der genug Geld hat.

Es gibt Algorithmen die in Hardware "gegossen" werden, d.h. für eine bestimmte Schlüssellänge zu einem bestimmten Verschlüsselungsverfahren.
Nehmen wir weiterhin an, es gibt SHA-mit 1024 Länge...
Also wird ermittlet, wieviele Mögliche Schlüssel gibt es mit einem kompletten UTF Zeichensatz und läßt diese in Hardware "gießen".
Das würde bedeuten, man kann in Echtzeit jeden Text mitlesen, da er oben reinfällt und unten an einer schlüsselposition als Klartext herausfällt.
Da es vll zu teuer ist, sowas in Hardware zu gießen und man auch rein programmtechnisch HArdware entwirft, werden die Schaltungen also nur in Software gegossen und von Schnellen Rechnern durchprobiert.

Bin ich paranoid ? Wer weiß, aber möglih ist das schon seit sicher 5 Jahren !

 

[ice-breaker]

Schon mal darüber nachgedacht, dass es mathematische Umkehrfunktionen für jede Funktion gibt ?
Sicher nur sind sie nicht einfach aus dem Hut zu zaubern...

lol, Hashfunktionen sind nicht bijektiv und somit existiert keine Umkehrfunktion, das ist ja der Sinn der Sache.

Also wird ermittlet, wieviele Mögliche Schlüssel gibt es mit einem kompletten UTF Zeichensatz und läßt diese in Hardware "gießen".
Das würde bedeuten, man kann in Echtzeit jeden Text mitlesen, da er oben reinfällt und unten an einer schlüsselposition als Klartext herausfällt.

Da die Urbildmenge also die Anzahl möglicher Schlüssel quasi unendlich ist, ist dein kompletter Ansatz Unfug.

Da es vll zu teuer ist, sowas in Hardware zu gießen und man auch rein programmtechnisch HArdware entwirft, werden die Schaltungen also nur in Software gegossen und von Schnellen Rechnern durchprobiert.

nein, dies ist schon möglich, das nennt sich dann FPGA



Sorry, aber deine ganzen Aussagen sind einfach nur absolut falsch womit man absolut an deiner Fachkompetenz zu dem Thema zweifeln muss.

 

[tobomator]

Sicher das ein Hashfunktion bijektiv ist ?
Laut Wikipedia, wo die Hashfunktion schön erklärt ist, steht davon nichts dabei.
Entweder hat der Autor dort das vergessen oder es ist nicht wahr (was ich nicht annehmen möchte).

@ice:
In der Vergangenheit wurde viel angenommen und mathematisch "gedacht", es ist nicht zu "knacken", aber immer wieder gibt es Verfahren, die ein kryptografisches Sicherheitssystem aushebeln (wozu Hashfunktionen nicht gehören !).
Weiter laut Wikipedia (ich zitier mal):

"... Nur Bijektionen behandeln ihren Definitionsbereich und ihren Wertebereich symmetrisch, sodass eine bijektive Funktion immer eine Umkehrfunktion hat bzw. invertierbar ist."

Das würde ja dem widersprechen was Du behauptet hast, das eine bijektive Funktion keine Umkehrfunktion besitzt.

Soviel zu dem was Du meinst, oder Wikipedia ist (autsch, ich möcht es lieber nicht sagen)...


Nachtrag:

Super, also liegst Du richtig mit dem was Du meinst, das Hashfunktionen nicht bijektiv sind.
Dennoch gibt es eine Umkehrfunktion, da bin ich mir sicher, sie ist noch nicht gefunden, oder nur geheim !

 

[LasMiranda]

...Dennoch gibt es eine Umkehrfunktion, da bin ich mir sicher, sie ist noch nicht gefunden, oder nur geheim !

Wenn Buchstaben in Zahlen von 0 bis 9 gequetscht werden, wie willst du rausbekommen, wie die Originalzahl und damit die Originalbuchstaben war?