Registierungspflichtiger Bereich einer Webseite: Korrekt?

Beitrag von **Southmedia** » 28.08.2006, 17:43

Hallo,

ich habe mal die Punkte aufgeschrieben, die man als Programmierer bei
einer Seite mit registrierungspflichtigem Bereich so beachten sollte. Ist
das so alles korrekt oder habe ich da was wichtiges vergessen? Mache
was falsch oder auf unübliche Art und Weise?

a. Nutzerregistrierung

1. Anmeldeformular mit Feldern Benutzername, Passwort und Emailadresse
2. Passwort verschlüsselt (z.B. md5) in der Datenbank speichern
3. Einmaliger Aktivierungscode generieren (z.B. uniqid)
4. Aktivierungsemail an die hinterlegte Emailadresse senden
5. Nach Klick auf Aktivierungslink wird Login möglich

b. Login

1. Loginformular mit Feldern Benutzername, Passwort und Checkbox "eingeloggt bleiben"
2. Zum Benutzernamen gehörende Daten abrufen
3. Passwort aus Formular verschlüsseln und mit String in Tabelle vergleichen
4. Benutzername und verschlüsseltes Passwort in Session-Variabeln "user_$seitenname" und "pass_$seitenname" abspeichern
5. Wenn Checkbox angehakt Benutzername und verschlüsseltes Passwort in Cookie "user_$seitenname" und "pass_$seitenname" abspeichern

c. Überprüfung der Nutzerdaten

1. Überprüfung ob "user_$seitenname" und "pass_$seitenname" in Session oder Cookie vorhanden ist
2. Vergleich des Passworts-Strings mit dem für den Benutzername in der Datenbank hinterlegten Passwort-String
3. Bei Fehler: Cookie und Session-Daten löschen
4. Bei Erfolg: Notwendige Nutzerdaten für Scriptausführung zwischenspeichern (z.B. Nutzer-ID)

d. Passwort vergessen

1. Formular für Benutzername und Emailadresse
2. Überprüfung ob Benutzername und Emailadresse zusammengehören
3. Einmaliger Passwort-Rücksetz-Code generieren (z.B. uniqid)
4. Passwort-Rücksetz-email an die hinterlegte Emailadresse senden
5. Nach Klick auf den Link kann ein neues Passwort gesetzt werden
6. Passwort verschlüsselt (z.B. md5) in der Datenbank speichern
7. Loginformular

e. Passwort ändern

1. Formular für altes Passwort und neues Passwort
2. Überprüfen ob altes Passwort korrekt
3. Neues Passwort verschlüsselt (z.B. md5) in der Datenbank speichern
4. Nutzer ausloggen
5. Loginformular

von **Anzeige von ABAKUS** »

Hochwertiger Linkaufbau bei ABAKUS:

Google-konformer Linkaufbau
nachhaltiges Ranking
Linkbuilding Angebote zu fairen Preisen
internationale Backlinks

Wir bieten Beratung und Umsetzung.
Jetzt anfragen: 0511 / 300325-0

Beitrag von **Nullpointer** » 28.08.2006, 17:59

anmerkung zu d) 1. :
ich würde nicht unbedingt auch die uid abfragen. in den zig foren, in denen ich im laufe der jahre registriert war, weiß ich auch oft meine uid nicht mehr. da ist es ganz praktisch, wenn ich nur die email adresse angeben muss. sonst muß ich einen neuen user anlegen mit anderer adresse.

Beitrag von **Southmedia** » 28.08.2006, 18:41

Da hast du Recht. Der Benutzername sollte hier dann wohl optional sein oder gar nicht abgefragt werden.

Da fällt mir ein:
Bei a) und d) muss ich jeweils noch überprüfen wann zuletzt eine solche Email an diese Adresse verschickt wurde. Das sollte möglichst nur ein mal am Tag geschehen oder so.

von **Anzeige von ABAKUS** »

SEO Consulting bei ABAKUS Internet Marketing
Erfahrung seit 2002

persönliche Betreuung
individuelle Beratung
kompetente Umsetzung

Jetzt anfragen: 0511 / 300325-0.

Beitrag von **Anonymous** » 28.08.2006, 19:10

Muss laut Datenschutz nicht auch die Möglichkeit der Abmeldung vorhanden sein?

