Cookie based Login - Sicherheit

[Theed]

Hallo,

Bisher habe ich für den Cookie-Login immer die $userid + md5($password) gespeichert.

Ich frage mich allerdings, ob dies sicher ist. Denn wenn jemand anders an die Cookies herankäme, könnte diese Person sich einloggen.

[penizillin]

vollkommen richtig. deswegen gibt es bei google auch so viele treffer, wenn man nach "cookies" und "security" sucht.

[jahlives]

PW als Hash im Cookie: Nur eine Frage der Zeit bis ein nicht allzuschweres PW mittels Brute Force geknackt wurde. Jeder der an den Cookie kommt hat ein nicht zu komplexes PW in ein paar Minuten "errechnet"

Gruss

tobi

[tontechniker]

PW als Hash im Cookie: Nur eine Frage der Zeit bis ein nicht allzuschweres PW mittels Brute Force geknackt wurde. Jeder der an den Cookie kommt hat ein nicht zu komplexes PW in ein paar Minuten "errechnet"

Du meinst ausprobiert? Wie du nen md5 zurückrechnest möchte ich mal gerne sehen.
Die Frage ist warum man nicht einfach auf Sessions zurückgreift.

[ministry]

Wenn das Passwort irgendwie verwurstet im Cookie steht und überprüft wird, dann gibt es dadurch immerhin die Möglichkeit, dass ein User durch PW-Änderung alle bereits verteilten Auto-Login-Cookies zunichte macht.

Was gäbe es da sonst für Alternativen?

[ghostgambler]

Original geschrieben von ministry
Was gäbe es da sonst für Alternativen?

Da man die UID im Cookie ja auch irgendwie einer user-id zuordnen muss und das für gewöhnlich über eine DB läuft kann man einfach alle Cookies unbrauchbar machen mit DELETE FROM autologin_cookies WHERE user_id = XYZ;

[jahlives]

Du meinst ausprobiert? Wie du nen md5 zurückrechnest möchte ich mal gerne sehen.

Drumm "errechnet" und nicht errechnet drumm auch Brute Force

Gruss

tobi

[ministry]

Original geschrieben von ghostgambler
Da man die UID im Cookie ja auch irgendwie einer user-id zuordnen muss und das für gewöhnlich über eine DB läuft kann man einfach alle Cookies unbrauchbar machen mit DELETE FROM autologin_cookies WHERE user_id = XYZ;

Dann müsste es für den User aber eine Funktion geben "Lösche meine Autologin-Cookies". Unschön.

[ghostgambler]

Original geschrieben von ministry
Dann müsste es für den User aber eine Funktion geben "Lösche meine Autologin-Cookies". Unschön.

passwort-ändern.php

<?php
if ($_POST['submit']) {
  $db->query("UPDATE users SET pw = '" . sha1($_POST['pass']) . "' WHERE user_id = " . $user_id);
  $db->query("DELETE FROM autologin_cookies WHERE user_id = " .
    $user_id . " AND cookie_id != '" . addslashes($_COOKIE['autologin']) . "'");
}
...

Was willst du jetzt von mir?

Ob ich jetzt den Cookie auf dem Client kille oder in der DB ist doch total egal, Code kostet beides...

[ministry]

Was willst du jetzt von mir?

Nichts von dir persönlich.

Es ist alles nicht ideal.

Wenn im Cookie das Passwort nicht vorkommt, dann kann ich solange an der Cookie-ID rumfummeln, bis ich einen von einem anderen user erwischt habe.

Wenn es drin vorkommt, dann brauche ich keine extra Tabelle für die Cookies. Außerdem werden sie von selber ungültig, sobald sich das Passwort ändert.

Es muss ja nicht offensichtliches MD5 sein, da ist der Phantasie ja keine Grenze gesetzt.

[ghostgambler]

Original geschrieben von ministry
Wenn im Cookie das Passwort nicht vorkommt, dann kann ich solange an der Cookie-ID rumfummeln, bis ich einen von einem anderen user erwischt habe.

Warte, lass mich kurz überlegen - wie finde ich schneller einen Treffer, beim md5 Hash vom Passwort+Salt oder beim md5 von einem kompletten random-Wert?
(fifty:fifty würde ich sagen...)
Das hängt wohl vielmehr einfach von der Länge ab, als vom Inhalt.

Wenn es drin vorkommt, dann brauche ich keine extra Tabelle für die Cookies. Außerdem werden sie von selber ungültig, sobald sich das Passwort ändert.

Es muss ja nicht offensichtliches MD5 sein, da ist der Phantasie ja keine Grenze gesetzt.

Wenn das ganze über die DB läuft hat man die Möglichkeit Cookies die schon länger nicht mehr benutzt wurden für ungültig zu erklären - das hat sehr wohl Vorteile, wenn man es über die DB laufen lässt.
Mal ganz abgesehen davon, dass sich der Salt rein theoretisch erraten lässt, indem man sich anmeldet und dann mit Passwort-Brute Force den md5-Hash knackt...
Sobald man den wiederum hat kann man eine Wörterbuch-Attacke los schubsen.

Die vollkommen user-unabhängige UID ist da in der Theorie definitiv die bessere Variante - und die paar DB-Lookups beim uneingeloggten Seitenaufruf mit vorhandenem Cookie wird mit Sicherheit nicht zu einem bottle neck der DB - da gibt es wesentlich größere Probleme ^^;

[ministry]

Okay, seh ich ein. Werd mich bei meinem nächsten Auto-Login davon inspirieren lassen.

[Theed]

Danke für eure zahlreichen Antworten.

In demfall sit es wohl am besten, wnen ich eine neue table für die Autologins mache, und einen(oder mehrere) Zufallsstring/Hash generiere welcher einer UserId zugeordnet ist. Zudem noch ein Attribut für die Ablaufzeit des Autologins.
|Hash1|Hash2(etc)|UserId|Expires
Die Hashes werden dann lokal als Cookie gespeichert.

[ghostgambler]

Original geschrieben von Theed
|Hash1|Hash2(etc)|UserId|Expires

Die Spalte Hash2 ist unnötig, bzw. scheiße...
Normalisier die DB und leg pro Hash einen Datensatz an - ggf. dann halt die user_id nur als index und nicht als unique - aber pro Spalte den Hash zu speichern ist banane, das macht nur Probleme, wenn man auf einmal mehr Hashes speichern will als Spalten da sind - erschwert die vernünftige Indizierung der DB (auf einmal benötigt man 2 Indexe über jeweils 2 Spalten wobei eine redundant ist), etc. pp.

[Theed]

Ich bin mir nicht sicher, aber ich denke dass wir aneinader vorbeireden.
Die Spalte hash2 ist nicht für den 2. Autologin, sondern als 2. "Identifizierungshash".

Hash1 und Hash2 werden lokal als Cookie gespeichert. Pro Autologin respektive user gibt es dann je einen neuen Tupel. Falls die beiden Hashes mit einem Eintrag übereinstimmen, wird der User als Benutzer mit der ID UserId eingeloggt.
Ich dachte ich nehme die Hashes als Index, und die UserId als PK.