Closed alxndr-w closed 4 years ago
Wie kann man einen prehash Wert von einem unverschlüsselten Passwort unterscheiden?
Laut https://stackoverflow.com/questions/2982059/testing-if-string-is-sha1-in-php
function is_sha1($str) {
return (bool) preg_match('/^[0-9a-f]{40}$/i', $str);
}
Es wird in den allerallerallerallerallerallerallerallerwenigsten Fällen jemand zufällig als Klartext-Passwort ein 40 characters hexadecimal string
verwenden.
Wenn man mit passwort-hash arbeitet, kann man dort die user automatisch auf ein anderes hashing verfahren upgraden. Das macht man in der regel beim login.
Machen wir im backend auch
Siehe auch http://php.net/manual/en/function.password-needs-rehash.php
Hieße das, man könne die YCom-Hashs 1:1 übernehmen, da YCom auf der rex_login-Klasse basiert? (Ich meine, dass das aktuell nicht geht)
Zunächst, gehört das für mich eher in das Projekt selber.
Wenn man mit passwort-hash arbeitet
@staabm ich meine es gab auch noch Varianten ohne hash.
@alexplusde würdest du für dieses Issue einen PR erstellen wollen, der dann alles abdeckt?
Hieße das, man könne die YCom-Hashs 1:1 übernehmen, da YCom auf der rex_login-Klasse basiert? (Ich meine, dass das aktuell nicht geht)
Ich hab keine ahnung wie es aktuell funktioniert. Ich habe nur einen weg gezeigt wie man normalerweise geschickt mit diesem problem umgehen kann
@tbaddade Schwierig, da meine Codezeile ja auf der rex_login-Klasse für R5 basiert und YConverter im R4-Kontext ausgeführt wird. Eine Alternative wäre vielleicht, Das in R5 YCom zur Verfügung zu stellen und es bei YConverter bei einem Hinweis zu belassen? Schließlich wird das R4 Community Addon im Moment sowieso nicht 1:1 für YCom aufbereitet.
@staabm finde es bei deinem Vorschlag kritisch, dass Hashs nicht geupdatet werden, ohne dass sich die Person einloggt. Das könnte dazu führen, dass unsichere Hashs in der Datenbank verweilen.
@staabm finde es bei deinem Vorschlag kritisch, dass Hashs nicht geupdatet werden, ohne dass sich die Person einloggt. Das könnte dazu führen, dass unsichere Hashs in der Datenbank verweilen.
Da man die klartext-passwörter in der regel nicht kennt, gibt es eigentlich keine Alternativen
@staabm ich verstehe unser Missverständnis.
Die rex_login-Klasse kommt damit klar, den Hash neu zu hashen anstelle dem Klartext-Passwort. Damit lassen sich alle alten Hashs direkt in neue Hashs umwandeln, ohne auf einen Login der Person (mit Eingabe des Klartext-Passworts) zu warten.
@staabm ich verstehe unser Missverständnis.
Die rex_login-Klasse kommt damit klar, den Hash neu zu hashen anstelle dem Klartext-Passwort. Damit lassen sich alle alten Hashs direkt in neue Hashs umwandeln, ohne auf einen Login der Person (mit Eingabe des Klartext-Passworts) zu warten.
Ich wüsste nicht dass das geht. Eine Umwandlung des hashes erwartet in der regel einen user der das passwort eingegeben hat im rahmen seines logins
Es ist getestet. Siehe Beispiel zu Beginn des Issues. Ich übergebe einen Hash aus dem R4 community
-Addon und erhalte einen neuen Hash zurück, mit dem ich mich via YCom einloggen kann, wenn ich diesen in die Datenbank zum passenden Benutzer schreibe.
Hier wird nachgesehen, ob das übergebene Passwort prehashed wurde oder nicht: https://github.com/redaxo/redaxo/blob/master/redaxo/src/core/lib/login/login.php#L473-L477
YCom verwendet sha256 (bzw. das aktuell in PHP eingestellte Verfahren), r4 community sha1
Wenn diese bereits in sha1 vorliegen am Beispiel von Passwort
test123
<?= rex_login::passwordHash("07b074b64dcdbcd037bed158228dfa36dcf462ba", true); ?>
(getestet)<?= rex_login::passwordHash("test123", false); ?>
(ungetestet)