Passwörter in plain text in einer Datenbank

[Mathias]

Hey,

beim Arbeiten an meinem Admin Backend stellte sich mir die Frage, wie man so eine 'Einstellungen'-Seite behandelt. Natürlich soll ein Benutzer sein eigenes Passwort aussuchen können. Das kann man ja nun auf fast jeder Website. Ebenso findet man auf vielen Websites, dass das alte Passwort bereits in dem Eingabefeld steht.
Die Frage mag jetzt etwas naiv klingen, aber wie kommt das Passwort dort rein? Passwörter sollten natürlich immer gehashed und vielleicht auch gesalted gespeichert. Die einzige Erklärung für mich ist, dass das Passwort wohl in der Datenbank ebenso in Klartext gespeichert worden ist, um es später dann auszulesen und in das Eingabegfeld als value zu packen.

Gibt es noch andere Erklärungen?

Ist es überhaupt sinnvoll, das Passwort nochmal in das Eingabefeld zu packen? Ich meine, man kann es doch sowieso nicht mehr lesen, da man nur Sternchen sieht.

In Bezug auf Cake müsste man auch die 'edit'-Funktion anpassen, damit am Ende beim Formular absenden kein leeres Passwort gespeichert wird.

Gibt es andere Ansätze, Gedanken oder Hinweise?

[euromark]

passwörter in pLAIN speichern is eine der größten sünden die man nur begehen kann, meiner meinung nach
sie md5 gehashed zu speichern, kommt dem fast genauso nah^^

immer IMMER mindestens sha1

es sind userdaten, die - davon gehen naive standarduser aus - vertraulich behandelt werden (und auch müssen per gesetz).
wenn nun jemand an die datenbank (wie auch immer) herankommt, hat er emails, weitere daten + ein tolles passwort dass dieser user vermutlich
für Email, andere Accounts und am besten noch Ebanking benutzt.
E voila - hat er dank dir den Jackpot geknackt...

wenn er dann noch schlau ist, verrät er dir davon nix - kann weiterhin nette passwörter zum Spammen/GeldAbheben und CO "holen" - und hat sich seine rente gesichert.

nene, also wenn dann wird sowas vom Browser gespeichert und verarbeitet.
ansonsten muss eben der user sein PW eingeben. Anders sollte es nicht sein.

Wenn - dann wird ein solcher gehasherter Wert nochma speziell in Cookies gespeichert
und dann verglichen mit einem hashwert der sich wiederum aus dem gehashed DB passwort berechnet
und dann könnte man darauf hin auto-logins gestalten
aber es hat schon einen grund, warum nicht ma ein admin einer webseite passwörter in plain einsehen darf...

[paul]

Also direkt sinnvoll finde ich es nicht das Passwort da nochmal reinzuschreiben, aber wenn man eine Einstellungsseite baut auf der alle Einstellungen, inkl. Passwort ändern, vorhanden sind, dann wäre es vielleicht nützlich einen Wert in das Passwortfeld zu schreiben um zu überprüfen ob der Benutzer das geändert hat.

Um den Armen DAU dann nicht zu verwirren wenn sein Passwort nur vier Stellen hat, aber 8 im Passwortfeld stehen, würde ich vorschlagen die Anzahl der Zeichen des Passworts in einer Extraspalte zu speichern.
Der Inhalt des Feldes wäre dann sowas wie str_repeat('#', $user['User']['pwdLength']);

Oder meint ihr das ist auch schon eine zu mutige Sicherheitslücke?

[Flo]

ich würde da bevorzugen es leer zu lassen, und nur wenns gefüllt ist es zu ändern,

altes passwort, neues passwort, neues passwort wiederholen.

wobei die passwortfelder im view irgendwelche "sinnfreuen" name="" haben sollten, damit der Browser ja nicht auf die idee kommt die felder von alleine zu füllen, denn das verwirrt

[havanna]

Hallo Mathias,

zu deiner Frage: Ich glaube kaum, dass heute noch jemand Passwörter unverschlüsselt in einer Datenbank speichert.
Jeder Schlüssel kann natürlich entschlüsselt werden (oder anders ausgedrückt: muss entschlüsselt werden können, sonst wäre es ja nicht möglich das Passwort zu verifizieren).
Wenn ich also eine Seite aufrufe, um mein Passwort zu ändern, und dort wird mein altes Passwort angezeigt, dann wurde es ausgelesen und entschlüsselt.
Gut ist das sicher nicht. Denn es könnte in dem Moment ja jemand über meine Schulter schauen, und sehen was ich so als Passwort wähle (Beispiel: bei einem Unternehmen musste ich jeden Monat mein Passwort für Windows und SAP ändern. Konsequenz (damit man sich das merken kann): man nimmt einfach den laufenden Monat mit ins Passwort auf)*.

Ciao Thomas

* Als Berater musste ich mir ca. 20 Passwörter von Kundensystemen merken - da baut man sich natürlich Eselsbrücken

[paul]

Hi Thomas,

es passt zwar nicht mehr ganz zum Thema, aber eine Frage an einen Berater habe ich, da wir in der Agentur gerade einen Beraterbereich planen:

Wie stehst du, und deine Kollegen zu dem Thema OpenID? Unsere Auftraggeber sagen das kennt niemand, aber ich vermute da übertragen sie ihre eigenen Kentnisse auf alle anderen, denn diese (oder ähnliche Techniken) würden dein Problem ja auf einen Schlag lösen.

Würd mich über eine kurze Antwort freuen.


Grüße, Paul

[havanna]

Hallo Paul,

meinst du das mit dem Passwort ändern als "mein Problem"? Wenn du das meinst, verstehe ich den Zusammenhang nicht ganz.

Die Passwortänderung alle vier Wochen betrifft ja Windows und SAP-Anmeldungen. Da wird OpenID (wenn ich das richtig verstanden habe) nichts nützen. Wusste ehrlich gesagt bis eben nicht, was OpenID ist und musste erst einmal googeln.

Es gab (gibt) ja verschiedene Ansätze in dieser Art. SAP verwendet z.B. auf ihrem Service Marketplace ein Zertifikat. Das wird einmal im Browser eingebunden und damit kann ich mich dann immer anmelden (Single-Sign-On). Natürlich funktioniert das Single-Sign-on auch ohne das ich das Zertifikat einbinde. Ein Anmeldeserver im Systemverbund prüft meinen User/Passwort und stellt dann das Cookie ein. Das dürfte in der Art wie OpenID sein. Allerdings ist da der Server, der das Single-Sign-On Zertifikat ausstellt, im eigenen Verbund und nicht irgendwo im WWW.
Bei Unternehmen, die das Enterprise Portal von SAP einsetzen (ein Portal das die unterschiedlichen Systeme (ERP, BI, CRM) unter einer Oberfläche einbindet) ist das Standard.

Insofern solltest du bei euren Auftraggebern noch einmal nachfragen. Vielleicht kennen Sie die Technik - aber unter einem anderen Namen.

Ciao Thomas

[paul]

Ich habe mit "deinem Problem" deine Fußnote gemeint. 20 verschiedene Passwörter für div. Kundensysteme. Wenn die alle OpenID verstehen würden, bräuchtest du nur noch ein Passwort.

Jetzt läuft es bei uns jedenfalls wieder darauf hinaus das sich der geneigte Berater ein neues Passwort anlegen muss. Na, wems gefällt. Danke für die Antwort & schöne Grüße.