Webseite - Zugangs-Passwort vergessen - Methoden...

[DerMagus]

Hallo,

ich hoffe, das ist das richtige Forum dazu - ich würde gerne um Meinungen fragen. Es geht um die Methode, ein vergessenes Passwort zuzusenden. Die Webseite ist ein kleiner Spiele-Server, also nichts mit maximaler Sicherheit.

Beim Registrieren gibt der neue Benutzer einen gewünschten Account-Namen, eine gültige Email-Adresse und ein Passwort ein. Diese 3 Daten sind Pflicht, und werden auch gespeichert. Email und Account-Name sind eindeutig und dürfen nur einmal existieren. Account-Name und Email werden nirgendwo angezeigt, sind also nur dem Benutzer selbst bekannt, anderen Benutzern nicht.

Eingeloggt wird mit Account-Name und Passwort.

Wenn der Benutzer sein Passwort nicht mehr weiß, muss man es ihm wieder geben, bzw. neu setzen. Darum geht es hier:

Ich habe eine (fertige) Lösung, bei der als Standard vom Benutzer seine Email-Adresse verlangt wird. Wenn die stimmt, wird das Passwort, das zum Account mit dieser Email-Adresse gehört, neu erstellt und zu dieser Email-Adresse gesendet.

Ehrlich gesagt, finde ich das nicht so toll - wenn jemand eine Email-Adresse kennt oder errät, kann er den Benutzer belästigen, weil der dann dauernd Emails bekommt, die er nicht angefordert hat.

Deswegen werde ich das wohl so abändern, dass der Benutzer seinen Account-Namen UND die Email-Adrese eingeben muss. Wenn beides zusammenpasst und ein Account gefunden wird, bekommt er das neue Passwort gesetzt und zugesandt.

Nun bitte ich um Meinungen - wie seht ihr das?

(Bitte keine Two-Factor Geschichten usw., das wird hier nicht gebraucht. Einfach die beiden Methoden vergleichen.)

Danke

 

[tollertyp]

Und was hat jemand davon, wenn er das macht, also solche Mails "zu erzeugen" für Accounts, die nicht von ihm sind? [Edit] Ach ja, und normal erzeugt man Links zum Generieren eines neuen Kennworts, das mitgesendete Token dafür ist dann nur zeitlich begrenzt gültig.[/Edit]

Eine gute Seite sagt einfach "Wenn es unter der Adresse einen Account gibt, wurde eine entsprechende Mail geschickt". Der Benutzer erhält keine Rückmeldung, ob es einen Account gibt.

Beides abzufragen halte ich für relativ nutzlos.

Wenn die Seite aber so stark missbraucht wird, dann würde ich über Captchas nachdenken und wenn das nicht reicht, dann wirklich beide Sachen abfragen. Aber ich habe das Gefühl, dass die Seite nicht wichtig genug dafür ist.

 

[scooter010]

Ich würde kein neues Passwort setzen. Ich würde das alte einfach weiter gültig lassen, bis es aktiv geändert wird (kein neues Passwort zusenden, sondern einen link, der das Ändern ohne kenntnis des bisherigen Passwortes erlaubt.

Diesen Link maximal 2x pro Tag anfordern lassen.

 

[madmax2010]

, bekommt er das neue Passwort gesetzt und zugesandt.

Bitte nicht.
Passwort via email versenden ist eine ganz schlechte Idee. Alleine schon, weil dann auf deiner Seite ein Klartextpasswort verarbeitest.
Schick eine email mit Reset Link.

Wie legst du die Passwörter in die Datenbank? Klartext oder Hash+Salt?

 

[Autokiller677]

Dass man mit der E-Mail Adresse E-Mails an einen Nutzer auslösen kann, ist bei fast jedem Dienst so üblich. Und Nutzer vergessen auch gerne ihren User-Name, den zu verlangen stellt dann ein Hindernis da.

Das viel größere Problem mit beiden Methoden ist, dass ein Passwort a) im Klartext per E-Mail versendet wird und b) der Server das Passwort im Klartext (zumindest kurzzeitig) kennt. Ganz großes no-no. Ein Server sollte nie das Passwort im Klartext kennen.

Entweder einen Link zum Zurücksetzen verschicken, oder ein temporäres Passwort, dass nur einmalig zum setzen eines neuen Passworts genutzt werden kann.

 

