PHP Ich verstehe den Random Salt nicht

[The-Master]

Ich sehe das so. Der zu "knackende" Hash ist ein abgeschnittener SHA-2 Hash und sieht so aus, als sei es ein MD5 (32 Zeichen) oder SHA-1 (40 Zeichen) Hash. Der Angreifer kann mit seinem Bruteforce-Angriff durchaus ein Ergebnis erzielen. Bspw. liefert der vermeindliche MD5/SHA-1 Hash eine Übereinstimmung mit dem String "123456". Doch heißt das zugleich, dass das tatsächliche Reintext-Passwort dem entspricht? Mitnichten ist das Reintext-Passwort ein anderer String, bspw. "abcdef".

Der Angreifer denkt also das Ergebnis gefunden zu haben. Dennoch wird es sich mit dem vermeindlich gefundenen Passwort niemals einloggen können.

Ok, so gesehen mag das zwar stimmen, jedoch würde ich mich nicht darauf verlassen, dass der Angreifer nicht herausfindet, auf welche weise der Hash berechnet wird. (http://de.wikipedia.org/wiki/Kerckhoffs’_Prinzip Edit: Ich hoffe ihr seid mir nicht böse, dass ich das auf ein Hashing-Verfahren beziehe, aber die Aussage ist trotzdem richtig^^)

Nachtrag: Ist dem Angreifer bekannt, dass der Passwort-Hash ein abgeschnittener SHA-2 Hash ist, kann dies weitreichende Folgen haben. Jedenfalls nach meiner Überlegung. Die zusätzliche Sicherheit durch SHA-2 (128 vs 32/40 Zeichen) wäre damit enthebelt. Es besteht eine Wahrscheinlichkeit, mit einem vom Reintext-Passwort abweichenden String einen SHA-2 Hash zu erhalten, dessen erste 32 Zeichen dem abgeschnittenen SHA-2 Hash des Reintext-Passwortes entspricht. Somit würde ich dazu raten, wenn schon SHA-2 verwendet wird, den Hash auch in seiner Länge zu speichern.

Das meinte ich, wenn man einen Hash verkürzt, erhöht sich die Wahrscheinlichkeit eine Kollision zu finden.

 

[Trainmaster]

@ The-Master

Siehe meine Nachtrag. Ich bin zunächst davon ausgegangen, dass der Angreifer die Berechnung des Hash nicht kennt. Davon sollte man aber heutzutage nicht mehr ausgehen. OpenSource Systeme kann sich jedermann herunterladen und nachvollziehen, auf welche Weise der Hash berechnet wird.

Edit: Im Prinzip könnte man dies einigen CMS-Systemen ankreiden.

Ganz nach dem Motto:
Person A: Ich habe ein paar Hashs von einer Joomla Seite / xtCommerce Shop
Person B: Kein Problem. Wir wissen ja wie Joomla / xtCommerce standardmäßig den Hash erstellt

Ganz anders wäre dies, wenn der Benutzer eines CMS der internen Hash-Erstellung eine individuelle Note verpassen könnte. Wobei es dennoch schwierig (unmöglich?) sein dürfte einen SHA-512 Hash, welcher aus dem Passwort und einem Unique String zusammengesetzt ist, mit einer Bruteforce-Attacke bzw. einer Rainbowtable zu erwischen. Aber ich denke, dass nicht alle CMS-Systeme einen unique Salt verwenden.

 

[The-Master]

Ich seh schon^^ wir sind uns einig

 

[Trainmaster]

Wunderbar. Vielleicht sollten wir eine kleine Übersicht zu dem Stand der Technik und Empfehlungen zu einer zeitgemäßen Speicherung von Passwörtern in einer Datenbank verfassen

 

[The-Master]

Ich seh schon^^ wir sind uns einig

oder auch nicht

Edit: Im Prinzip könnte man dies einigen CMS-Systemen ankreiden.

Ganz nach dem Motto:
Person A: Ich habe ein paar Hashs von einer Joomla Seite / xtCommerce Shop
Person B: Kein Problem. Wir wissen ja wie Joomla / xtCommerce standardmäßig den Hash erstellt

Ganz anders wäre dies, wenn der Benutzer eines CMS der internen Hash-Erstellung eine individuelle Note verpassen könnte. Wobei es dennoch schwierig (unmöglich?) sein dürfte einen SHA-512 Hash, welcher aus dem Passwort und einem Unique String zusammengesetzt ist, mit einer Bruteforce-Attacke bzw. einer Rainbowtable zu erwischen. Aber ich denke, dass nicht alle CMS-Systeme einen unique Salt verwenden.

Der sinn hinter Hashs ist ja, dass sie es ermöglichen eine Eingabe zu Überprüfen, ohne, dass man vom Hash auf die direkt Eingabe schließen kann, um jedoch Datenbanken / Raindow-Tables entgegen zu wirken, ist es sinnvoll noch zusätzlich den Hash zu Salten: Die Sicherheit solle einzig darauf beruhen, dass es kein effizientes verfahren gibt, um aus einem Hash die / eine zugehörige Eingabe zu ermitteln.

Demnach sollte es ausreichend sein, ein Standardisiertes Verfahren zu verwenden um den Hash zu bilden / zu verifizieren. --> z.B.: PBKDF2
(Mein Beispiel aus Post #7 war daran angelehnt)

 

[Trainmaster]

Ich dachte eigentlich, dass wir uns einig sind.

Ein standardisiertes Verfahren ist ausreichend, solange der Salt und die Hash-Methode ausreichend sicher ist. Bspw. kann ein unerfahrener Nutzer von Joomal ein relativ unsicheren Salt einstellen.

return '$1$'.substr(md5(mt_rand()), 0, 8).'$';

Also mir wird es bei soetwas ganz schaurig. Kein Wunder dass es diverse Foren gibt, bei denen man "Joomla Hashs" entschlüsseln lassen kann

 

[furryhamster]

Bei der Methode würde ich die Salt Methode wie im Internet beschrieben anwenden. Zusätzlich wüsste man ohne PHP Code nicht um Welche verschlüsselung es sich handelt (kürzung auf 32 zeichen = md5 +8 Zeichen hash = sh1).

ich kann zwar bei der letzten diskussion nicht alles nachvollziehen. allerdings lese ich daraus, dass meine oben genannte funktion schon ziemlich "sicher" ist, sofern ich einfach den sha2 hast nicht auf 32 zeichen kürze. dadurch würde sich zwar ein 136 zeichen langer string entsteht, wodurch ich aber eigl keine nachteile habe.

wäre schön wenn mir einer dies nochmal so bestätigen könnte

 

[ice-breaker]

nein, deine Funktion ist absoluter Quatsch, Security-Through-Obsurity funktioniert nicht, du prependest den Salt an den Hash, also kennt man auch den Salt und dein zusätzlicher "Schutz" war sinnlos.
Zu welchem Zweck Zufalls-Salts errechnet werden, ist mir auch schleierhaft, immerhin sind die Daten nicht mehr vergleichbar, für CSRF-Tokens usw. gibt es bessere Methoden zur Erzeugung (über Google findet man bestimmt welche).

ehrlich gesagt verstehe ich auch nicht warum du es dir so kompliziert machst, folgendes ist best-practice:

function myHash($value, $salt) {
  // APPLICATION_SALT ist ein dynamischer Salt für jede Applikation
  return sha512($value . $salt . APPLICATION_SALT); // sha512 existiert nicht, steckt aber meine ich in irgendeiner Bibiliothek
}

// aufgerufen mit einem eigenen salt für jeden Nutzer/Ressource/wasauchimmer:
myHash($ottoPw, $ottoSalt);
myHash($annaPw, $annaSalt);

Von mir aus kann man es auch wie in Linux machen und den Hash noch x-mal hashen um die Laufzeit von Bruteforce-Angriffen bei bekanntem Algorithmus steigen zu lassen, auch lässt sich hier wunderbar durch den Algorithmus Paralellität von GPGPU verhindern:

function myHash($value, $salt) {
  $hash = $value;
  for($i = 1; $i <= 50; $i++)
    $hash = sha512($i . $hash . $salt . APPLICATION_SALT);
  return $hash;
}

 

[The-Master]

ich kann zwar bei der letzten diskussion nicht alles nachvollziehen. allerdings lese ich daraus, dass meine oben genannte funktion schon ziemlich "sicher" ist, sofern ich einfach den sha2 hast nicht auf 32 zeichen kürze. dadurch würde sich zwar ein 136 zeichen langer string entsteht, wodurch ich aber eigl keine nachteile habe.

wäre schön wenn mir einer dies nochmal so bestätigen könnte

Ein gutes Hash-Verfahren (wie z.b. SHA256) + ein Salt, dass für jedes Passwort zufällig generiert wird ist für 99.9% aller Anwendungsfälle vollkommen ausreichend.

Ich dachte eigentlich, dass wir uns einig sind.

Ein standardisiertes Verfahren ist ausreichend, solange der Salt und die Hash-Methode ausreichend sicher ist. Bspw. kann ein unerfahrener Nutzer von Joomal ein relativ unsicheren Salt einstellen.

return '$1$'.substr(md5(mt_rand()), 0, 8).'$';

Also mir wird es bei soetwas ganz schaurig. Kein Wunder dass es diverse Foren gibt, bei denen man "Joomla Hashs" entschlüsseln lassen kann

Falls ich deinen Nachtrag aus Post #22 missverstanden haben sollte, sry^^

Solange der Salt dynamisch gewählt wird, halte ich selbst ein einfaches MD5(Salt + Passwort) noch für halbwegs sicher, wobei das dann schon sehr grenzwertig ist. (Auf moderner Hardware lassen sich mittels GPGPU-Computing schon mehrere Milliarden MD5-Hashs pro Sekunde bilden, weswegen dann das Passwort schon gut sein muss, also > 8 Stellen)

Zum Thema Salt-Generierung kann man sich natürlich ewig streiten, aber 64-Zufallsbits sollten für ein PHP-Login-Script eigentlich ausreichen. (Entspricht dann 8 Byte also 16 Hex-Zeichen)

 

[1668mib]

nur mal so - "zeitgemäß" wäre eigentlich wenn man verstärkt auf Public-Key-Authentifikation setzen würde ;-)
Schade, dass diese Verfahren in der breiten Masse nach wie vor nicht angekommen sind.

 

[QXARE]

Ich würd mich gerne auch näher mit diesem Thema (Hashing, Verschlüsselung usw.) beschäftigen. Hat da jmd. irgendwelche Internetseiten oder Bücher die er empfehlen kann?

 

[Trainmaster]

nur mal so - "zeitgemäß" wäre eigentlich wenn man verstärkt auf Public-Key-Authentifikation setzen würde ;-)

