Wie funktioniert eigentlich ein Login?

  • Hm... Ich schaff es irgendwie nur noch Sporadisch mal in Forum zu schauen...
    So immer, wenn mir mein Passwort mal wieder einfällt....
    Heute treibt mich mal wieder eine lustige Frage, wir melden uns tagtäglich in irgendwelchen Foren unseren Accounts auf Websites, unseren Rechnern usw an. Nachdem ich jetzt ein paar Tage mit php gespielt habe stellte sich mir plötzlich folgende Frage:


    "Wie funktioniert ein Login eigentlich?"

    Jemand hier, der's mir erklären kann, würd mich echt mal interessieren... ^^
    Es müsste ja irgendwie in Richtung:
    Datein eingeben -> Absenden -> Datenbank Abfrage -> Bestätigung als 'true/false' -> ???
    Sein...


    Gruß!
    Quappe
    (ehemals Nachtschatten)

  • Du bist da schon auf dem richtigen Weg...
    Mein Informatiklehrer erklärte es uns folgendermaßen:
    1. du gibst dein Passwort ein.
    2. es wird verschlüsselt un des kommt eine Prüfsumme raus.
    3. Die Datenbank checkt, ob die Prüfsummen übereinstimmen (Denn Passwörter zu speichern, wär ja Datenschutzwahnsinn! :crazy: )

    Zitat von Das Lied von Eis und Feuer: Die Saat des goldenen Löwen, S. 103

    Die Macht ist stark in dir.

  • Achso, soweit war mir das auch schon klar, hatte das ganze gewusel Testweise mit PHP und einer mySQL Datenbank nachgebildet, da das alles lokal auf xampp lief hatte ich mir die Verschlüsselung geschenkt.
    Aber ich frag mich wie es weiter geht, ok, meine Datenbank hat jetzt geantwortet, aber wie muss es weiter gehen?
    Bleibt die Verbindung bestehen? wird eine Variable $login = false; auf true gesetzt?
    Wie weiß meine Datenbank was Sache ist? Das muss ja irgendwie zwischen gespeichert werden, aber wo?
    Bleiben wir ruhig mal bei meinem Beispiel mit php und mySQL.
    Ich find das grad interessant

  • Puh, ich weiß das nicht so genau... aber auf jeden Fall gibts dann nen Cookie, der sagt, dass du eingeloggt bist.

    Zitat von Das Lied von Eis und Feuer: Die Saat des goldenen Löwen, S. 103

    Die Macht ist stark in dir.

  • Also sind wir dann schon einmal so weit:


    Daten eingeben -> Chiffrieren -> Chiffren Absenden -> Abfrage an die Datenbank (Daten sidn als Chiffren gespeichert) -> Bestätigung der Daten als 'wahr/falsch'
    Wenn: Daten falsch -> Fehlermeldung ausgeben!
    Wenn: Daten wahr -> Cookie generieren -> Login erfolgt!


    In meinem vereinfachten Testsystem also:
    Daten eingeben -> Daten Absenden -> Abfrage an die Datenbank -> Bestätigung der Daten als 'wahr/falsch'
    Wenn: Daten falsch -> Fehlermeldung ausgeben!
    Wenn: Daten wahr -> Cookie generieren -> Login erfolgt!


    Und vor jedweder Aktion abfragen:

    PHP
    if(isset $_COOKIE['login_userID']){ //PHP-Script fortführen. }else{ //Login auffordern. }


    Klappt das wohl so?
    Vor allem: Ist es sinnvoll so?

  • Da es mich selbst interessiert habe ich mal etwas gesucht. Ich glaube das könnte deine Fragen ganz gut beantworten:




    "It checks if your username and password combinations exists in the database, if it does not existst an error
    message will be shown. If it existst, two session variables will be made, these will be needed to check if you are
    logged in."


    Source: http://ycscripts.co.cc/free-ph…/1/User-Management-System
    (Der 7. Punkt um genau zu sein.)

  • Das erinnert mich daran dass ich ins interne Forum schreiben wollte, das das Code Feld grau sein sollte...


    Ja, das hab ich gestern nacht auch noch gefunden, interessanterweise genau das gleiche in Deutsch von irgendwem in ein Forum gesetzt der behauptet hat er hätte das ganz allein... usw. ERTAPPT xD (<-- Amüsier ich mich immer wieder drüber, wenn ich so parallelen finde :p).


    mal sehn, was kann ich dazu sagen....
    mysql_usw. Befehle hab ich mir sagen lassen sind veraltet, stattdessen solle ich die mysqli_usw. Befehle nehmen, das i stände für improved. Kein schimmer ob das stimmt...


    Die Verschlüsselung ist Hirnrissig. sha1() stellt eine Checksumme aus, das zu verschachteln ohne den String wieder zu verlängern macht in meinen Augen keinen Sinn. Das wäre, als wenn man eine abgeschlossene Tür mit einer Kette und drei Vorhängeschlössern sichert, wo man anstatt die Schlösser zu knacken auch die Tür eintreten könnte. Hab gestern auch noch gelesen, das sha1 mittlerweile nicht mehr Kollisionssicher sein soll, es lässt sich also mit (Hochleistungsrechner-) Aufwand eine Zeichenkette finden, die die gleiche Checksumme erzeugt. Aber das mit zu beachten wäre echt paranoid....


    Der Rest scheint ganz gut zu sein, auch wenn ich mich frage warum überprüft wird ob die Datenbank nur eine Zeile zurück gibt.
    Wenn man mit dem Usernamen eine ID holt und das Passwort entsprechend nach der ID sucht, dann kann es zwingend nur ein Ergebnis gegen auch wenn ein Username mehrfach vergeben ist. Vergleichbar mit den UIN's bei ICQ, aber in diesem Fall sollte dann auch die ID als Login Abgefragt werden, da bei eine fast unendlichen fülle an alphanummerischen Passwörtern die Chance relativ hoch steht, das zwei gleichnamige User einfach PENIS als Passwort benutzen. Zumindest würde ich es unserer Spezies zutrauen... :-|


    Was aber mit AND admin=1 AND active=1 gemeint ist ist mir noch schleierhaft....

  • Würde denken, das active einfach sagt, ob der Acc gesperrt ist oder nich.
    Ich habe da unter add user folgendes gefunden:


    PHP
    //save to database when no errors are detected ------------------------------------------
    if (count($error) == 0) {
    $salt = rand(100,999);
    $password = sha1(sha1($password).sha1($salt));
    $query = "INSERT INTO user SET username='".$username."', email='".$email."', password='".$password."', salt='".$salt."', ".
    "`registration-date`='".date('Y-m-d H:i:s')."', active='1', admin='".$admin."'";


    Also wird bei Acc-Erstellung active auf 1 gesetzt. Bei der delete-Aktion wird aktive dann wieder auf 0 gesetzt:


    PHP
    //execution when pressed delete button --------------------------------------------------------
    if (isset($_POST['deleteUser'])) {
    $result = mysql_query("UPDATE user SET active='0' WHERE userID = ".$userID);
    if ($result) {
    echo "<strong>User has been deleted!</strong>";
    }


    Eine Verwendung von admin habe ichnicht gefunden, bin aber auch grade in der Schule. Ich schau zuhause nochmal.

  • Hm... Boolean Wert abfragen ob der User bereits bestätigt ist... Interessant, sollte ich ebenfalls einbauen...
    Aber du hast da grad nen kleinen Denkfehler drin :p
    Du hast 4 Stufen:

    • User existiert nicht: Keine Zeile, d.h. Kein Wert.
    • User ist registriert aber unbestätigt: Zeile existiert, active = false;
    • User ist registriert und bestätigt: Zeile existiert, active = true;
    • User gelöscht: Zeile existiert, active = false;

    Du willst wenn du einen User löscht ihn dennoch in der Datenbank behalten, also kann man es auch bannen nennen, wenn du das aber nur über den Boolean-Wert active für Mitgliedschaft bestätigt/unbestätigt machst, kann der User theoretisch die Bestätigungsmail erneut anfordern und sich damit selbst entsperren, und das ist ja nciht Sinn der Sache...
    Ich würde da mit einem zweiten Boolean oder einem Integer ran gehen:


    Boolean:

    • User existiert nicht: Keine Zeile, d.h. Keine Werte.
    • User ist registriert aber unbestätigt: Zeile existiert, active = false; banned = false;
    • User ist registriert und bestätigt: Zeile existiert, active = true; banned = false;
    • User gesperrt (einfacher Bann): Zeile existiert, active = true; banned = true; (Login noch Möglich, aber Mundtot.)
    • User gesperrt (Ausschluss):Zeile existiert, active = false; banned =true; (Login verboten.)
    • User gelöscht: Zeile gelöscht, d.h. Keine Werte.
      (Der User wird aus der Datenbank gelöscht, alle Angaben sind wieder frei, ausgenommen der ID, die fortlaufend, selbständig von der Datenbank vergeben wird)


    Geht man über einen Integer daran:

    • User existiert nicht: Keine Zeile, d.h. Keine Werte.
    • User ist registriert aber unbestätigt: Zeile existiert, active = 0;
    • User ist registriert und bestätigt: Zeile existiert, active = 1;
    • User gesperrt (einfacher Bann): Zeile existiert, active = 2;
    • User gesperrt (Ausschluss):Zeile existiert, active = 3;
    • User gelöscht: Zeile gelöscht, d.h. Keine Werte.

    Die Abfrage würde ich dann in beiden fällen über einen Switch-Case gestalten, der Integer wär da einfacher einzugeben, bedarf aber eine Erklärung, der Boolean macht bei der Eingabe mehr Aufwand, ist aber selbsterklärend...
    Was böte sich da jetzt eher an? :?:


    Zudem wär interessant zu wissen, was genau $_SESSION macht bzw. darin gespeichert wird.
    admin zumindest scheint für die Benutzerkontnesteuerung wichtig zu sein (du hattest das interne Admin Login gepostet).

  • PHP
    //if username and password matches put userID in authentication session for later use
    if (mysql_num_rows($result) == 1) {
    $row = mysql_fetch_assoc($result);
    $_SESSION['auth_admin_userID'] = $row['userID'];
    $_SESSION['auth_admin_username'] = $username;


    "It checks if your username and password combinations exists in the database, if it does not existst an error
    message will be shown. If it existst, two session variables will be made, these will be needed to check if you are
    logged in.
    "


    Dazu der Link. $_SESSION['xyz'] erstellt ein Array mit dem Spaltenname xyz. Was hinter dem = kommt wird der Inhalt der 2. Zeile in dieser Spalte. Da dieses Array global ist kannst du es nun in deinen anderen Seiten verwenden und abfragen. In dem Beispiel wird dadurch die UserID und der Username abgefragt, was dann quasi bei jedem öffnen einer neuen Seite abgefragt werden könnte. Dadurch könnten dann halt auch entsprechende "Max Mustermann war auf deiner Seite"-Funktionen eingefügt werden.


    Ich weiß zwar nicht, ob das dein Problem schon löst, aber ich hoffe es hilft zumindest.

  • Ich hab mir grad folgendes in PHP als Kommentar notiert.
    (Ich brauch das immer etwas aufgedröselt, damit ich nicht den Faden verliere)


    Das war jetzt meine "Graupause" (Kommentare werden bei mir im Editor grau gezeigt).
    Mein Code wird demnach aus diesen 5 Schritten bestehe, die aber nciht alle zwingend eintreten müssen.
    Idee dahinter: Das Login läuft immer primär über die $_SESSION variable. Sollte diese geschlossen werden (Fensterschließen), so holt sich die Session ihre Prüfwerte über den Login Cookie.
    Der Cookie enthält die gleichen Daten wie die $_SESSION bzw. es wird die $_SESSION als dessen Quelle genutzt.
    Existiert kein Cookie, so muss man sich wie gehabt von neuem anmelden.
    Noch Anregungen?

  • Hihi, der DW sagt: "Achtung! Das Thema ist möglicherweise veraltet, es liegt 546 Tage zurück!".


    Ich wollt' nur schnell "mein" Loginsystem (auch bis dato nur auf xampp) erläutern, bzw. eigentlich nur eine Frage klären:


    Wozu brauchst du ein Cookie, wenn die Daten manuell eingegeben werden?


    Ich hab' das im Prinzip so gemacht wie du, Schritt 1 ist aber:


    Seitenaufruf des Users ->


    Überprüfen, ob Cookie vorhanden ->
    Ja=Autologin (also Schritt 2 bei dir, die Anmeldedaten kommen aber dann vom Cookie)
    Nein=Loginfelder zeigen (name+pw)



    Der Rest ist glaub' ich klar. Bei einer erfolgreichen Anmeldung (oder einer Erstregistrierung) wird dann wieder ein Cookie erstellt, mit Name und md5.pw.
    Bei mir wird darüber hinaus in der Datenbank gespeichert, ob der User überhaupt ein Autologin möchte. (was vor schritt zwei kurz überprüft wird).


    Nun wollt ich generell mal hören, ob das eine "fatale" Lösung ist, denn im Cookie sind bei mir ja Name und PW gespeichert - ist das eine Möglichkeit für Hacker? (Das PW wird md5 verschlüsselt gespeichert, ein "Auslesen des PW" ist also nicht möglich.. Aber mit dem md5-Schlüssel kann man sich mglw. auch irgendwie (fremd-)anmelden?


    Grüße, IP

  • Cookie-Klau ist sicher möglich.
    Die MD*-Familie ist wie der Name schon sagt (Message Digist) eigentlich eine Kryptografie zur Nachrichtenübermittlung bzw. zur Erstellung von Prüfsummen (z. B. für Dateiübertragung).
    MD5 (und die anderen der Familie) gelten aber nicht mehr als sicher, es ist möglich das unterschiedliche "Plaintext" den gleichen Hashwert haben.
    Davon abgesehen, kann man u. U. auch mit Rainbowtables MD5 Verschlüsselungen brechen.


    Besser wäre es, mehrfache Verschlüsselungen zu verwenden (z. B. mehrfaches MD5 oder SHA2(MD5("Wert")) ) oder das zu verschlüsselnde zu salzen.
    Damit erschwert man Rainbowtables bzw. Brute-Force.

  • Ahoi Fürst Alcazar,besten Dank für die schnellen Infos!


    Ich werde wohl das PW auch doppelt verschlüsseln, für meine private Seite reicht mir das dann. Es hört sich für mich ein bißchen so an, als sei md5 schon recht sicher, und nur die Spitzen der Gilde kann da (mit Rainbowtables?) eventuell was auslesen. Also mach ich's doppelt, dann reicht mir das.


    Zu den Cookies würde mich jetzt (da ein Datenklau anscheinend möglich ist) noch interessieren, wer denn da rein rechtlich gesehen dann Schuld hat?
    Meine Internetseite legt auf deinem Rechner einen Cookie an, der von einem dritten ausgelesen wird. Bin ich dann für den unsicheren Cookie verantwortlich (als Seitenbetreiber), oder du als Besitzer deines Rechners?


    Danke schonmal (es sind übrigens beim Lesen deiner Antwort entstandene Fragen, ich kann sie auch erstmal selbst googeln.. Aber vielleicht weißt du es ja direkt..)


    Grüße, IP

  • Bin kein Anwalt, kann daher nichts zur Schuldfrage sagen.


    Was die Verwendung von Algorithmen angeht, es kommt immer drauf an, wie wertvoll das zu verschlüsselnde ist.
    Am sichersten wäre das One-Time-Pad, richtig angewendet ist das (solange der Schlüssel nicht bekannt ist) nicht zu brechen, auch nicht mit Brute-Force.

  • Wie seid ihr bloß auf dieses Thema gestoßen? :P
    Ich hatte mich damals beim basteln noch schlau gemacht und von verschiedenen Leuten beraten lassen.


    Beim erstellen des Cookies sollte es irgendwo einen Parameter geben, der den Zugriff auf diesen einschränkt. Dass man Daten nicht im Klartext speichern sollte ist hoffentlich auch klar. Am idealsten ist es wahrscheinlich, aus Username und Passwort eine neuen Code zu generieren, mit dem ein Login ebenfalls möglich ist. Gelangt der Cookie dann doch mal in falsche Hände so bleiben dem Eindringling die Anmeldedaten des Users verborgen. Ideal ist es in dieser Hinsicht übrigens, den Usern zu erlauben sich Alias zu geben, so dass der registrierte Benutzername unter Umständen auch gar nicht im Profil auftaucht.
    Interessant war übrigens noch der Punkt, dass ich in soweit irgendetwas verbockt hatte, als das mit dem Login von User B auch User A und User C aus der Session rausgeflogen sein müssten. Kurzum, ich hab ein weiter bearbeiten des Scriptes auf weiteres aufgegeben gehabt. :thumbsup:

  • Weltklasse, ick brauch den Thread echt alle 550 Tage, diesmal sagt er: "Obacht, die letzte Antwort liegt 560 Tage zurück!" xD, jedenfalls:


    Habe ich gerade eine kleine Datenbankverbindungsfrage, nämlich simpel MySQL, folgendes Konstrukt:



    auf einer index.php wird nichts weiter gemacht, als eine $main ausgegeben, die in der includeten skript.php je nach $_GET generiert wird. Beispielsweise sieht die Skript.php so aus:


    Ob btw. aus der Datenbank nur gelesen, oder auch geschrieben/ geupdatet wird, is' genauso egal, wie ein mögliches includen der funktionen etwa in einer funktionen.php o.Ä.. Meine Frage ist nämlich:


    Wo eröffne, bzw. schließe ich die Datenbankverbindung am besten (folgend orange)?
    Möglichkeit 1:


    Möglichkeit 2:


    1. Gibt es überhaupt eine klare Antwort? (und ich mach mich folgend also zum Affen? ;) )
    2. Vom Gefühl her gefällt mir die zweite Variante besser, da hier nur dann eine Verbindung hergestellt wird, wenn sie benötigt wird. Falls Funktionen aber hintereinander ausgeführt werden, muss jedesmal eine neue DB-Verbindung hergestellt werden, was längere Wartezeiten (und mehr Anfragen/Slots) verursacht. Oder lieber Variante eins mit nur einer Anfrage, allerdings auch bei der statischsten Seite?!


    Ich bin da generell für ein paar Gedanken dankbar; wer Ahnung hat sagt also einfach mal was dazu. :)
    Danke!, IP

  • Forum

    Hat das Thema geschlossen