zu f) Änderung der Mailadresse wird erst nach Mail mit Bestätigungslink an neue Mailadresse wirksam.

Beitrag von **Nexus** » 28.08.2006, 19:17

Hi,

2. Passwort verschlüsselt (z.B. md5) in der Datenbank speichern

Nur der Vollständigkeit halber: Das macht natürlich nur Sinn wenn diese Formulare verschlüsselt (SSL/TLS) übertragen werden. Ansonsten kann das Passwort immer noch im Klartext mitgelesen werden.

Zu Passwörtern in DBs gab vor einigen Tagen ein paar nette Blog-Einträge in der MySQL-Community:

https://sheeri.com/archives/109
https://www.flamingspork.com/blog/2006/ ... -in-mysql/
https://mysqldatabaseadministration.blo ... mysql.html

Gruß
Raphael

Beitrag von **Southmedia** » 28.08.2006, 19:29

Muss laut Datenschutz nicht auch die Möglichkeit der Abmeldung vorhanden sein?

networker, logisch muss eine Abmeldung vorhanden sein. Hab ich doch glatt vergessen. Wer geht schon davon aus, dass die Nutzer sich abmelden möchten

zu f) Änderung der Mailadresse wird erst nach Mail mit Bestätigungslink an neue Mailadresse wirksam.

Hinzugefügt:

f. Emailadresse ändern

1. Neue Emailadresse eingeben
2. Einmaliger Email-ändern-Code generieren (z.B. uniqid)
3. Email-ändern-Email an die neue Emailadresse senden
4. Nach Klick auf den Link wird die neue Emailadresse aktiviert

Beitrag von **Southmedia** » 28.08.2006, 19:49

Nur der Vollständigkeit halber: Das macht natürlich nur Sinn wenn diese Formulare verschlüsselt (SSL/TLS) übertragen werden. Ansonsten kann das Passwort immer noch im Klartext mitgelesen werden.

Zu Passwörtern in DBs gab vor einigen Tagen ein paar nette Blog-Einträge in der MySQL-Community:

https://sheeri.com/archives/109
https://www.flamingspork.com/blog/2006/ ... -in-mysql/
https://mysqldatabaseadministration.blo ... mysql.html

Danke Raphael für die Anmerkung und vor allem die Links. Gerade das userseitige Verschlüsseln von Passwörtern ist ein sehr interessanter Gedanke. Die sichere Übertragung könnte ich oben noch hinzufügen als Vorwort oder so.

Beitrag von **Southmedia** » 28.08.2006, 20:00

Eine Frage zu den ganzen Email mit einem Aktivierungscode:
Reicht es hier nur den Code als Parameter zu senden oder sollte man auch zusätzlich die Emailadresse, User-ID oder ähnliches dranhängen? Wie ist da eure Einschätzung?

Beitrag von **Anonymous** » 28.08.2006, 20:34

Southmedia hat geschrieben:Eine Frage zu den ganzen Email mit einem Aktivierungscode:
Reicht es hier nur den Code als Parameter zu senden oder sollte man auch zusätzlich die Emailadresse, User-ID oder ähnliches dranhängen? Wie ist da eure Einschätzung?

wenn der aktivierungscode jeweils einmalig ist und eine gewisse Länge hat sollte es ausreichend sein.... ggf. bei dem aktivierungsscript eine Sicherheit einbauen, so dass von einer IP nur eine gewisse Anzahl Aktivierungsversuche pro Zeitspanne stattfinden können, um brute force aktivierungen zu verhindern...

für solche Aktionen die eine weitere Bestätigung benötigen nutze ich eine eigene Store/Restore Class, diese speichert die daten erst im xml format in einer db, zusammen mit ausführender Class/Funktion, Gültigkeitsdauer und einem aktionskey... beim speichern wird der aktionskey übergeben, und beim restore aufruf mit dem aktionskey wird der gespeicherten Class/Funktion die gespeicherten Daten übergeben und aufgerufen...

Beitrag von **MonikaTS** » 29.08.2006, 00:06

PW ändern können,

also ich dermerk mir die HU876)0?08jj generierten PW so selten

wenn ich mich abmelde, dann mag ich auch gern , wenn die Cookies gelöscht werden,
und ich dann auf die Hauptseite weitergeleitet werde

