Sicheres Cookie Login System?

Hab mir in einem Loginscript mit "eingeloggt bleiben" -Funktion überlegt:

Und zwar wie kann ich ein cookie sicher speichern und manipulationen erkennen bzw gleich vorbeugen.

Folgendes passiert beim einloggen mit cookie:

• In der User SQL-Table wird ein (random) cookie token und ein cookie key ersellt und gespeichert
• Die UserId (=! Login Nickname) wird "gesalzen" mit einer fixen Konstanten und md5-gehasht
• Das Cookie Array wird erstellt:
  
  
  • User-ID im Klartext
  • Cookie-Token
  • Cookie-Salt
  • weitere: privilegien, restriction level,loginintime etc.
  • Die IP Adresse wird gesalzen mit anderen attributen und dem Cookie-salt und gehasht - mit einem starken sha256 (erkennt komprmiteirte cookie attribute und cookie-hijacking auf andere pcs - das updaten eines browsers ist erlaubt)

  
  

• Danach wird das array serialisiert und mitteles mcrypt und RIJNDAEL 256bit (AES), CBC-mode (symentrisch) verschlüßelt. Der Key besteht aus dem dynamischen cookie-key (der in der SQL steht) und einer fixen konstanten. Der IV (initialvektor) steht fix im Code.
• Die gehaste und gesalzene User-ID wird am anfang an den verschlüsselten Text angehängt
• Danach wird das ganze noch komprimiert (gzcompress) und bas64 codiert um 1. 2 dünne hüllen encodierung hinzuzufügen und das einfache manipulieren unterbunden wird und 2. das cookie verkleineret und die daten etwas gesichert werden gegen korruption.
• Das Cookie ist dann < 1kb und sollte ohne Porbleme auf jedem browser aktzeptiert werden können

Beim einloggen mittels cookie:

• Das cookie wird decodiert und unkomprimiert.
• Die gehashte (u. gesalzene) user id mit der SQL verglichen und wenn es einen match gibt, wird der cookie key geladen.
• Mit diesem cookie-key (u. der fixen Konstante u. IV) wird dann das cookie array entschlüsselt und deserilisiert.
• Jetzt beginnt der eigentliche loggin prozess:
  
  
  • Die user-id, das cookie token und andere wichitige attribute werden mit den werten aus der SQL datenbank verglichen.
  • Bei erfolgreichen loggin wird ein neues Cookie erstellt (siehe prozedur oben) und die sessions geladen damit die gesicherte seite angesehen werden kann

  
  

Vorteile:

• Anstatt des Passwortes oder des Nicknames wird "nur" die User-ID und das Cookie Token gespeichert. So kann man nie auf das passwort schließen und nur sehr schwer auf den nickname.
• Bei jedem einloggen oder ausloggen wird ein neues cookie token erstellt, was jedes alte cookie sofort ungültig macht - dies hat zwar einen geringen usability schwachpunkt, das man sich nur bei einem PC permanent einloggen kann, das ist aber ein guter kompromiss wie ich finde.
• Das Cookie wird mittels immer wieder neu generierten key (kombiniert mit einer Konstanten) und starkem RIJNDAEL-Code verschlüsselt (ähnlich des cookie tokens) was es quasi unmöglich macht ein cookie zu fälschen. Bei jedem ein- ausloggen wird der cookie key verändert
• Die IP wird gehasht gespeichert, damit das cookie nur mit dieser ip gültig ist
• Als hash verfahren verwende ich das stärkere sha256 (zu md5).
• mit der IP werden andere wichitge atribute gehasht um kompromitirte daten und manipulationen zu erkennen.
• Bei einem fehlerhaften cookie-login versuch werden sofort cookie-token und cookie-key geändert (sowie das cookie gelöcscht)
• Es werden auch immer alle attribute mit der SQL DB verglichen um manipulationen zu erkennen.
• Dadurch das die User-ID, die dem verschlüßelten Teil vorangestellt wird, mit einem fixen salt gehast wird, ist es sehr schwer selbst eine user id zu generieren, was aber auch keine auswirkungen hätte, da enwteder der user nicht gefunden wird oder der falsche key geladen wird
• Durch das kodieren und komprimieren wird das cookie verkleinert und "obfuscated".
• Das Cookie wird mit dem "neuen" setcookie gesetzt und dem parameter - nur cookie manipulationen über http zulassen (nicht unterstütz von allen browsern) um XXS - Attacken und fern-cookie manipulationen vorzubeugen

Als Schwachpunkt ist vlt. der fixe IV, und die funktione serialze, die ja nicht die sicherste sein soll. Weiters ist es vlt. auch nicht das schnellste system, aber aktuelle server sollten da aber kein problem haben. (also in der praxis merk ich nix)

Wäre über bemerkungen über dieses cookie-login system erfreut!

Also, das Cookie-Login system ist ja nur ein teil des gesamten login scripts - und zwar nur dafür da um eine "eingeloggt bleiben" funktion funktionieren kann (und das geht halt nur mit cookie) - und das ist ja eher ein usability plus.

Man kann wenn man will auf cookies verzichten, dann ist man eben 20 min eingeloggt.

Zitat

Du erlaubst gnädigerweise ein Browser-Update, aber wenn man z.B. seinen Laptop woanders ans Internet hängt, oder von seinem Provider einfach so eine andere IP zugeteilt bekommt, kann man sich brausen gehen? Von "nur bei einem PC", wie du schreibst, ist keine Rede. (Also insofern nicht, als du suggerierst, mit diesem einen PC würde es immer gehen.)

Ich sehe aber keine andere möglichkeit (viele) "cookie-hijacking attacken" zu verhindern. Wenn man auf einem proxy sitzt der zB bei jedem request eine neue ip sezt ist ja nur die cookie funktion kompromittiert, man kann sich ja einfach neu einloggen - ein annhembarer kompromis wie ich finde.

Also ich sehe das szenario, ip ändern sich ständig, als realistisch, aber nicht als üblich.