[PHP] Login Script

Anachronist · 25 Februar 2007

Hoi,
ich habe eine homepage mit einigen usern die sich über ein login script einloggen, welches die daten (username und PW) in sessions speichert.
nur habe ich gelesen, dass sessions nicht das optimum für ein login script sind.

welches sind denn die anderen lösungen?
vllt hat ja einer nen link oder wenigstens nen stichwort parat.

hatte mir auch schon überlegt, dass eine ip adresse einem bestimmten benutzer zugeteilt wird (wenn er sich einloggt, dann ip und user in txt datei oder so).
ich hoffe mal, dass es noch andere, bessere vorschläge gibt.
danke

Icy · 25 Februar 2007

A)
warum sollte man generell keine Sessions benutzen? kannst du mal den Grund zitieren? vielleicht steht der nur in einem gewissen Zusammenhang.

B)
über IPs würde nicht unbedingt gehen, da mehrere User die gleiche IP haben könnten oder auch ein User mehrmals die IP wechseln kann

Man könnte über session_start() und $_SESSION gehen oder per Hand sowas zusammenfrickeln. Die Session ID kann man bei einer Eigenlösung über ein Cookie oder $_GET übergeben lassen, überdiese serverseitig der Status über mehrere Seitenaufrufe hinaus festgehalten wird.

Benutzt man session_start()/$_SESSION und hat sein Projekt auf einem Shared Hosting Server liegen, sollte man aus Sicherheitsgründen zusätzlich drauf achten, das der "save_path" auf einem Pfad zeigt, wo andere Hostingkunden kein Lesezugriff haben.

Anachronist · 25 Februar 2007

Icy schrieb:
A)
warum sollte man generell keine Sessions benutzen? kannst du mal den Grund zitieren? vielleicht steht der nur in einem gewissen Zusammenhang.

https://www.it-academy.cc/article/1455/PHP:+LoginScript+(Sicherheit+mit+Sessions).html
da steht das in den kommentaren.

jo also ich wollte einfach mal hören, was es sonst noch für möglichkeiten gibt.
ich würde es meinen usern gerne ermöglichen, dass sie sich einmal einloggen, und dann nur noch alle 4 wochen oder so. Wie bei klamm so in der art

oder bei eBesucher, wo man auswählen kann, wie lange man eingeloggt bleiben will...

Icy · 25 Februar 2007

Ich sehe in den Kommentaren nichts von, das man Sessions nicht benutzen darf.
Ich sehe lediglich die (berechtigte) Kritik, das man Passwörter nicht in der Session speichern sollte, man kann auch es auch anders machen und in der $_SESSION ein Status/Flag setzen, der einmalig beim ein/ausloggen geändert und auf jeder Seite abgefragt wird.

joschilein · 25 Februar 2007

Was wichtiges vorweg:
Es ist kein Fehler Cookies zu verwenden, es ist nur ein "tödlicher" Fehler den dort enthaltenen Daten zu trauen - selbst wenn man der Meinung ist, die Daten selbst dort hinterlegt zu haben. Alle Daten, die vom Besucher kommen (Formular [z.B. hidden oder readonly Felder] (POST), Adresszeile (GET), Cookies (COOKIE)), können von diesem manipuliert sein. Also immer mit SQL Injections und ähnlichem Schweinekram rechnen.
Außerdem sollte man keine Passwörter in Cookies speichern. Das gefährdet zwar nicht primär den Server, man sollte aber trotzdem darauf achten (Cookies können geklaut werden => Nachteil für den Besucher).

Folgende Vorgehensweise kann als relativ sicher angesehen werden:
:arrow:

Passwörter werden in der Datenbank als Hash (z.B. md5) nach einer Salt-Kombination (eine systemweit immer gleiche aber individuelle Zeichenkette) gespeichert:

PHP:

$salt = 'hkgsdfkjKJHKLg45tzihgasdjhJHGJH§gjh45g365'; // Beispiel
$pw_db = md5($pw_login.$salt); // $db_pw ist in der DB zu speichern, $pw_login kommt aus dem Formular ($_POST verwenden)

Bei einem späteren Login, wird das eingegebene Passwort entsprechend Punkt 1 behandelt. Das Ergebnis wird mit dem in der DB gespeicherten Hash verglichen. Sind die Daten gleich, ist das Passwort richtig eingegeben.

:arrow:

In Sessions wird dann mit einem zweiten Salt-Kombination gearbeitet. Dieser kann/sollte öfters mal geändert werden (Übergangfsehler beachten: User meldet sich an, als Salt A gilt, Cookie hat eine Lebensdauer von 4 Wochen und nach einer Woche wird im System der Salt geändert => Prüfung auch mit altem Salt laufen lassen).

