Login-System

[Kmitska]

Hallo Leute,

ich würde mich gerne bei Euch über das Loginssystem einer Webseite informieren.

Ich weiß nicht, wie ich das machen kann/sollte und wie es sicher ist.
Im Moment ist es so, dass ich 2 Cookies für Benutzername und Passwort speichere.
Auf der API Seite lese ich die Cookies ab und schaue jedes mal, ob der User eingeloggt ist.
Doch zufrieden bin ich mit dieser Methode nicht, da alles in Klartext gespeichert wird. (Im Browser als Cookie)

Was sagt Ihr dazu?

Grüße,
Kmitska

[nufan]

Im Moment ist es so, dass ich 2 Cookies für Benutzername und Passwort speichere.

Der Benutzername sollte eher nicht in den Cookies gespeichert werden, das Passwort auf gar keinen Fall!
Bei XSS-Angriffen hat der Angreifer dann sofort alle Zugangsdaten eines Benutzers und kann diese eventuell auch in anderen Diensten missbrauchen. Außerdem fällt es einem Angreifer im lokalen Netzwerk (WLAN?) viel leichter das Passwort zu sniffen, wenn es bei jedem Request mitgeschickt wird.

Was sagt Ihr dazu?

Für einen sicheren Datenverkehr solltest du mal HTTPS verwenden. Benutzerspezifische Informationen solltest (in lesbarer Form) trotzdem so selten wie nur irgendwie möglich übertragen, im Idealfall nur ein einziges Mal beim Login. Nun kannst du dir z.B. deine Benutzer-ID in der Session speichern und jedes mal abfragen.

[GilbertDur]

Du könntest Nutzername und Passwort (falls möglich) auch in einer Datenbank verschlüsselt speichern, zum Beispiel mit Hilfe einer Hashfunktion. Beim Login-Versuch jagst du dann die eingegebenen Daten ebenfalls durch die Hash-Funktion und vergleichst sie mit den in der DB gespeicherten Werten.

[Xin]

Du könntest Nutzername und Passwort (falls möglich) auch in einer Datenbank verschlüsselt speichern, zum Beispiel mit Hilfe einer Hashfunktion.

Bitte kräftig würzen....

Ein Salt wird auf das Passwort addiert, daraus wird der Hashwert gebildet. Fehlt der Salt, so gibt es im Internet Tabellen, wo man den Hashwert nachschlagen kann und das dazugehörige Passwort erhält.

[cloidnerux]

Jop, Salten ist pflicht.

Was du aber statt Benutzername und Passwort speichern solltest, ist eine Eindeutige ID, die auf deinem Server in einer DB hinterlegt ist, mitsamt Uhrzeit der Ausstellung. So brauchst du nur die ID zu vergleichen und es werden keine benutzerspezifischen Merkmale übertragen.
Wenn es geht, müsste man da egt noch Computerspezfische Merkmale mit einbauen, damit das übernehmen einer solchen ID nicht so ohne weiteres Möglich ist.
Zudem sollte so eine ID auslaufen, nach einer Woche, 2, 3, 4, was auch immer. Nicht so wie hier im Forum

[GilbertDur]

Du könntest Nutzername und Passwort (falls möglich) auch in einer Datenbank verschlüsselt speichern, zum Beispiel mit Hilfe einer Hashfunktion.

Bitte kräftig würzen....

Ein Salt wird auf das Passwort addiert, daraus wird der Hashwert gebildet. Fehlt der Salt, so gibt es im Internet Tabellen, wo man den Hashwert nachschlagen kann und das dazugehörige Passwort erhält.

Step by Step. Es ging doch um die Grundlagen

[Kmitska]

Hallo Leute,

also, ich fass mal kurz alles zusammen und Ihr korrigiert mich ok?

1) Ich erstell erst mal eine Tabelle in der Datenbank (MySQL):
| session_id | date |

2) Nach dem Login wird in Klartext über SSL(HTTPS) Benutzername und Passwort gesendet.
3) Auf der Server-Seite wird das Passwort als Hash gespeichert und das gesendete ebenfalls gehasht und kontrolliert.
4) Bei einem ergolreichen Login bekommt der User eine Session_id zugesendet, die er dann als Cookie speichert.
5) Bei jeder weiterem API Zugang wird die ID gesendet und wenn sie valid ist heißt das für den Server, dass der User eingeloggt ist.

