Gerade bemerkte ich eine Lustige Angewohnheit der Auth-Component von CakePHP.
Nehmen wir an wir haben eine Userregistration, also mit Feldern wie Username, Password, E-Mail usw. nun trägt der User alles richtig ein, nur bei der E-Mail vertippt er sich bzw. trägt dort keine valide Mailadresse ein. Da ich natürlich in CakePHP auf das Feld eine ValidationRule gelegt habe die besagt das in das Feld nur valide Mailadressen eingetragen werden dürfen schlägt Cake Alarm und quittiert den Versuch mit einer Fehlermeldung.
Da Cake schlau ist füllt es alle Felder automatisch mit den zuvor eingegebenen Werten wieder aus, damit man auch wirklich nur das fehlerhafte Feld neu bestücken muss. Das lustige ist jedoch das die Auth-Component in das Passwort-Feld bereits den MD5-Hash als value übergibt. Merkt man das nicht und korrigiert nur das eigentlich fehlerhafte Feld, so wird der MD5-Hash nochmal in einen MD5-Hash verwandelt und man kann sich somit nicht mit dem angelegten Account einloggen. Für mich ist das ein klarer Bug, denn die Auth-Component sollte natürlich prüfen ob die Validierung einen Alarm ausgelöst hat, und nur falls alles Ok ist sollte der Wert in MD5 umgewandelt werden.
Im IRC-Channel zu CakePHP wurde mir nun gesagt ich solle doch einfach das Passwordfeld generell leer halten, denn das sei schließlich vollkommen normal das man bei einem Validierungsfehler auch die Passwörter nocheinmal eintragen müsse. Ja klar, das machen zwar einige Portale so, doch mich persönlich nervt das einfach gewaltig.
Sicherlich ist es unsicher das Passwort in das value zu setzen, doch ist sowas doch bei einer Adminoberfläche die nur 2-3 Personen nutzen zu vernachlässigen. Warum wird da ein offensichtlicher Bug also so bekämpft?
Eine Lösung habe ich dafür leider nicht, außer dem Feld dauerhaft ein value="" mit auf den Weg zu geben, damit eben das Feld bei einer Falscheingabe statt dem MD5-Hash wenigsten nichts beinhaltet und somit wieder Alarm schlägt falls man es versehentlich leer lässt.
Wie seht ihr das? Sollte man ein Passwordfeld bei einer Fehlerausgabe wieder mit dem Eingabewert befüllen oder den Nutzer nochmals dazu auffordern sein Passwort einzugeben, obwohl es ja eigentlich die Validierung absolviert hat?
Kommentare zum Thema Unterschiedliche Meinung über Passwortfelder:
@Michael Wieso ist ein ausgefülltes Passwortfeld ein Bug? Wenn ich eine Anmeldung durchziehe, und bekomme z.b. zum dritten mal die Meldung das mein Benutzername schon vergeben ist, dann muss ich ja 3x mein Passwort das ich für die Applikation will neu eingeben, da es ja auch noch eine Passwort-Verifikation geben muss wahrscheinlich eher 8x.
Nach dem das Passwort ja in der DB ist ist klar das man es nicht mehr als value ausgeben kann und darf, aber während einer einmaligen Registration? Ich finde irgendwie schon das da die Vorteile für den Nutzer überwiegen. Ich meine wie oft kommt es denn vor das jemand mitten im Registrationsprozess den Browser offen stehen lässt und dann jemand böses auf die Idee kommt im value-Feld nach dem gerade eingegebenem Passwort zu gucken?
Ok, da gehen die Meinungen wohl auseinander, aber schon doof das einem die Möglichkeit genommen wird.
Mich nervt es auch kolossal, wenn das Passwort bei einer Registrierung nach einer Fehleingabe wieder weg ist, ganz besonders, wenn der Benutzername nicht schon vorher per AJAX geprüft wird. Ich sehe da auch überhaupt kein Sicherheitsproblem, warum auch? Der Applikation ist es zu dem Zeitpunkt völlig wurst, was der Nutzer da eingibt.
Falls einem das trotzdem widerstrebt, schlage ich eine Hybridlösung vor: Übertragung und Überprüfung der eingegebenen Daten per AJAX und wenn es kein JavaScript gibt, eben ein normales Formular mit serverseitiger Validierung und leerem Passwortfeld im Fehlerfall. Damit müssten alle glücklich sein und die User ohne JavaScript müssen im Zweifel halt ihr Passwort noch mal eingeben.
Ich persoenlich finde es auch nervig das Passwort immer und immer wieder eingeben zu muessen und wie Christian schon angemerkt hat wird sich wohl niemand irgendwo registrieren und dann mitten im Registrierungsprozess seinen PC verlassen beziehungsweise werden wahrscheinlich die wenigsten Leute im Quellcode die Values auslesen.
Meiner Meinung nach ist das ein Bug, schade nur, dass die CakePHP-Entwickler das nicht auch so sehen, aber Nathanaels Loesungsansatz gefaellt mir. Und mal ehrlich, wer surft heutzutage mit deaktiviertem JavaScript, bei all den vielen AJAX-Anwendungen? (Das ist eine rhetorische Frage, ich will da jetzt keine Antwort drauf haben).
Ich empfinde die Neusetzung des Passwortes als unsicher. Egal ob “nur 2-3” Leute oder eben 500 sich registrieren. Ein Bug ist es natürlich den Du beschreibst, aber zur grundsätzlichen Frage “soll man Passwortfelder immer leeren” sag ich klar ja.
@Christian
Es geht nicht nur um einen Offen-Stehenden Browser sondern auch um mögliche XSS-Angriffe. Diese sehen diese Passworte natürlich als super Chance.
Nächtes Problem sind öffentliche PCs. Geh mal in deine Uni, oder deine Stadtbücherei, oder ein Internetkaffee und wühle im Cache. Das kann richtig lustig sein.
Und Passworte könnte man so auch sammeln. Daher ist es nicht ratsam, dass Passwort im Quelltext stehen zu lassen.
Kommentar-Feed für diesen Artikel
Ich empfinde das als klaren Bug. Allerdings finde ich, dass das Feld automatisch mit nichts ausgefüllt werden sollte.
Ein ausgefülltes Passwort-Feld ist schließlich ein Bug, den man nicht runterspielen sollte.