16
Userverwaltung
Hallo zusammen,
ich brauche mal eine Meinung.
Ich habe eine Userverwaltung. Also eine simple Webanwendung mit Login. In der Tabelle stehen halt Name, Vorname, Benutzername, usw. und das verschlüsselte Passwort.
Als Schema habe ich 1.Buchstabe vom Vornamen + Nachname hinterlegt. Also Klaus Meyer -> KMeyer, Lisa Müller -> LMüller. Zusätzlich eine Gruppenzugehörigkeit.
Wenn der User angelegt wird, wird ein Passwortsheet generiert mit Benutzername, Name und Kennwort, sowie einigen Hinweisen.
Wenn nun der User heiratet oder die Gruppe wechseln soll, wird aus Klaus Meyer uU Klaus Schmidt -> KSchmidt oder Lisa Müller soll in die Gruppe Verwalter kommen.
Wenn ich dem User dann ein neues Passwortsheet geben möchte, wird es schwierig, da ich nur das verschlüsselte Passwort in der Datenbank habe.
Der User hat sich aber an sein altes Kennwort gewöhnt, welches ich ihm nicht nehmen möchte.
Nun habe ich die Möglichkeit, dass der User sich selber Notizen auf sein altes Sheet macht. Aber das ist fehleranfällig. Stichwort: l (kleines "L") I (großes "i").
Oder tatsächlich neue Daten vergeben. Wie regelt man sowas am besten? Amazon & Co. geben kein Sheet raus und vertrauen dass der Use sich die Daten notiert.
mfG
tsunami
ich brauche mal eine Meinung.
Ich habe eine Userverwaltung. Also eine simple Webanwendung mit Login. In der Tabelle stehen halt Name, Vorname, Benutzername, usw. und das verschlüsselte Passwort.
Als Schema habe ich 1.Buchstabe vom Vornamen + Nachname hinterlegt. Also Klaus Meyer -> KMeyer, Lisa Müller -> LMüller. Zusätzlich eine Gruppenzugehörigkeit.
Wenn der User angelegt wird, wird ein Passwortsheet generiert mit Benutzername, Name und Kennwort, sowie einigen Hinweisen.
Wenn nun der User heiratet oder die Gruppe wechseln soll, wird aus Klaus Meyer uU Klaus Schmidt -> KSchmidt oder Lisa Müller soll in die Gruppe Verwalter kommen.
Wenn ich dem User dann ein neues Passwortsheet geben möchte, wird es schwierig, da ich nur das verschlüsselte Passwort in der Datenbank habe.
Der User hat sich aber an sein altes Kennwort gewöhnt, welches ich ihm nicht nehmen möchte.
Nun habe ich die Möglichkeit, dass der User sich selber Notizen auf sein altes Sheet macht. Aber das ist fehleranfällig. Stichwort: l (kleines "L") I (großes "i").
Oder tatsächlich neue Daten vergeben. Wie regelt man sowas am besten? Amazon & Co. geben kein Sheet raus und vertrauen dass der Use sich die Daten notiert.
mfG
tsunami
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 2881452895
Url: https://administrator.de/contentid/2881452895
Printed on: April 28, 2024 at 09:04 o'clock
16 Comments
Latest comment
Moin,
ich verstehe dein Problem nicht ganz. Das PW wird einmalig bei Anlage mitgeteilt. Bei Namens-/Gruppenänderung dann nicht mehr.
lg,
Slainte
ich verstehe dein Problem nicht ganz. Das PW wird einmalig bei Anlage mitgeteilt. Bei Namens-/Gruppenänderung dann nicht mehr.
lg,
Slainte
Moin,
Korrekt. Am Vortag der Namensänderung sendet man noch schnell eine E-Mail und lässt sich den Erhalt bestätigen. Inhalt:
Gruß
em-pie
Zitat von @SlainteMhath:
Moin,
ich verstehe dein Problem nicht ganz. Das PW wird einmalig bei Anlage mitgeteilt. Bei Namens-/Gruppenänderung dann nicht mehr.
lg,
Slainte
Moin,
ich verstehe dein Problem nicht ganz. Das PW wird einmalig bei Anlage mitgeteilt. Bei Namens-/Gruppenänderung dann nicht mehr.
lg,
Slainte
Korrekt. Am Vortag der Namensänderung sendet man noch schnell eine E-Mail und lässt sich den Erhalt bestätigen. Inhalt:
Guten Tag Herr Schmidt,
Morgen ändern wir Ihren Anmeldenamen von KMayer auf KSchmidt, zudem kommen die E-Mails an K.Mayer@company.tld weiterhin bei Ihnen an, Ihre primäre Adresse lautet ab morgen jedoch K.Schmidt@compyna.tld.
Gruß und Kuss, Ihr Julius.
Gruß
em-pie
1
Genau, damit wird das gespeicherte Passwort der UUID zugewiesen und, wenn sich der Name ändert, ändert sich nicht die UUID.
Du kannst aber auch den gespeicherten Hash Wert (Passwort) des alten Users in die Zeile des neuen Users kopieren / überschreiben, dann hat der neue User das selbe Passwort (bzw seinen alten Hash Wert) wieder.
Du kannst aber auch den gespeicherten Hash Wert (Passwort) des alten Users in die Zeile des neuen Users kopieren / überschreiben, dann hat der neue User das selbe Passwort (bzw seinen alten Hash Wert) wieder.
Also:
E-Mail ist uU schwierig, da nicht jeder mit E-Mail arbeitet.
Also: Benutzer Klaus Meyer wird angelegt.
Es wird ein Sheet generiert:
Sehr geehrter Herr Klaus Meyer für Ihren Zugang zum System xy wurde am 22.02.22 ein Zugang mit folgenden Daten generiert:
URL: https://blah.de
Gruppe lesen
Benutzername: KMeyer
Kennwort: asdfASfjl7756((
Blah Blah Bla.
Das Kennwort ist aus Sicherheitgründen in der DB verschlüsselt gespeichert. Nun müsste nach einer Änderung ein neues Sheet generiert werden.
Sehr geehrter Herr Klaus Schmidt für Ihren Zugang zum System xy wurde am 23.05.22 ein Zugang mit folgenden Daten generiert:
URL: https://blah.de
Gruppe Verwalter
Benutzername: KSchmidt
Kennwort: asdfASfjl7756((
Blah Blah Bla.
So das ursprüngliche Kennwort habe ich nicht. Das Sheet finde ich praktisch, weil oftmals wird es sonst auf irgendeinen Zettel gekritzelt und der ist nach 2 Tagen weg. Überlasse ich es dem user habe ich 12345 als Kennwort. Das Sheet kann er sich zumindest in den verschlossenen Schreibtisch legen.
Zitat von @tsunami:
Wenn der User angelegt wird, wird ein Passwortsheet generiert mit Benutzername, Name und Kennwort, sowie einigen Hinweisen.
Wenn der User angelegt wird, wird ein Passwortsheet generiert mit Benutzername, Name und Kennwort, sowie einigen Hinweisen.
E-Mail ist uU schwierig, da nicht jeder mit E-Mail arbeitet.
Also: Benutzer Klaus Meyer wird angelegt.
Es wird ein Sheet generiert:
Sehr geehrter Herr Klaus Meyer für Ihren Zugang zum System xy wurde am 22.02.22 ein Zugang mit folgenden Daten generiert:
URL: https://blah.de
Gruppe lesen
Benutzername: KMeyer
Kennwort: asdfASfjl7756((
Blah Blah Bla.
Das Kennwort ist aus Sicherheitgründen in der DB verschlüsselt gespeichert. Nun müsste nach einer Änderung ein neues Sheet generiert werden.
Sehr geehrter Herr Klaus Schmidt für Ihren Zugang zum System xy wurde am 23.05.22 ein Zugang mit folgenden Daten generiert:
URL: https://blah.de
Gruppe Verwalter
Benutzername: KSchmidt
Kennwort: asdfASfjl7756((
Blah Blah Bla.
So das ursprüngliche Kennwort habe ich nicht. Das Sheet finde ich praktisch, weil oftmals wird es sonst auf irgendeinen Zettel gekritzelt und der ist nach 2 Tagen weg. Überlasse ich es dem user habe ich 12345 als Kennwort. Das Sheet kann er sich zumindest in den verschlossenen Schreibtisch legen.
Wie bereits geschrieben, kopier sein altes Kennwort Hash auf den neuen User in der Tabelle um und überschreibe sein neu generiertes Kennwort damit.
Für das Sheet benötigst du eine zweite Version mit der Beschreibung "Kennwort bleibt"
Oder
Benenne seinen Namen in der Tabelle um.
Aber auch dann brauchst du eine zweite Sheet Version "Kennwort bleibt"
Oder
Erzeuge ein Single Sign On zum Active Directory, dann brauchst du kein Kennwort mehr, er wird automatisch erkannt.
Für das Sheet benötigst du eine zweite Version mit der Beschreibung "Kennwort bleibt"
Oder
Benenne seinen Namen in der Tabelle um.
Aber auch dann brauchst du eine zweite Sheet Version "Kennwort bleibt"
Oder
Erzeuge ein Single Sign On zum Active Directory, dann brauchst du kein Kennwort mehr, er wird automatisch erkannt.
Zitat von @NordicMike:
Wie bereits geschrieben, kopier sein altes Kennwort Hash auf den neuen User in der Tabelle um und überschreibe sein neu generiertes Kennwort damit.
Für das Sheet benötigst du eine zweite Version mit der Beschreibung "Kennwort bleibt"
Das in Kombination mit einem neuen Feld "NewUser" in der User-Tabelle.Wie bereits geschrieben, kopier sein altes Kennwort Hash auf den neuen User in der Tabelle um und überschreibe sein neu generiertes Kennwort damit.
Für das Sheet benötigst du eine zweite Version mit der Beschreibung "Kennwort bleibt"
Ist der Wert = 1, wird das Kennwort auf das Sheet angedruckt.
Gleichzeitig muss der User bei der ersten Anmeldung sein Kennwort ändern. Danach wird das Feld auf 0 gesetzt. Wird dann das Sheet neu erzeugt, steht bei Kennwort "ist bekannt" oder "unverändert".
Das Sheet finde ich praktisch, weil oftmals wird es sonst auf irgendeinen Zettel gekritzelt und der ist nach 2 Tagen weg. Überlasse ich es dem user habe ich 12345 als Kennwort. Das Sheet kann er sich zumindest in den verschlossenen Schreibtisch legen.
das ist Mist. ich würde die User "zwingen", ihr Kennwort zu ändern...das ist Mist. ich würde die User "zwingen", ihr Kennwort zu ändern
Check. Initial-Kennwort bekanntgeben, beim ersten Anmelden Zwang zum Ändern und natürlich entsprechende Passwortrichtlinien implementieren.
Der Titel müsste dann umbenannt werden in:"wie verschlimm bessert man einen Designfehler m möglichst aufwendig.
Der Primärschlüssel auf ne UUID die sich nicht ändert
Benutzername muss auch einmalig sein und gut ist.
das Macht Microsoft im Hintergrund so das mach @Frank hier im Forum. Das ist so eine gängige Lösung.
Der Primärschlüssel auf ne UUID die sich nicht ändert
Benutzername muss auch einmalig sein und gut ist.
das Macht Microsoft im Hintergrund so das mach @Frank hier im Forum. Das ist so eine gängige Lösung.
1
Schreibe ich so falsch, oder können einige Leute nicht lesen? ;)
Mein Problem ist das Sheet! Das gespeicherte Passwort ist != dem Passwort womit der User sich anmeldet
Also KMeyer hat das Passwort Vogel23.
In der Datenbank steht dann sowas wie sjrfsafaqfghqwifwughfwQ&&/&%&SDFCVSq.
Klaus Meyer heriratet und heißt Klaus Schmidt.
Also möchte ich den Benutzernamen ändern, Vogel23 bleibt. Vogel23 steht aber nicht in der Datenbank, kann also nicht asugelesen werden. Da nützt mir auch keine id.
Was nützt wir ein
Dann ist zwar der Login geändert, aber ich möchte eigendlich ein neues Sheet rausgeben, wo draufsteht.
Name Klaus Schmidt
Username KSchmidt
Passwort Vogel23
Die Idee war, ob man zB irgendwie das Passwort in eine Session schreibt oder das Passwort encodiert
Mein Problem ist das Sheet! Das gespeicherte Passwort ist != dem Passwort womit der User sich anmeldet
Also KMeyer hat das Passwort Vogel23.
In der Datenbank steht dann sowas wie sjrfsafaqfghqwifwughfwQ&&/&%&SDFCVSq.
Klaus Meyer heriratet und heißt Klaus Schmidt.
Also möchte ich den Benutzernamen ändern, Vogel23 bleibt. Vogel23 steht aber nicht in der Datenbank, kann also nicht asugelesen werden. Da nützt mir auch keine id.
Was nützt wir ein
update user set benutzername=KSchmidt where id=39Name Klaus Schmidt
Username KSchmidt
Passwort Vogel23
Die Idee war, ob man zB irgendwie das Passwort in eine Session schreibt oder das Passwort encodiert
Du denkst falsch.
UUID - > 1
Name - > Klaus Schmidt
Username - > kschmidt
Passwort - > Vogel23
nach der Hochzeit
machst du nur in der DB ein Modify auf Name und Username mehr nicht. Der Datensatz mit UUID und das Passwort bleibt erhalten.
und jede andere Tabelle verknüpftst du nicht mit nem Namen sondern mit der ID und alles ist sauber.
UUID - > 1
Name - > Klaus Schmidt
Username - > kschmidt
Passwort - > Vogel23
nach der Hochzeit
machst du nur in der DB ein Modify auf Name und Username mehr nicht. Der Datensatz mit UUID und das Passwort bleibt erhalten.
und jede andere Tabelle verknüpftst du nicht mit nem Namen sondern mit der ID und alles ist sauber.
1
Nochmal: das lässt sich so technisch nicht Umsetzen, Zumindest dann nicht wenn du das PW korrekt verschlüsselt - also irreversibel - in der Tabelle speicherst. PUNKT.
Deswegen: PW nur bei Anlage auf das Sheet. In allen "Folge-Sheets" nicht mehr mit angeben.
Deswegen: PW nur bei Anlage auf das Sheet. In allen "Folge-Sheets" nicht mehr mit angeben.
wie @SlainteMhath und @wiesi200 schon schrieben: neues/ angepasstes Formular und fertig.
Und würdest du ein halbes Jahr später mir mein Kennwort im Klartext zukommen lassen, würde ich deine Plattform vermutlich nicht mehr nutzen wollen.
Das klingt jetzt sicherlich etwas "hart", aber obige Punkte solltest du als Entwickler ja schon im Unterbewusstsein verankert haben.
Die Idee war, ob man zB irgendwie das Passwort in eine Session schreibt oder das Passwort encodiert
Das wäre der SuperGAU Damit kannst du die verschlüsselten Passwörter direkt sein lassen und die Kennwörter im Klartext in die DB schreiben. Stell dir vor, die Datenbank kommt dir "abhanden"...Und würdest du ein halbes Jahr später mir mein Kennwort im Klartext zukommen lassen, würde ich deine Plattform vermutlich nicht mehr nutzen wollen.
Das klingt jetzt sicherlich etwas "hart", aber obige Punkte solltest du als Entwickler ja schon im Unterbewusstsein verankert haben.
1
Durch die Heirat ändert sich doch nur der Benutzername. Dass Passwort wird nicht verändert.
Der User erhält ein angepasstes Sheet (Mail?) auf dem der alte und der neue Benutzername steht.
Das Passwort in verschlüsselter oder unverschlüsselter Version hat da nichts drauf zu suchen.
Wenn du dein Passwort bei einem Freemailanbieter (oder überall anders auch) änderst, dann steht das neue Kennwort ja auch nicht in der Mail - nur der Hinweis, dass dass Kennwort geändert wird.
Alles andere ist datenschutzrechtlich Unsinn.
Greetz
thejoker2305
Der User erhält ein angepasstes Sheet (Mail?) auf dem der alte und der neue Benutzername steht.
Das Passwort in verschlüsselter oder unverschlüsselter Version hat da nichts drauf zu suchen.
Wenn du dein Passwort bei einem Freemailanbieter (oder überall anders auch) änderst, dann steht das neue Kennwort ja auch nicht in der Mail - nur der Hinweis, dass dass Kennwort geändert wird.
Alles andere ist datenschutzrechtlich Unsinn.
Greetz
thejoker2305
Zitat von @tsunami:
Schreibe ich so falsch, oder können einige Leute nicht lesen? ;)
Mein Problem ist das Sheet! Das gespeicherte Passwort ist != dem Passwort womit der User sich anmeldet
Also KMeyer hat das Passwort Vogel23.
In der Datenbank steht dann sowas wie sjrfsafaqfghqwifwughfwQ&&/&%&SDFCVSq.
Klaus Meyer heriratet und heißt Klaus Schmidt.
Also möchte ich den Benutzernamen ändern, Vogel23 bleibt. Vogel23 steht aber nicht in der Datenbank, kann also nicht asugelesen werden. Da nützt mir auch keine id.
Was nützt wir ein
Dann ist zwar der Login geändert, aber ich möchte eigendlich ein neues Sheet rausgeben, wo draufsteht.
Name Klaus Schmidt
Username KSchmidt
Passwort Vogel23
Die Idee war, ob man zB irgendwie das Passwort in eine Session schreibt oder das Passwort encodiert
Schreibe ich so falsch, oder können einige Leute nicht lesen? ;)
Mein Problem ist das Sheet! Das gespeicherte Passwort ist != dem Passwort womit der User sich anmeldet
Also KMeyer hat das Passwort Vogel23.
In der Datenbank steht dann sowas wie sjrfsafaqfghqwifwughfwQ&&/&%&SDFCVSq.
Klaus Meyer heriratet und heißt Klaus Schmidt.
Also möchte ich den Benutzernamen ändern, Vogel23 bleibt. Vogel23 steht aber nicht in der Datenbank, kann also nicht asugelesen werden. Da nützt mir auch keine id.
Was nützt wir ein
update user set benutzername=KSchmidt where id=39Name Klaus Schmidt
Username KSchmidt
Passwort Vogel23
Die Idee war, ob man zB irgendwie das Passwort in eine Session schreibt oder das Passwort encodiert
Also sorry - das ist die DÜMMSTE idee überhaupt. Denn um das Passwort wieder auszulesen müsstest du ja auch wissen welches PW der Benutzer hat.
a) Du verhinderst damit effektiv das der Benutzer je sein Passwort ändert - denn ich würde sicher KEIN Passwort der Firma bekannt geben was ein auch nur idenisches Schema wie meine normalen PWs hat.
b) Sollte irgendwer an die DB kommen bist du so richtig im Ar....
-> Benutzerpasswörter sollte auch eben NUR der Benutzer kennen, niemand anders. Willst/musst du an das Konto ran (Kollege ist längerfristig Krank,...) -> passwort mit Admin-Recht ändern und das dir dann bekannte PW nutzen.
Von daher wäre bei einer Namensänderung auf deinem Zettel halt einfach nur "Passwort: Ihr Passwort wurde durch die Namensänderung nicht geändert".
Natürlich kannst du auch jeden 2-Wege-Code nehmen (dann eben keine Checksumme sondern JEDEN 2-Wege-Code, incl. des beliebten ROT-13). Das macht dich aber angreifbar, ist sinnlos und so ziemlich der schlechteste Stil überhaupt.
Zitat von @maretz:
Also sorry - das ist die DÜMMSTE idee überhaupt. Denn um das Passwort wieder auszulesen müsstest du ja auch wissen welches PW der Benutzer hat.
a) Du verhinderst damit effektiv das der Benutzer je sein Passwort ändert - denn ich würde sicher KEIN Passwort der Firma bekannt geben was ein auch nur idenisches Schema wie meine normalen PWs hat.
b) Sollte irgendwer an die DB kommen bist du so richtig im Ar....
-> Benutzerpasswörter sollte auch eben NUR der Benutzer kennen, niemand anders. Willst/musst du an das Konto ran (Kollege ist längerfristig Krank,...) -> passwort mit Admin-Recht ändern und das dir dann bekannte PW nutzen.
Von daher wäre bei einer Namensänderung auf deinem Zettel halt einfach nur "Passwort: Ihr Passwort wurde durch die Namensänderung nicht geändert".
Natürlich kannst du auch jeden 2-Wege-Code nehmen (dann eben keine Checksumme sondern JEDEN 2-Wege-Code, incl. des beliebten ROT-13). Das macht dich aber angreifbar, ist sinnlos und so ziemlich der schlechteste Stil überhaupt.
Zitat von @tsunami:
Schreibe ich so falsch, oder können einige Leute nicht lesen? ;)
Mein Problem ist das Sheet! Das gespeicherte Passwort ist != dem Passwort womit der User sich anmeldet
Also KMeyer hat das Passwort Vogel23.
In der Datenbank steht dann sowas wie sjrfsafaqfghqwifwughfwQ&&/&%&SDFCVSq.
Klaus Meyer heriratet und heißt Klaus Schmidt.
Also möchte ich den Benutzernamen ändern, Vogel23 bleibt. Vogel23 steht aber nicht in der Datenbank, kann also nicht asugelesen werden. Da nützt mir auch keine id.
Was nützt wir ein
Dann ist zwar der Login geändert, aber ich möchte eigendlich ein neues Sheet rausgeben, wo draufsteht.
Name Klaus Schmidt
Username KSchmidt
Passwort Vogel23
Die Idee war, ob man zB irgendwie das Passwort in eine Session schreibt oder das Passwort encodiert
Schreibe ich so falsch, oder können einige Leute nicht lesen? ;)
Mein Problem ist das Sheet! Das gespeicherte Passwort ist != dem Passwort womit der User sich anmeldet
Also KMeyer hat das Passwort Vogel23.
In der Datenbank steht dann sowas wie sjrfsafaqfghqwifwughfwQ&&/&%&SDFCVSq.
Klaus Meyer heriratet und heißt Klaus Schmidt.
Also möchte ich den Benutzernamen ändern, Vogel23 bleibt. Vogel23 steht aber nicht in der Datenbank, kann also nicht asugelesen werden. Da nützt mir auch keine id.
Was nützt wir ein
update user set benutzername=KSchmidt where id=39Name Klaus Schmidt
Username KSchmidt
Passwort Vogel23
Die Idee war, ob man zB irgendwie das Passwort in eine Session schreibt oder das Passwort encodiert
Also sorry - das ist die DÜMMSTE idee überhaupt. Denn um das Passwort wieder auszulesen müsstest du ja auch wissen welches PW der Benutzer hat.
a) Du verhinderst damit effektiv das der Benutzer je sein Passwort ändert - denn ich würde sicher KEIN Passwort der Firma bekannt geben was ein auch nur idenisches Schema wie meine normalen PWs hat.
b) Sollte irgendwer an die DB kommen bist du so richtig im Ar....
-> Benutzerpasswörter sollte auch eben NUR der Benutzer kennen, niemand anders. Willst/musst du an das Konto ran (Kollege ist längerfristig Krank,...) -> passwort mit Admin-Recht ändern und das dir dann bekannte PW nutzen.
Von daher wäre bei einer Namensänderung auf deinem Zettel halt einfach nur "Passwort: Ihr Passwort wurde durch die Namensänderung nicht geändert".
Natürlich kannst du auch jeden 2-Wege-Code nehmen (dann eben keine Checksumme sondern JEDEN 2-Wege-Code, incl. des beliebten ROT-13). Das macht dich aber angreifbar, ist sinnlos und so ziemlich der schlechteste Stil überhaupt.
"Das Kennwort ist aus Sicherheitgründen in der DB verschlüsselt gespeichert."
Aus welchen Sicherheitsgründen!!! soll das Passwort im Klartext irgendwo - außer beim User - verfügbar sein?
Ich würde den Sheet-Prozess nochmal überdenken und die gemachten Vorschläge nochmal verinnerlichen.
Sonst kann man das Passwort auch weglassen.
Als Alternative Lösung bietet sich auch ein SingleSignOn an, dann sparst du dir das Benutzerverwaltungspasswort komplett - hängt natürlich von der Umgebung ab...
Greetz
thejoker2305
