password_needs_rehash

[Floezen]

Hallo,

ich benutze die password_needs_rehash Funktion um Passwort-Hashes möglichst sicher in der User-Datenbank zu speichern.

if (password_verify($pass, $dbpass)) {
              
              if (password_needs_rehash($hash, PASSWORD_DEFAULT)) {
                $hash = password_hash($pass, PASSWORD_DEFAULT);
                     // Speichere neues Hash in DB...
} 

Ich habe diese Funktion eigentlich so verstanden, dass Sie nur dann ein neuen Hash anlegt, wenn der alte Hash einem einfacheren Algorithmus entstammt.

Bei mir wird aber interessanter Weise jedes mal ein neuer Hash angelegt...

Das ist zwar irgendwie sicher, aber verhindert, dass ein Nutzer via Cookie (mit Hash-Information) auf zwei Browsern/Rechner eingeloggt sein kann.

Habe ich die Funktion falsch verstanden oder liegt der Fehler wo anders?

Danke
Flözen

[tr0y]

Keine Ahnung was deine Datenbank noch so mit dem hash anstellt, aber..

$pw = password_hash('foobarbaz', PASSWORD_DEFAULT);

var_dump( password_needs_rehash($pw, PASSWORD_DEFAULT) ); 

ergibt false.

[Floezen]

Ohje... die eigenen Fehler finden sich besonders schwer...

Jetzt klapp es...

if (password_verify($pass, $dbpass)) { 
               
              if (password_needs_rehash($dbpass, PASSWORD_DEFAULT)) { 
                $hash = password_hash($pass, PASSWORD_DEFAULT); 
                     // Speichere neues Hash in DB... 
} 

Thanks anyway

[ChrisvA]

Das ist zwar irgendwie sicher, aber verhindert, dass ein Nutzer via Cookie (mit Hash-Information) auf zwei Browsern/Rechner eingeloggt sein kann.

Jetzt sag bitte nicht, dass du im Cookie den Passwort-Hash speicherst....

[Floezen]

Jetzt sag bitte nicht, dass du im Cookie den Passwort-Hash speicherst....

Na klar. Ich sehe da auch ein größeres Sicherheitsrisiko.

Natürlich nehme ich nicht den gesamten Hash. Da der aber über 40 Zeichen lang ist, kann man sich bequem einen Ausschnitt daraus ziehen und für den Vergleich in das Cookie einfügen. (Logischerweise nicht die ersten Zeichen ) Mit 10-20 Zeichen hat man schon ein recht sicheres Passwort.
Damit überhaupt der Inhalt des Cookies etwas geschützt wird, verschlüssele ich diesen per AES256…

Da über unsere Seite weder Bankgeschäfte noch Kreditkartengeschäfte abgewickelt werden, sollte das ein ausreichender Schutz sein.

[tr0y]

Au Backe. Das Hash-Fragmente kollidieren können ist dir bewusst ?

[ChrisvA]

Anstatt dir Dinge auszudenken, mit denen du eine "sichere" Authentifizierung erreichst würde ich dir empfehlen dich in Sessions einzulesen, damit kann man diese Funktionalität erheblich besser erreichen.

[Floezen]

Au Backe. Das Hash-Fragmente kollidieren können ist dir bewusst ?

Was meinst Du damit? Dass es zwei mal die gleichen Fragmente gibt???

Na und? Zur Validierung gehört immernoch der Name.

Aber allein bei einem 20 stelligen rein alphabetischem Hash liegt die Wahrscheinlichkeit bei 26 hoch 20, dass es sich doppelt.

Da ist es leichter, Passwörter zu erraten...

Anstatt dir Dinge auszudenken, mit denen du eine "sichere" Authentifizierung erreichst würde ich dir empfehlen dich in Sessions einzulesen, damit kann man diese Funktionalität erheblich besser erreichen.

Wenn ich mich nicht irre, müsste der Nutzer sich bei der Nutzung von Sessions täglich neu einloggen, aber das sollte aus bequemlichkeit für den Nutzer vermieden werden.

Diese Forum (vBulletin) nutzt für diese Funktion m.E. auch Cookies?!

[Floezen]

P.S. Eigentlich geht es bei der Verschlüsselung ja auch vielmehr um den Schutz des Passwortes des Nutzers, als um den Schutz der Website.
Auf der Website kann, wie hier im Forum, nur ein relativ geringer Schaden durch die Nutzung eines fremden Kontos angerichtet werden, bzw. es lohnt sich eigentlich nicht, ein fremdes Konto zu missbrauchen, bzw. dafür wäre der Aufwand unverhältnismaßig hoch....

[tr0y]

Du siehst hashes als zufällige Zeichenkette, was nicht der Fall ist. Egal was du tust, Cookies als Password-Storage ist definitiv der falsche Weg.

[monolith]

Wenn er noch Salt hinzufügt passt's aber (sofern ich den Diskussionsgegenstand richtig verstanden habe).

Dennoch Floezen, statt des ganzen Aufwands könntest du auch einfach ein eigenes, sich veränderndes token extra für die Nutzung in Cookies verwenden.

[Floezen]

Du siehst hashes als zufällige Zeichenkette, was nicht der Fall ist. Egal was du tust, Cookies als Password-Storage ist definitiv der falsche Weg.

Dann sollte dieses Forum dringend geschlossen werden!


Also mal ernsthaft, was wäre denn eine sinnvolle Methode, dem Nutzer den Komfort des "Eingelogged bleibens" zu ermöglichen und Sicherheit?

Um Cookies komme ich nicht herum.
Bei einiger Recherche im Internet habe ich Vorschläge gefunden, eine Datenbank mit durch den Server vergebene "Cookie-Passwörter" anzulegen, allerdings entgeht mir der dadurch entstehende Sicherheitszuwachs.

Wenn ich dieses Cookie abgreifen kann, habe ich den gleichen Zugriff auf das Webangebot, wie bei allen andern cookie-basierten Angeboten.
Einziger Vorteil: Das echte Nutzer-Passwort bleibt beim Cookie-Klau sicher.

Dann kann ich aber genausogut Hash-Fragmente nutzen, da über diese auch kein Passwort ermitteln werden kann.
Im besten Fall könnte ich die möglichen Passwörter auf einige Millionen reduzieren, da der Hash aber gesalzen ist und dem potentiellen Abgreifer über den Hash-Ausschnitt weder der genutzte Algorithmus noch das Salt bekannt ist, hilft das nicht wirklich weiter.
Also – das Nutzer-Passwort ist auch sicher.

Natürlich sind Sessions sicherer, bieten aber weniger Komfort.


Über gute Lösungsvorschläge mit entsprechendem Nutzerkomfort freue ich mich natürlich!

[Floezen]

Dennoch Floezen, statt des ganzen Aufwands könntest du auch einfach ein eigenes, sich veränderndes token extra für die Nutzung in Cookies verwenden.

Ja, das wäre die Alternative gewesen. Allerdings hätte dieser Token, wie von mir gerade beschrieben, in einer eigenen Datenbank abgespeichert werden müssen. Die Datenbank würde also jedesmal wenn der Nutzer einen anderen Browser oder Computer benutzt einen weiteren Eintrag bekommen.

Da ich das Cookie sowieso verschlüssen möchte, ist der AES256 Codier- und Dekodierrechenaufwand im Vergleich zu einer DB Abfrage kein Rechenleistungsproblem.
Die Zeilen im Quellcode dürften für beide Methoden ähnlich viele sein.

[tr0y]

Sessions bieten den Vorteil, Userbezogene Daten für den Verlauf der Session vorzuhalten über mehrere Requests hinweg.

Cookies dienen als Status-Storage für Clientseitige Dinge die vom Server gesetzt und manipuliert werden können. Sessions können sich dieser Mechanik bedienen und eine nicht Authentificationsbezogene ID zur wiedererkennung dort speichern, aber auch da gibt es Alternativen: SuperCookies.

http://de.wikipedia.org/wiki/Web_Storage

Der von dir angestrebte Weg ist fragiler als Browser-Fingerprinting, wobei Fingerprinting eine eindeutigere Identification eines Clients anstrebt und dabei keine Authentication Credentials sich ausleiht.

Fingerprinting ermöglicht eine beinahe Kollisionsfreie Wiedererkennung eines Browsers ( nicht einer Session ), falls du dich dafür später mal ( bspw. für public voting ) interessierst: http://valve.github.io/fingerprintjs/

In Summe: Dinge die man für die Authentification nutzt transportiert man nicht zurück zum Client, auch nicht gehashed, als Schnittchen, in Form von Gummibären oder als Picasso-Briefmarke.

[Floezen]

Und Dein Vorschlag für heute, bei dem man nicht gut 5%-10% der Nutzer ausschließt?