[tollertyp]

Diesen Link maximal 2x pro Tag anfordern lassen.

Finde ich persönlich eine relativ unnötige Einschränkung, also 2 erscheint mir unnötig wenig.

Ergänzung (27. März 2024)

oder ein temporäres Passwort, dass nur einmalig zum setzen eines neuen Passworts genutzt werden kann.

temporäres Passwort macht es halt ggf. komplizierter, falls das alte Passwort nach wie vor genutzt werden können soll - also eben falls es sich um eine "Störung" durch andere handeln sollte. So könnte man Nutzer dazu nötigen, ständig die Passwörter neu setzen zu müssen.

Es hat gute Gründe, warum man Reset-Links mit Tokens verwendet.
(und ich weiß, dass du das auch genannt hast, ich erkläre nur, warum die Variante mit dem temporären Passwort die eher schlechtere Variante ist)

 

[Autokiller677]

Ich würde das temporäre Passwort auch einfach wie einen Token implementieren - kommt dann halt nicht als URL-Parameter rein, sondern vom User eingegeben, ist am Ende aber dasselbe auf Seite des Systems.

 

[tollertyp]

Kann man so machen, gibt es dafür dann eine spezielle Seite oder muss der Login-Mechanismus dann beide Varianten verstehen? Wenn es eine eigene Seite ist, dann ist es halt exakt dasselbe wie ein Token.

 

[DerMagus]

Danke für eure Antworten!

Wegen Passwort: Wird nicht im Klartext gespeichert, muss aber am Server bekannt sein, zumindest kurz, da es nämlich auch für den Spiele-Server gilt und dort ebenfalls gesetzt werden muss. Dh. Account-Name und Passwort sind auch (und sogar vor allem) für das Spiel nötig.

Daher kann ich es ruhig erzeugen, und diverse Gefummel mit Tokens usw. würde alles nur komplizierter machen, weil der Benutzer in der Regel einfach nach einer Pause wieder spielen will, und sein Passwort vergessen hat.
Falls der Benutzer auch seinen Account-Namen nicht mehr weiß, ist das ein Problem, da ich als Admin lösen muss. Ich muss nämlich dann (und nicht nur anhand der Email) entscheiden, ob es wirklich die Person ist, oder jemand anders. Das möchte ich wirklich selber machen, also bloß eine Email raten und dann alles neu bekommen ist nicht ideal. Es geht hier auch um gespeicherte Spielfiguren und deren Besitz, hat zwar keinen finanziellen Wert, ist aber den Spielern natürlich wichtig.

Also werde ich wohl Account und Email abfragen, und wenn das wer nicht mehr weiß, muss er sich sowieso an uns wenden. In den allermeisten Fällen (wir machen das ja schon eine Weile) fehlt einfach das Passwort, der Spieler weiß alle möglichen Details und meist auch seinen Account-Namen.

Nochmal danke für eure Meinungen!

 

[tollertyp]

Das möchte ich wirklich selber machen, also bloß eine Email raten und dann alles neu bekommen ist nicht ideal.

Also da bekommt man den Eindruck, dass man bei Eingabe der Adresse direkt im Browser das neue Passwort zu Gesicht bekommt.

Einfach nur das Erraten einer E-Mail-Adresse reicht eigentlich nirgends aus, um einen Account zu stehlen... wenn das bei dir reicht, dann würde ich mir Sorgen machen.

Und wenn das mit den Tokens die Sache so kompliziert macht, wie stellst du eigentlich sicher, dass es die E-Mail-Adresse des Nutzers überhaupt gibt?

 

[M@rsupil@mi]

wohl Account und Email abfragen

Nach dem Accountnamen zu fragen halte ich für problematisch. Wer die Logindaten vergisst und Hilfe braucht, der wird kaum seinen Accountnamen wissen. Eingabe der Mail ist doch das, was nahezu alle Dienste anbieten. Dadurch wird ein Account ja nicht übernommen. Für die Sicherheit des hinterlegten E-Mail-Accounts ist der Benutzer verantwortlich. (Zumindest optional wäre 2FA im Jahr 2024 allerdings auch nicht verkehrt.)

Du könntest auch dem User die Möglichkeit bieten eine weitere / alternative Mail-Adresse oder Telefonnummer für Passwort-Reset per SMS zu hinterlegen?