Das hat wahrscheinlich auch seine Gründe. Soll ich meine Private-Keys von den Seiten XYZ ständig mit mir herumtragen wenn ich mich bspw. in einem Internetcafe bei Seite X anmelden will? Das heißt ja auch, dass man als Benutzer die entsprechenden Private-Keys je Seite einrichten muss. Und damit wären wir wieder beim ersten Punkt: was ist, wenn ich mich bspw. bei einem Freund bei Seite X anmelden will? Und es ist ja nicht so, dass Public-Key-Authentifizierung nicht verbreitet ist. Da brauch ich nur meine Onlinebanking-Software anschauen. Nachteil ist eben (was in diesem Fall auch gut so ist), dass ich zur Benutzung meinen Key benötige (z.b. auf einem USB-Stick o.ä.). Die geringe Verwendung im Web hat meiner Meinung nach v.a. Usability-Gründe.

 

[1668mib]

Warum man zwangsläufig bei jeder Seite ein eigenes Key-Paar braucht, musst du mir jetzt aber mal erklären...

Und ja, es liegt hauptsächlich an der Usability, da stimme ich dir dennoch zu.

 

[Trainmaster]

Na dann müssten ja alle Server den gleichen Public-Key haben?

 

[1668mib]

Ähm nein... nur den selben Algorithmus (z.B. RSA).

 

