Ist: Eine fe_user Gruppe deren Passwörter verschlüsselt werden, dazu eine newloginbox in der User sich anmelden.
Lustigerweise speichert Firefox nicht das Passwort der User ab, zumindest nicht das korrekte Passwort, der IE macht es ebenso falsch.
Da die meisten User natürlich ihre Usernamen und Passwörter im Browser speichern, ist das nicht so gut.
Hatte jemand bereits das Vergnügenauf dieses Problem zu treffen?
Hi,
hab das gleiche Problem. Hast du schon eine Lösung dafür gefunden?
Mephisto87
ist noch keinem das Problem aufgefallen?
Mfg
nein, ich habe das Problem nicht.
Ganz wichtig ist, das kb_md5fepw als letztes installiert ist, sonst greift der Mechanismus nicht. Also einfach deinstallieren und neu installieren.
mhh das problem besteht auch nach der deinstallation und neuinstallation von kb_md5fepw noch.
noch mal das Problem genau:
ich gebe Name und Passwort im Firefox ein und wähle beim Passwort-Manager "Speichern" aus.
Was dann besonders auffällig ist, dass nach dem Klick auf Anmelden das Passwort mit z.b. 6 Sternchen auf 20 Sternchen verlängert wird, bis das Formularfeld voll ist. Das PW akzeptiert er (Anmeldung geht), er füllt nur das Feld irgendwie.
Ist das normal?
weil wenn ich dann die Seite später aufrufe und Benutzername und Passwort noch gespeichert sind, ist das Passwortfeld schon voll mit den ca 20 Sternchen und die Anmeldung bringt einen "Anmeldefehler". #paralyzed#
verstanden, was ich meine?;-) sonst kann ich auch mal ein bild davon online stellen.
Mephisto
das Verhalten ist normal - die JS-Routine superchallange kodiert das Passwort, damit das login auch funktioniert.
Probiers mal ohne Passwortmanager
na wenn ich das Passwort nicht speichere, steht es beim Aufruf der Seite auch nicht drin. Somit muss der User es jedes mal neu eingeben und somit kommt es nicht zu diesem Fehler.
Viele User machen es sich aber einfach und Speichern hier und da ihre Passwörter.
nagut dann gibt es wohl dafür keine Lösung... 🙁
Habe auch das Problem noch, allerdings nur im IE:
Wir verwenden die newloginbox mit kb_md5fepw als mit MD5-Verschlüsselung. Wenn ich im IE per Hand die Logindaten eingebe dann kann ich mich auch im IE einloggen. Aber wenn ich mit dem IE (egal ob 6 oder 7) das Passwort speichere dann kann ich mich beim nächsten mal nicht anmelden.
Es erscheint dann eine Abfrage vom IE:
"Das angegebene Kennwort stimmt nicht mit dem für diesen Benutzer gespeicherten Kennwort überein. Möchten Sie das gespeicherte Kennwort in den neuen Eintrag ändern?"
Egal ob ich jetzt JA oder NEIN sage, das Passwort wird im IE falsch gespeichert und ich kann mich nicht mehr einloggen. Wenn ich dann wieder das Passwort per Hand eingebe dann kann ich mich wieder einloggen.
Habe von allen beteiligten Ext die neueste Version laufen.
Im Firefox klappt alles beim Einloggen und Passwort speichern wunderbar. Ist das ein bekannter Bug? Kann jemand das Problem reproduzieren?
Hallo!
Wie Steffen schon andeutete: Das PW wird von einer JavaScript-Routine vor dem Senden verschlüsselt. Daher speichen die Browser dieses verschlüsselte PW ab. Beim automatischen Ausfüllen steht dann beim nächsten Versuch das schon verschlüsselte PW im Feld und wird nochmals MD5-verschlüsselt --> PW stimmen nicht überein.
Viele Grüße
Michael
dann arbeitet man aber in diesem fall im IE vorbei,halte ich für nicht so gut. klar müsste es der IE so machen wir der FF, aber wenn man weiss dass dieser bug im IE da ist....
vielleicht der falsche js-event um die verschlüsselung zu machen?
Hallo Leute
Habe gerade auch dieses Problem.
Beim Testen (leider nur mit dem FF) ist alles gut gegangen.
Nur leider sind in diesem Fall alles Verwaltungsangestellte
die sich mit dem IE 6 bzw IE 7 einloggen und jezt Probleme
damit haben, wiel sie Benutzernamen und Passwort auch
speichern wollen.
Hat jemand eine Lösung oder einen "Würgaround" gefunden
Viele Grüsse
Jonas
Na die Lösung dürfte doch wohl sein, dass das Passwort erst nach dem Senden verschlüsselt wird. Aber das macht ja dann eigentlich keinen Sinn mehr!
Daniel
Hi
Also ich habe einen Weg gefunden.
Man muss das JavaScript und die HTML-Vorlage anpassen.
Also, wenn das noch nicht gemacht wurde, die HTML-Vorlage der Erweiterung newloginbox nach fileadmin/templates kopieren, und per TS einbinden.
plugin.tx_newloginbox_pi1 {
storagePid = [PID mit den FE-Usern]
templateFile = fileadmin/templates/html/newloginbox.html
}
Dann bei der HTML-Vorlage aus dem <input type="password" /> ein <input type="hidden.." /> machen und ein neues <input type="password" einfügen.
Also so etwas: (bei TEMPLATE_LOGIN)
Original:
<input type="password" id="pass" name="pass" value="" />
Angepasst:
<input type="hidden" id="pass" name="pass" value="" />
<input type="password" id="pass_fe" name="pass_fe" value="" />
Dann muss man leider den Code der Erweiterung bearbeiten.
Und zwar die Datei class.tx_kbmd5fepw_newloginbox.php
in typo3conf/ext/kb_md5fepw
Dort wird ab Zeile 63 das JavaScript definiert, welches bei der Seite eingefügt wird.
Und zwar muss man aus dem
var pass = form.pass.value;
ein
var pass = form.pass_fe.value;
machen
Also so etwas dann:
function superchallenge_pass(form) {
var pass = form.pass_fe.value;
if (pass) {
var enc_pass = MD5(pass);
var str = form.user.value+":"+enc_pass+":"+form.challenge.value;
form.pass.value = MD5(str);
return true;
} else {
return false;
}
}
Wenn wir das so laufen lassen wird wohl das Passwort wieder im Klartext mit übermittelt. Bei meiner Site ist das nicht so wichtig, weil sie noch per SSL (https) geschützt ist. Wir setzen die kb_md5fepw ein, damit im Backend und in der Datenbank die Passwörter nicht als Reintext sichtbar sind.
Okay, hoffe es hilft.
Gebt doch feedbacks, wenns bei euch auch funktioniert. (oder wenn es nicht funktioniert)
Viele Grüsse
Jonas
bin endlich dazugekommen auch mal deinen Hinweis zu übernehmen. Klappt einwandfrei.
Allerdings ist das Problem dann noch bei der Registrierung da. Müsste man im User-Reg-Form folgenden Teil:
<!-- ###SUB_INCLUDED_FIELD_password### -->
<dt>
<label for="tx-srfeuserregister-pi1-password">###LABEL_PASSWORD### ###REQUIRED_PASSWORD###</label>
</dt>
<dd>
<!-- ###SUB_ERROR_FIELD_password### -->
<p class="tx-srfeuserregister-pi1-error">###EVAL_ERROR_FIELD_password###</p>
<!-- ###SUB_ERROR_FIELD_password### -->
<!-- ###SUB_REQUIRED_FIELD_password### -->
<p class="tx-srfeuserregister-pi1-error">###MISSING_PASSWORD###</p>
<!-- ###SUB_REQUIRED_FIELD_password### -->
<input id="tx-srfeuserregister-pi1-password" type="password" size="10" maxlength="40" title="###TOOLTIP_PASSWORD###" name="FE[fe_users][password]" class="tx-srfeuserregister-pi1-password" />
</dd>
<dt>
<label for="tx-srfeuserregister-pi1-password_again" class="tx-srfeuserregister-pi1-password-again">###LABEL_PASSWORD_REPEAT###</label>
</dt>
<dd>
<input id="tx-srfeuserregister-pi1-password_again" type="password" size="10" maxlength="40" title="###LABEL_TOOLTIP_PASSWORD_AGAIN###" name="FE[fe_users][password_again]" class="tx-srfeuserregister-pi1-password" />
</dd>
<!-- ###SUB_INCLUDED_FIELD_password### -->
in sowas ändern?
<!-- ###SUB_INCLUDED_FIELD_password### -->
<dt>
<label for="tx-srfeuserregister-pi1-password">###LABEL_PASSWORD### ###REQUIRED_PASSWORD###</label>
</dt>
<dd>
<!-- ###SUB_ERROR_FIELD_password### -->
<p class="tx-srfeuserregister-pi1-error">###EVAL_ERROR_FIELD_password###</p>
<!-- ###SUB_ERROR_FIELD_password### -->
<!-- ###SUB_REQUIRED_FIELD_password### -->
<p class="tx-srfeuserregister-pi1-error">###MISSING_PASSWORD###</p>
<!-- ###SUB_REQUIRED_FIELD_password### -->
<input type="hidden" id="tx-srfeuserregister-pi1-password" name="FE[fe_users][password]" value="" />
<input id="tx-srfeuserregister-pi1-password" type="password" size="10" maxlength="40" title="###TOOLTIP_PASSWORD###" name="FE[fe_users][password]" class="tx-srfeuserregister-pi1-password" />
</dd>
<dt>
<label for="tx-srfeuserregister-pi1-password_again" class="tx-srfeuserregister-pi1-password-again">###LABEL_PASSWORD_REPEAT###</label>
</dt>
<dd>
<input id="tx-srfeuserregister-pi1-password_again" type="password" size="10" maxlength="40" title="###LABEL_TOOLTIP_PASSWORD_AGAIN###" name="FE[fe_users][password_again]" class="tx-srfeuserregister-pi1-password" />
</dd>
<!-- ###SUB_INCLUDED_FIELD_password### -->
Ansonsten Vielen Dank für deine Lösung!!!
Gruß
Nicklas
Hmm?! Welchen Vorteil soll es bringen, das Passwort VOR dem Senden zu verschlüsseln (btw: MD5 ist ein Hash und keine Verschlüsselung)?
Falls ein böser Dritter das Passwort ablauscht, kommt er also nicht in Besitz des "geheimen Passworts", sondern stattdessen erhält er den MD5-Hash. Soweit so gut. Aber genau dieser MD5-Hash ist ja der Schlüssel zum Glück, man darf ihn halt nur nicht nochmal hashen... ?!
Was sinnvoll ist: Passwort im Klartext über eine sichere Leitung übermitteln, auf dem Server hashen und mit dem Hash in der Datenbank vergleichen. Falls die Datenbank korrumpiert wird, hat der Angreifer: genau, nix!
Den Umweg über browserbasierte JS-Hasherei verstehe ich aus Informatikersicht überhaupt nicht. Mag mich jemand eines besseren belehren? #paralyzed#
Gruß
Marc
edit: Rechtschreibfehler entfernt (hoffentlich alle *gg*). Die bleiben hier!
marc-willmann schriebHmm?! Welchen Vorteil soll es bringen, das Passwort VOR dem Senden zu verschlüsseln (btw: MD5 ist ein Hash und keine Verschlüsselung)?
Den Umweg über browserbasierte JS-Hasherei verstehe ich aus Informatikersicht überhaupt nicht. Mag mich jemand eines besseren belehren? #paralyzed#
Weil ich auch grad über das IE-Problem gestolpert bin, will ich es mal versuchen! 😉
Zunächst ist es vollkommen richtig, daß die SSL-Verschlüsselung den besten Schutz bietet. Aber nicht jeder kann und will sich ein SSL-Zertifikat leisten. Um seinen Nutzern wenigstens einigermaßen Sicherheit zu bieten, ist eine verschlüsselte Übertragung des Passworts daher ein sinnvoller Ansatz. Zwar kann ein Angreifer diesen Hashwert dann mitlesen, und sich so ggf. Zugriff zum System verschaffen, aber er kann eben nicht das eigentliche Passwort einsehen. Dies wäre deutlich kritischer, weil viele Anwender das selbe Passwort in verschiedenen Portalen verwenden.
Davon abgesehen ist auch die Wahrscheinlichkeit mit dem abgefangenen MD5-Hash in das betroffene System einzudringen sehr gering. Der Hashwert ist nämlich bei jedem Zugriff unterschiedlich und erlaubt nur genau eine Anmeldung am System. Danach verfällt dieser HashWert. Dafür sorgt die zusätzliche Verwendung des challenge-Werts.
Insgesamt ist diese Art der Schutzes also schon deutlich mehr als nur reine Spielerei. Auch aus Informatikersicht! 😉