[TYPO3-german] Problem mit saltedpasswords und rsaauth: einige BE-User verwenden weiterhin MD5-Hash-Passwords

[Michael]

On 06/01/12 19:58, Steffen Gebert wrote:

>> "[...] The backend is configured to use SaltedPasswords over SSL"
[...]
> Das wäre schon mal ein Ansatzpunkt. Aber nein, das Backend über SSL
> laufen zu lassen und dafür kein rsaauth zu verwenden ist natürlich
> völlig legitim. Es geht ja nur darum, dass das Passwort nicht im
> Klartext durch die Leitung geht.

Nun, ich frage mich sowieso warum es eine Abhaengigkeit zwischen
saltedpasswords and rsaauth gibt. Wenn die primaere Aufgabe von
saltedpasswords darin besteht, sich um das "Format" der Passwoerter in
der DB zu kuemmern - und die Aufgabe von rsaauth ist, das eingegebene
Passwort auf der client-Seite mit dem public key des Servers zu
verschluesselt, bevor es uebertragen wird... wozu setzt saltedpassword
dann unbedingt rsaauth voraus?

Aber noch einmal zurueck zu dem Problem von Markus: mir ist noch ein
Ansatzpunkt eingefallen.

In der Standardinstallation von 4.5.x wird die DB mit be_users.password
als VARCHAR(40) DEFAULT NULL erzeugt (reicht fuer einen 32-Zeichen
langen MD5 Hash). Waehrend der Installation von saltedpasswords wird
dieses Attribut auf VARCHAR(60) erhoeht (ALTER TABLE...).

Mal angenommen, der ALTER TABLE... wurde bei Markus nicht ausgefuehrt
(warum auch immer), dann kann saltedpasswords (bzw. der Scheduler Task)
moeglicherweise den (laengeren) salted-hash nicht korrekt speichern.

Als ich diesen Fall bei mir getestet habe, fuehrte das allerdings nicht
zu dem selben Verhalten, wie bei Markus, sondern der neue Hash wurde
einfach gekuerzt in die DB geschrieben (was auch nicht schoen ist, da
das Passwort dadurch zerstoert wird... aber es wurde wenigstens was
geschrieben).

@Markus: du koenntest mal pruefen, wie die DB bei dir aussieht.
Insbesondere die Tabelle "be_users" und hier das Attribut "password".

Cheers
Michael