Außerdem schadet es sicherlich nicht nach Zeitraum X die mit dem Account verknüpften Daten, wie Mail / Telefon, erneut zu verifizieren oder zumindest zu fragen, ob die noch aktuell sind.

 

[Autokiller677]

Auf der einen Seite willst du deutlich mehr Sicherheit machen als es sonst bei sehr vielen Diensten im Internet üblich ist und die E-Mail Adresse ist nicht ausreichend für eine Account-Recovery.

Auf der anderen Seite sind Tokens Gefummel, 2FA gibt's auch nicht und dein Server kennt das Passwort im Klartext.

Klingt für mich nicht nach einer schlüssigen Sicherheitsarchitektur.

Und wenn der Server Passwörter im Klartext kennt: Wie ist der Server selbst gegen Angriffe abgesichert?

 

[DerMagus]

Der Spiele-Server speichert auch keine Klartext-PW, aber so wie bei Webseiten muss man es wohl einmal eingeben (damit er es mit PW-Hash vergleichen kann). Bei Setzen des PW muss man es natürlich auch eingeben, und der Spiele-Server ist von der Webseite getrennt. Also brauche ich das Klartext-PW, das der Benutzer ja eintippt, dann auch zum Update am Spiele-Server. Das läuft aber intern und direkt.

Geschichten wie SMS, 2FA usw. kosten Geld. Ich benutze einen VM-Server mit Linux, und das ist schon nicht billig. Aber die zusätzliche Sicherheit kann sich jemand mit Geld und Profi-Team vielleicht leisten. Ich brauche sie aber nicht.

Und ich möchte anmerken, dass ich nirgendwo geschrieben habe, dass die Passworte im Klartext GESPEICHERT werden. Gesendet werden sie im Klartext, und verarbeitet auch, oder wie soll das denn sonst klappen? Der Server macht einen Hash aus dem empfangenen PW und vergleicht den mit dem gespeicherten Hash. (Und ja, wir 'salzen' die Hashes, auch der Spiele-Server macht das). Webserver und Spiele-Server haben eigene Account-Daten, also auch eigene PW-Hashes, das geht nicht anders.

Aber - ich nehme zur Kenntnis, dass offenbar einige von euch die Angabe der Email alleine für ausreichend halten.

 

[MaverickM]

Ich habe eine (fertige) Lösung, bei der als Standard vom Benutzer seine Email-Adresse verlangt wird. Wenn die stimmt, wird das Passwort, das zum Account mit dieser Email-Adresse gehört, neu erstellt und zu dieser Email-Adresse gesendet.

Ehrlich gesagt, finde ich das nicht so toll - wenn jemand eine Email-Adresse kennt oder errät, kann er den Benutzer belästigen, weil der dann dauernd Emails bekommt, die er nicht angefordert hat.

Das ist die gängige Vorgehensweise und auch richtig so. Das hat auch den Vorteil, dass der Besitzer des Accounts bzw. der E-Mail Adresse weiß, dass jemand fremdes versucht, auf den Account zuzugreifen, und kann entsprechende Maßnahmen unternehmen.

Für den Fall, dass solche Anfragen gespammt werden, gibt es Fail2Ban.

Ergänzung (27. März 2024)

Gesendet werden sie im Klartext, und verarbeitet auch, oder wie soll das denn sonst klappen?

Idealerweise werden sie über eine verschlüsselte Verbindung gesendet... Und zwar bereits als Hash, und nicht als Klartext.

 

[DerMagus]

Fail2ban ist sowieso unverzichtbar, habe ich natürlich...

Der Webserver ist auch https, auch klar. Das Senden der PW als Hash - dazu müsste man mit Javascript beim Benutzer selbst das PW hashen. Das machen wir nicht. Aber SSL sollte eigentlich reichen - wir machen nichts mit Geld/Kreditkarte usw. Einfach Spiel-Forum und Spiel-Server.

Trotzdem - danke für euren Input!

Das mit Email-Adresse alleine oder nicht überlege ich noch. Beide Möglichkeiten (Account-Name UND Email, oder Email alleine) habe ich hier fertig. Jedenfalls waren die Kommentare hier hilfreich, um mal eine Übersicht zu bekommen.

 