[ice-breaker]

Ich würd mich gerne auch näher mit diesem Thema (Hashing, Verschlüsselung usw.) beschäftigen. Hat da jmd. irgendwelche Internetseiten oder Bücher die er empfehlen kann?

Einführung in die Kryptographie
wird bei uns an der Uni vorlesungsbegleitend als Literatur zu Kryptographie-Vorlesungen empfohlen (stammt von einem unserer Professoren)

Ähm nein... nur den selben Algorithmus (z.B. RSA).

doch müssten sie.
es passt immer nur ein Public und Private-Key zusammen.
Wenn ich nun also einen Key für mehrere Seiten verwenden will, benötigen diese Seiten also jeweils genau den gleichen gegenteiligen Schlüssel aus dem Keypair, und somit ist es wieder hinfällig, das hat dann die gleiche Sicherheit wie ein Passwort für mehrere Seiten zu verwenden.

 

[Trainmaster]

@ 1668mib

Du sagst also, dass man sich mit einem Private-Key auf verschiedenen Seiten anmelden kann?

 

[1668mib]

Dann hast du Public-Key-Kryptographie nicht verstanden bzw nicht, wie die Anmeldung funktioniert...

Public-Key-Authentifizierung sieht so aus:
- Server muss deinen Public-Key kennen - im Grunde kennt den aber die ganze Welt [Schwierigkeit bei Public-Key-Verfahren ist aber meist das sicherstellen, dass ein Public-Key tatsächlich einer Person/Instituition gehört]
- Der Server schickt dir zur Authentifikation eine Zufallszahl
- Diese signierst du (= verschlüsseln mit deinem Private-Key) und schickst sie zurück an den Server
- Jeder auf der Welt kann diese Signatur nun entschlüsseln mit Hilfe deines Public-Keys (das ist auch gut so), der Server macht das, und wenn es der gesendeten Zahl entspricht, dann wurde sie mit dem korrekten Schlüssel signiert => passt

 

[ice-breaker]

äh, sry, ich war gerade gedanklich bei einer anderen Form.
Du willst nur die Authentifizierung durch Signierung machen, das ist in Ordnung.

 

[1668mib]

Darum geht es doch hier eigentlich, oder nicht? :-)