Frage ist auch:

Benutzerregeln, Hausordnung, Rechtliches:
erst nach Klick auf dieses geht die Registrierung weiter oder nicht ...

gut ist es auch, wenn bei der Anmeldung und beim PW neu senden und so weiter dabei steht, dass der user bitte seinen Spamordner ansehen sollte..
zu 9999,99 % landen diese Emails nämlich dort.

mehr fäll mir jetzt nicht mehr ein, vielleicht kommt noch was..
lg

Beitrag von **marc75** » 29.08.2006, 08:06

3. Einmaliger Aktivierungscode generieren (z.B. uniqid)
4. Aktivierungsemail an die hinterlegte Emailadresse senden

Inaktive User würde ich nach x Tagen löschen.

2. Passwort verschlüsselt (z.B. md5) in der Datenbank speichern

Nur der Vollständigkeit halber: Das macht natürlich nur Sinn wenn diese Formulare verschlüsselt (SSL/TLS) übertragen werden. Ansonsten kann das Passwort immer noch im Klartext mitgelesen werden.

Die Verschlüsselung der Passwörter in der DB dient dazu, falls jemand mal die DB knackt und die Daten runterlädt.

Beitrag von **Anonymous** » 29.08.2006, 08:17

achja... fällt mir gerade ein...

in der aktivierungsmail gleichzeitig einen Link anbieten um die Mailadresse auf eine Sperrliste zusetzen, falls sich da jemand einen Scherz mit einer fremden Mailadresse erlaubt....

Beitrag von **Nullpointer** » 29.08.2006, 08:17

marc75 hat geschrieben:....

Die Verschlüsselung der Passwörter in der DB dient dazu, falls jemand mal die DB knackt und die Daten runterlädt.

aber auch dann sollte man sich vor einer dictionary attack schützen. selbst bei einem forum, wie diesem, könnte es sehr sehr ärgerlich für einige member werden, wenn ihre pwds geknackt werden.
und so mancher hat ein standardpasswort.

Beitrag von **Hasenhuf** » 29.08.2006, 10:20

net(t)worker hat geschrieben:achja... fällt mir gerade ein...

in der aktivierungsmail gleichzeitig einen Link anbieten um die Mailadresse auf eine Sperrliste zusetzen, falls sich da jemand einen Scherz mit einer fremden Mailadresse erlaubt....

Na ja, wer will sich schon so der Gefahr aussetzen seine Emailadresse zu validieren. Die Mühe zu schauen ob es ein seriöse Seite ist macht sich kaum jemand.

marc75 hat geschrieben:
Nexus hat geschrieben:
2. Passwort verschlüsselt (z.B. md5) in der Datenbank speichern

Nur der Vollständigkeit halber: Das macht natürlich nur Sinn wenn diese Formulare verschlüsselt (SSL/TLS) übertragen werden. Ansonsten kann das Passwort immer noch im Klartext mitgelesen werden.
Die Verschlüsselung der Passwörter in der DB dient dazu, falls jemand mal die DB knackt und die Daten runterlädt.

Genau und ein paar weitere Gründe fallen mir auch noch ein.

Beitrag von **Southmedia** » 29.08.2006, 12:52

Inaktive User würde ich nach x Tagen löschen.

Je nach Anwendung kann das sinnvoll sein, ja. Wobei "inaktiv" = "nicht aktiviert". Und "löschen" nur "verschieben" bedeutet, da ansonsten der selbe Nutzer alle x Tage wieder mit Aktivierungsmails zugemüllt werden könnte.

Die Verschlüsselung der Passwörter in der DB dient dazu, falls jemand mal die DB knackt und die Daten runterlädt.

oder die Anwendung doch mal für ne Injection anfällig ist, das Script aus Versehen irgendwo ein Query ausgibt oder, oder, oder. Passwörter sind so wichtig wie die Daten, die sie schützen.

in der aktivierungsmail gleichzeitig einen Link anbieten um die Mailadresse auf eine Sperrliste zusetzen, falls sich da jemand einen Scherz mit einer fremden Mailadresse erlaubt....

Eine nicht aktivierte Emailadresse bekommt maximal x erneute Emails pro Tag / Woche / überhaupt. Das ist sinnvoller.