[Autokiller677]

Der Spiele-Server speichert auch keine Klartext-PW, aber so wie bei Webseiten muss man es wohl einmal eingeben (damit er es mit PW-Hash vergleichen kann). Bei Setzen des PW muss man es natürlich auch eingeben, und der Spiele-Server ist von der Webseite getrennt. Also brauche ich das Klartext-PW, das der Benutzer ja eintippt, dann auch zum Update am Spiele-Server. Das läuft aber intern und direkt.

Ich sehe das Problem. Der richtig ordentliche Weg dafür wäre halt, einen Authentication-Dienst als Single-Sign-On zu nutzen (Keycloak, Auth0, Azure Entra, "Login mit Google / Facebook etc" oder was auch immer - sind teilweise auch kostenlos) und beide Server reden mit dem Dienst um einen User zu validieren (Stichwort OAuth / SAML Authentication Flow).
Eine andere Lösung könnte sein, dass der User halt einfach beide Accounts selber anlegen muss und dann nur im Nachhinein verknüpft - nicht so schön für den User, aber von der Sicherheit sauberer.

Geschichten wie SMS, 2FA usw. kosten Geld.

2FA mit einer Authenticator-App kostet jetzt nicht per se Geld. Ob es ein fertiges Packet für deinen Anwendungsfall gibt, ist natürlich eine andere Frage. SMS dagegen klar, kosten Geld, aber ist eh unsicher, von daher sollte man die eh weglassen.

Und ich möchte anmerken, dass ich nirgendwo geschrieben habe, dass die Passworte im Klartext GESPEICHERT werden.

Auch im RAM wird gespeichert. Nicht dauerhaft, aber es ist da und kann im Fall von Sicherheitslücken in der Software / Memory Leaks auch länger da bleiben als man denkt.

Gesendet werden sie im Klartext, und verarbeitet auch, oder wie soll das denn sonst klappen?

Heißt dass, nicht nur beim Account erstellen, sondern bei jedem Login bekommt dein Server ein Klartext-Passwort?
Wie es eigentlich klappen soll - so wie bei jedem halbwegs sicheren System seit Jahren. Der Hash wird auf der Client-Seite berechnet (z.B. durch JavaScript im Browser) und nur der gehashte Wert wird gesendet. Der Normalfall ist, dass ein Passwort nie das Gerät im Klartext verlässt.


Vermutlich gibt es für dich keinen einfachen Weg, das System sicherheitstechnisch sauber aufzusetzen. Wenn du dich trotzdem entschließt es zu machen, stell wenigstens sicher, dass alles drum rum top läuft - Updates für alles schnell installieren, Zugriff auf die Linux-Kiste nur per SSH Keys (Passwort-Login über SSH komplett deaktivieren, root Login sowieso), SSH Key am besten noch per Hardware Key wie ein Yubikey geschützt, alle Verbindungen von / zu den Servern mit TLS1.3 gesichert usw.

 

[BeBur]

Idealerweise werden sie über eine verschlüsselte Verbindung gesendet... Und zwar bereits als Hash, und nicht als Klartext.

Nein, das macht niemand und bringt nichts, weil der Hash dann einfach zum Passwort wird. Das Passwort selber wird stets per Transportverschlüsselung an den Server übertragen.

 

[Autokiller677]

Natürlich bringt es was. Ein Angreifer kann nicht ans Klartext-Passwort kommen, und da immer noch sehr viele Leute Passwörter wiederverwenden, ist ein Abfluss von Klartext-Passwörtern deutlich schlimmer als ein Abfluss von Hashes, weil dadurch für viele gleich mehrere Dienste kompromittiert werden, und nicht nur der Angegriffene.

 

[BeBur]

Ein Angreifer kann nicht ans Klartext-Passwort kommen

Wenn ein Angreifer Zugriff auf den Server hat, dann liefert er einfach eine Website ohne Client-Hashing aus. Oder für welches Angriffszenario soll es was bringen, das Passwort beim Nutzer schon zu hashen?

Im übrigen muss man dann selbstredend am Server sowieso nochmal hashen, siehe hier.

 

[MaverickM]

Oder für welches Angriffszenario soll es was bringen, das Passwort beim Nutzer schon zu hashen?

MitM Attacken.

Aber ja, ich sehe das Problem.