PHP:

$salt2 = 'askgfdjshf4325245ahgKJHSJHGFD';

if ($pw_db == $pw_login){ // $pw_db und $pw_login nach Behandlung von oben
  $pw_session = md5($pw_db.$salt2); // Wird im Cookie gespeichert, der Username natürlich ebenfalls
}

Zur Überprüfung der Gültigkeit der Cookie Daten, wird nun die $pw_db - Salt2 Kombination (die durch Angabe des Usernamens im Cookie erstellt wird) mit dem Hash aus dem Cookie verglichen.

chrissel · 6 März 2007

joschilein schrieb:
...

Ich habe da auch noch einmal eine Frage zu

Reicht es nun im Prinzip wenn ich den md5() von dem Passwort in dem Cookie speicher?
Das mit dem "salt" kapiere ich nicht soganz was es bringt...
Ob bei dem String für den md5() nun noch einen anderen, immergleichen String dranhängt oder nicht...

Samy · 6 März 2007

MD5 ist knackbar desweben der Salt... so kann man einfache Strings nicht so leicht auslesen...
Passwort gehört auch als md5 nicht ins Cookie

chrissel · 6 März 2007

Ah, okay. Nun verstehe ich es mit dem Salt :idea:

! Hätte ich auch selber draufkommen können :think:

.

Und wie soll man dann ohne Passwort im Cookie dann ein Autologin machen?
Als MD5 mit Salt wäre es ja eigentlich sicher. Ausser wenn natürlich wer die Cookies klaut, und die bei sich selber setzt.

joschilein · 6 März 2007

Das mit dem salt bringt sehr viel, da es mittlerweile schon Bemühungen gibt die millionenfachen Möglichkeiten des md5-Hash einfach abzuspeichern um dann zu schauen, welcher String diesen speziellen Hash erzeugt. Das ist zwar mit Kanonen auf Spatzen geschossen und scheitert auch noch etwas an der entstehende Datenbankgröße, doch theoretisch ist es möglich und mit steigender Computerleistung erst recht.
Wenn ein Angreifer also rausfinden würden, dass der Hash durch den String abcd1234 erzeugt wird, bringt es ihm nichts, wenn er abcd1234 eingibt, da du dann intern abcd12341234 draus machst und dann wieder ein anderer Hash entsteht, der aber nicht mit dem in der Datenbank übereinstimmt => kein Zugriff, kein Cookie, kein zu analysierender neuer Hash für den Angreifer. Er müsste dann bei der Analyse von vielen Hash erstmal rausfinden, dass deren Strings alle auf 1234 enden, um dann daraus zu schließen, dass das der Salt ist und die Eingabe entsprechend zu kürzen. Je verworrener der Salt eingebaut wird, desto effektiver, aber wichtig ist erstmal, dass er überhaupt verwendet wird.

chrissel · 6 März 2007

Und um solänger ja der Salt ist, umsogrößer muss seine Datenbank sein. Denn die Crackersoftware checkt ja glaube ich jede Kombination ob die den gleichen Hash bildet.
So ist es doch gedacht oder ?

(lol^^ Nun habe ich schon mehr Fragen wie der Threadersteller, hoffe mal im bringen meine Fragen auch was ^^)

joschilein · 6 März 2007

Ich selbst würde sogar dazu übergehen nach einem bestimmten Muster einen langen Salt einzumischen. Also wenn Text A das Passwort und Text B der Salt ist sowas wie BABAAABBBABBABBBBAABBABBBBBBBBBBBBBBBBBBB draus machen.

Naja theoretisch sollte bei einem Hash-Verfahren ja jeder Input einen anderen Hash ergeben, aber bei md5 sind ja schon Kollisionen gefunden worden und dann hätte der Angreifer ein Problem, wenn er statts obigem String nur den String "hw3t" in seiner Liste stehen hat, da könnte er dann lange probieren :biggrin:

(oder sich natürlich einen anderen Weg suchen)

ZeroCCC · 6 März 2007

joschilein schrieb:
In Sessions wird dann mit einem zweiten Salt-Kombination gearbeitet. Dieser kann/sollte öfters mal geändert werden (Übergangfsehler beachten: User meldet sich an, als Salt A gilt, Cookie hat eine Lebensdauer von 4 Wochen und nach einer Woche wird im System der Salt geändert => Prüfung auch mit altem Salt laufen lassen).