Nun meine Fragen:
- Wie wird diese ID in der Datenbank gelöscht? Nur die wenigsten melden sich wieder ab.
- So ist doch das Hijacking leichter? Einfach die Session_id holen?

Grüße
Kmitska

[cloidnerux]

2) Nach dem Login wird in Klartext über SSL(HTTPS) Benutzername und Passwort gesendet.
3) Auf der Server-Seite wird das Passwort als Hash gespeichert und das gesendete ebenfalls gehasht und kontrolliert.

Hier gilt Folgendes Konzept:
Bei der Registrierung, speicherst du kein klartext Passwort, sondern das Passwort als Gesalzener Hash. z.B:

Code: Alles auswählen

md5(passwort+"salt")

Damit bei einem Datenbank Einbruch keine Passwörter direkt geklaut werden können.
Dann bei der Anmeldung, sollte über eine gesicherte HTTPS Verbindung Nutzername und Passwort ausgetauscht werden, das Passwort wird auf die selbe Art und Weise gehasht und verglichen.

- Wie wird diese ID in der Datenbank gelöscht? Nur die wenigsten melden sich wieder ab.

Du kannst dir entweder per Cronjob ein Programm drüberlaufen lassen, der veraltete Sessions löscht.
Du kannst aber auch, bei einer Anmeldung mit einer Session-ID überprüfen, wie alt diese ist und bei überschrittener Gültigkeit den Nutzer zur eingabe des Passworts zwingen. Das sollte dann aber nach Möglichkeit bei jedem Zugriff kontrolliert werden, damit ein Bösewicht nicht einfach nur die Verbindung aufrecht erhalten kann.

So ist doch das Hijacking leichter? Einfach die Session_id holen?

Es ist nicht leichter, da die Session-ID ja als Cookie vorliegt, das selbe wie mit deinem Nutzername und Passwort, aber eben Nutzer unabhängig.
Wenn jemand die Session-ID erhält, kann er sich einige Tage lang Zugriff erschleichen. Klaut er Nutzername und Passwort, kann er sich dauerhaft Zugang erschleichen und evt sogar auf andere Websiten zugriff erhalten(Email, Amazon, EBanking). Was ist wohl schlimmer?

[Kmitska]

Hmm.. man könnte doch dann eigentlich gleich die ganze Seite mit SSL unterstützen?

Und ich habe jetzt eine Tabelle mit diese Spalten erstellt:

Code: Alles auswählen

username | session_id | date

Die letzte Frage, um sicher zu gehen:
Das Passwort wird jedes mal auf der Server-Seite verschlüsselt und nicht auf der Client Seite?

Möchte bald die Software online zum testen stellen und wenn alles gut läuft wirds kommerziell.
Würde mich freuen, wenn Ihr die Software mittesten würdet.

Wegen Passwort: Ich hatte nicht gedacht, dass ich soweit damit komme. Hatte deshalb alles auf Cookies gemacht.

[darksider3]

Das Passwort wird jedes mal auf der Server-Seite verschlüsselt und nicht auf der Client Seite?

Eindeutig auf der Server Seite. Am besten versuchst Du dir eine Anbindung an einen GPG-Agenten auf den Server zu ziehen, damit Du diese mit einem Serverseitigen Passwort(welches nach X tagen ausläuft, womit auch die ID's wieder ungültig werden) verschlüsseln kannst, oder mit einem dauernd generierten SSH-Images/Hashes.

Möchte bald die Software online zum testen stellen und wenn alles gut läuft wirds kommerziell.

<-Biete mich an da mitzumachen

Würde mich freuen, wenn Ihr die Software mittesten würdet.

Bin dabei.

Wegen Passwort: Ich hatte nicht gedacht, dass ich soweit damit komme. Hatte deshalb alles auf Cookies gemacht.

Achtung: Datenschützer Quengeln wegen allem - da braucht man nicht allzu viel drauf geben, solange man eine Ordentliche Verschlüsselung(oder Zwei) und einen(oder 2) Salts nutzt.

PS: Da war ich 4 Tage nicht aktiv, und dann kommt etwas darein, wo ich etwas Qualifiziert zu sagen kann... Fu^^
MFG