Cookie based Login - Sicherheit

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Cookie based Login - Sicherheit

    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.

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

    Kommentar


    • #3
      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
      Gutes Tutorial | PHP Manual | MySql Manual | PHP FAQ | Apache | Suchfunktion für eigene Seiten

      [color=red]"An error does not become truth by reason of multiplied propagation, nor does truth become error because nobody sees it."[/color]
      Mohandas Karamchand Gandhi (Mahatma Gandhi) (Source)

      Kommentar


      • #4
        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.
        Die Regeln | rtfm | register_globals | strings | SQL-Injections | [COLOR=silver][[/COLOR][COLOR=royalblue]–[/COLOR][COLOR=silver]][/COLOR]

        Kommentar


        • #5
          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?
          ich glaube

          Kommentar


          • #6
            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;

            Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

            bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
            Wie man Fragen richtig stellt

            Kommentar


            • #7
              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
              Gutes Tutorial | PHP Manual | MySql Manual | PHP FAQ | Apache | Suchfunktion für eigene Seiten

              [color=red]"An error does not become truth by reason of multiplied propagation, nor does truth become error because nobody sees it."[/color]
              Mohandas Karamchand Gandhi (Mahatma Gandhi) (Source)

              Kommentar


              • #8
                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.
                ich glaube

                Kommentar


                • #9
                  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-Code:
                  <?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...

                  Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

                  bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
                  Wie man Fragen richtig stellt

                  Kommentar


                  • #10
                    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.
                    ich glaube

                    Kommentar


                    • #11
                      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 ^^;

                      Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

                      bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
                      Wie man Fragen richtig stellt

                      Kommentar


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

                        Kommentar


                        • #13
                          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.

                          Kommentar


                          • #14
                            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.

                            Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

                            bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
                            Wie man Fragen richtig stellt

                            Kommentar


                            • #15
                              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.

                              Kommentar

                              Lädt...
                              X