PHP:

$salt2 = 'askgfdjshf4325245ahgKJHSJHGFD'; if ($pw_db == $pw_login){ // $pw_db und $pw_login nach Behandlung von oben $pw_session = md5($pw_db.$salt2); // Wird im Cookie gespeichert, der Username natürlich ebenfalls }

Zur Überprüfung der Gültigkeit der Cookie Daten, wird nun die $pw_db - Salt2 Kombination (die durch Angabe des Usernamens im Cookie erstellt wird) mit dem Hash aus dem Cookie verglichen.

zu was musst du bitte das passwort in der session mitführen? und dann noch der aufwand jedes mal den salt zu ändern...
da kann ich auch gleich so arbeiten wie die php sessions... ich erzeug ne eindeutige id die mit daten auf den server verknüpft ist und diese verfällt nach x stunden. somit kann jemand nur nen paar stunden mein account nutzen wenn ihm das cookie in die hände fällt... wenn dass passwort nimmt kann er solange den account nutzen bis dass passwort geändert wird oder jemand den salt ändert.

und zum thema autologin... da ist es normal dass man dass passwort und nochwas im cookie speichert, dass ist aber ok da der user selbst entscheiden kann ob dass passwort gespeichert werden soll oder nicht.

@Anachronist das tutorial von https://www.it-academy.cc/article/1455/PHP:+LoginScript+(Sicherheit+mit+Sessions).html ist nicht das gelbe. das passwort und den username inner session zu speichern ist unsinn und unsicher. man kommt besser wenn man einfach die user id oder sowas in der session speichert... zum thema unsicher bevor hier welche schreien. bei vielen shared hostern werden alle session in einem verzeichniss gespeichert, dass kann man am ende mit php auslesen somit hat man auf den inhalt aller session zugriff und mit nem username und passwort kann man mehr anfangen als mit ner user id

natürlich muss man noch rausfinden zu welcher seite die session gehöhrt... aber das machen ein manche hoster auch leicht. ausser sie hosten da 500 domains aufm server... da wirds schon schwere die passende zu finden.

Anachronist · 6 März 2007

cb1992 schrieb:
(lol^^ Nun habe ich schon mehr Fragen wie der Threadersteller, hoffe mal im bringen meine Fragen auch was ^^)

ich verfolge diesen thread immer aufmerksam und danke jedem, der sich mit diesem thema weiter auseinander setzt, kommen ja sehr interessante sachen bei raus... und so lange du mich fragst, warum deine tastatur mit QWERTZ anfängt is es doch in ordnung.

ZeroCCC schrieb:
z

@Anachronist das tutorial von https://www.it-academy.cc/article/1455/PHP:+LoginScript+(Sicherheit+mit+Sessions).html ist nicht das gelbe. das passwort und den username inner session zu speichern ist unsinn und unsicher. man kommt besser wenn man einfach die user id oder sowas in der session speichert... zum thema unsicher bevor hier welche schreien. bei vielen shared hostern werden alle session in einem verzeichniss gespeichert, dass kann man am ende mit php auslesen somit hat man auf den inhalt aller session zugriff und mit nem username und passwort kann man mehr anfangen als mit ner user id natürlich muss man noch rausfinden zu welcher seite die session gehöhrt... aber das machen ein manche hoster auch leicht. ausser sie hosten da 500 domains aufm server... da wirds schon schwere die passende zu finden.

hey danke

mh, also werd ich entweder die passwörter meiner user verschlüsselt in der session speichern oder halt nur die ID muss das alles hier nochma aufmerksam durchlesen.

chrissel · 6 März 2007

Du kannst ja z.b. auch die SessionID ( session_id() ) beim Login in der Datenbank speichern, und dann immer gucken ob die SessionID gleich der SessionID von dem User aus der Datenbank ist. So mache ich es meist.

Anachronist schrieb:
ich verfolge diesen thread immer aufmerksam

Anachronist schrieb:
muss das alles hier nochma aufmerksam durchlesen.

lol^^

Anachronist · 6 März 2007

hupsi...
naja ironie
man beachte meine signatur....

[PHP] Login Script

Anachronist

Well-known member

Icy

*

Anachronist

Well-known member

Icy

*

joschilein

Multitalent

chrissel

Woohooo!

Samy

...

chrissel

Woohooo!

joschilein

Multitalent

chrissel

Woohooo!

joschilein

Multitalent

ZeroCCC

wasn das?

Anachronist

Well-known member

chrissel

Woohooo!

Anachronist

Well-known member

Ähnliche Themen