[PHP] Geschützter Bereich mit Cookies

CPU

Lieutenant
Registriert
Jan. 2006
Beiträge
704
Hi Leute,

zu dem Thema "Passwordgeschützter Bereich bzw. Loginbereich mit PHP" gibt's mit Google ja Einträge wie Sand am Meer. Trotzdem möchte ich nicht irgentein Skript abschreiben sondern es selbst verstehen!

Ich hab mir das so gedacht:

Wenn man sich anmeldet wird ein Cookie gesetzt, der folgendes enthält:
  • Anmeldetimestamp (time())
  • Passwort (verschlüsselt)
  • Benutzername
  • sec_id_a
  • sec_id_b
  • (evt. IP-Adresse)
... diese Werte kette ich allesamt aneinander durch ein "|". Gleichzeitig wird in die Datenbank der Timestamp, die sec_id_a und die sec_id_b (sec_id's = Zufallszahlen) eingetragen.

Danach wird man weitergeleitet und die Geschützten Seiten überprüfen die Übereinstimmung der Werte des Cookies mit der Datenbank, stimmen sie, is alles OK, ansonsten wird der User rausgeworfen!

Beim Logout wird der Cookie gelehrt!

Doch wie sicher ist nun mein entwickeltes Verfahren?
Kann man damit leben! Ich will damit nichts besonderes schützen, nur den Administrationsbereich einer kleinen Website! :)

Vielen Dank für Beiträge,

CPU
 
Hallo,

klar kann man damit leben. Etwas runder finde ich es, wenn man das ganze Login-Gedöhns in einer Session speichert. Das hat ein paar Vorteile:


  • Das verschlüsselte (Hash-Verfahren?) Passwort auf dem Client-Rechner kann benutzt werden, um sich jederzeit im Admin-Bereich anzumelden. Dazu müsste man nur die Cookie-Datei der Seite im Notepad öffnen, die paar Daten auslesen und einen ensprechenden Request mit deinen Daten an den Server schicken. Deine Anmeldedaten wären somit bekannt und man könnte unbemerkt manipulieren (vorausgesetzt, du änderst dein PW nicht). Selbst nach Löschen des Cookies könnte man im Dateisystem die Daten wiederherstellen.
    Die Session-Daten und mit ihnen die -ID verfallen irgendwann (je nach Einstellung). Auf dem Client wird nur die ID gespeichert. Ein Anmelden wäre mit der ID zwar möglich, für zukünftige Angriffe müsste man sich aber wieder von deinem Rechner die ID holen oder gleich das PW für deinen Account ändern, was du schnell bemerken solltest. Nach einem Logout würden die Daten in der Session gelöscht und man könnte mit der ID nichts mehr anfangen.

  • Wenn ein Browser keine Cookies unterstützen sollte, kann die Session-ID auch über die URL übermittelt werden (Stichwort transiente Übermittlung der Session-ID). Das ist für den Entwickler sehr komfortabel und der Anwender merkt davon nichts. Bei deiner Lösung müsste man das gesondert behandeln.

Wie auch immer, beide Verfahren haben Schwachstellen und man kann (und wird wahrscheinlich) darüber streiten. Wenn man aber Sessions verwendet und sich immer schön ausloggt, kann eigentlich nichts passieren. Bei beiden oben genannten Szenarien bräuchte ein Angreifer eh lokalen Zugriff auf einen Client-Rechner. Meist kann man das ausschließen (oder hast du fiese Geschwister?).
Gegen echtes Mithören helfen aber auch Sessions nicht. Hier ist eine verschlüsselte Verbindung angebracht, wobei man abwägen muss, ob sich der Aufwand für die private HP lohnt...

Gruß, Gobble-G
 
CPU schrieb:
Beim Logout wird der Cookie gelehrt!
Müsste es nicht belehrt heißen?



Also wenn es sich für um eine rein private Seite handelt, denke ich reicht diese Vorgehensweise. Ideal ist es, wenn du auf der Seite gar keinen Link für den administrativen Bereich setzst, sondern ihn nur über manuelle Eingabe einer URL erreichst (kannst ja über Favoirten speichern...) - wer nicht weiß, wo er "angreifen" kann, kann auch nciht angreifen ;-)
 
Müsste dann "geleert" heißen (wie leer).

Aber BTT: Für eine private Seite sollte die Methode reichen, ich würde es aber auch (wie Gobble-G schon sagte) über Sessions machen.

mfg
 
Backslash schrieb:
Müsste dann "geleert" heißen (wie leer).
Das ist mir schon bekannt (deswegen auch gelehrt in " "), aber das ist so eine Sache mit der Orthographie... ;)
Vielleicht soll ein User belehrt werden? Aber über was?
 
Zuletzt bearbeitet:
1668mib schrieb:
Ideal ist es, wenn du auf der Seite gar keinen Link für den administrativen Bereich setzst, sondern ihn nur über manuelle Eingabe einer URL erreichst (kannst ja über Favoirten speichern...) - wer nicht weiß, wo er "angreifen" kann, kann auch nciht angreifen ;-)
Es sei aber erwähnt, dass security through obscurity als alleiniges Sicherheitsmerkmal nicht gern gesehen ist. Das spielt in dem Fall wahrscheinlich keine Rolle, aber CPU sollte es dennoch wissen, finde ich.
 
Hi,

natürlich meine ich geleert!

1. Klar ist es Besser, wenn die Daten garnicht erst zum Clienten gelangen, doch kann er mit dem Passwort nichts anfangen, da ich es durch einen eigenen Algorithmus verschlüssele. MD5 kann man ja ausheblen, da es bekannt ist, aber meins ist unbekannt, außerdem kennt keiner den Code dafür und kann nicht zum Entschlüsseln ansetzen.:)

2. Auslesen der Cookies und erneut senden. Auslesen, nach dem löschen, ist möglich (?!), wusste ich vorher noch nichts, dachte, wenn man sie löscht sind sie weg.

Das mit den Cookies verstehe ich nicht! Wie soll das gehen:
ensprechenden Request mit deinen Daten an den Server schicken

Die sachen, die Geschickt werden und variabel sind müssen ja auch in der (MySQL) DB stehen (!), d.h. man kann zwar die sec_id's auslesen, doch nach ordentlichem Ausloggen wird die DB ja geleert und die sec_id's sind nicht mehr da! Nun gut, man könnte sagen, dass man nun den Wert "" für die Sec_id's eintragen kann, doch ich schütze es vor keinen Einträgen in den sec_id's (außerdem wären da noch die IP, die in die DB muss, genauso wie der Logintimestamp!

Zur Erinnerung außerdem:
Cookie-Parameter:
  1. Name
  2. Inhalt
  3. Verfallsdatum
  4. Pfad
  5. Domain
  6. secure

Und wenn sich ein "Hacker" aus - mir - schir unerklärliche Gründen an dieser Administration interessieren sollte, muss er ja ersteinmal an den Cookieaufbau rankommen, und wenn er nicht das richtige Passwort hat, dann wird auch kein Cookie gesetzt!

3. Außerdem ist alles ja nicht "wirklich" sicher (außer SSL und das ist für meine HP zu teuer und unütz), und ich möchte ja auch nur eine Seitenadministration schützen, und nicht den Intranet-Server der amerikanischen Regierung (!) und so wie Gobble-G sagt, kann man ja nur lokal darauf zugreifen und die Administratoren (5-6 Stk.) haben wohl kaum Interesse sowie Ahnung an der Aushebelung der Sicherheit!

Natürlich gibt es 1000de Wege alles besser oder schlechter zu machen, genauso wie knacken, aushebeln & Co.!

Doch vielen Dank für die Beiträge (vorallem Gobble-G) und noch einen schönen Tag,

CPU :p
 
Sind hier alle Ironie-immun?
natürlich is mir klar, dass man Cookies net belehrt, ich fand es nur einen lustigen Schreibfehler :-)

@Gobble-G: Es war auch nicht so gemeint, dass er dann auf zusätzliche Login-Abfragen verzichten könnte...
 
1668mib schrieb:
@Gobble-G: Es war auch nicht so gemeint, dass er dann auf zusätzliche Login-Abfragen verzichten könnte...
Stimmt. Jetzt, wo ich es mir noch mal durchlese, hab ich das wohl falsch interpretiert. Alles klar.
 
@Geschützter Bereich:

Weiß eigendlich jemand wie man mit dem Sessions umgeht? Hab die Erklärung gelesen und verstehe momentan nur Bahnhof...^^
*(Mein AdminCenter* hab ich auch nur mit Cookies gesichert :)*
 
Zuletzt bearbeitet:
Wie weiß eigentlich jemand wie man mit den Sessions umgeht? Wenn ich jetzt als Antwort ja sage, hilft dir das nicht weiter, oder? Was genau verstehst du nicht?
 

Ähnliche Themen

Zurück
Oben