Mario: "angemeldet bleiben" implementieren

Hallo,

bei verschiedenen Services besteht die Möglichkeit, angemeldet zu bleiben, wenn man sich nicht explizit abmeldet. Oft kann man dann den Service 14 Tage lang benutzen ohne sich neu anzumelden.

Nun die Frage: Wie funktioniert das technisch? Was wird im Cookie hinterlegt? User und Passwort? Verschlüsselt oder Plain? Gibt es mit Flash bedenken (indem man Flash Cookies bzw. Shared Objects benutzt)? Kennt jemand ein Beispiel?

Danke!

  1. Moin!

    Warum solltest Du irgendwelche sensiblen Daten im Cookie speichern? Wenn der Cookie gesetzt und gueltig ist, ist das Verifikation genug. Teil deinem Server mit, dass die Session 2 Wochen halten soll.

    --
    Ich bin dafuer verantwortlich was ich sage, nicht dafuer, was Du verstehst.
    1. Teil deinem Server mit, dass die Session 2 Wochen halten soll.

      Danke für die Antwort. Session 2 Wochen aufrecht erhalten ist generell kritisch. Sessions könnten groß sein, der Server muss diese verwalten. Auch könnte mal ein Neustart erforderlich sein. Für mich also keine Option.

      1. Sessions könnten groß sein, der Server muss diese verwalten.

        Von welcher "Größe" und welcher Anzahl reden wir hier?

        1. Von welcher "Größe" und welcher Anzahl reden wir hier?

          In dieser Applikation wahrscheinlich nichtmal allzu kritisch, allerdings generell ein fragwürdiger Ansatz. Ich glaube nicht, dass Ebay, Google, Yahoo etc. 2 Wochen lang die Session laufen lassen. Aber Danke für den Ansatz :)

          1. Ich glaube nicht, dass Ebay, Google, Yahoo etc. 2 Wochen lang die Session laufen lassen.

            Warum nicht? Amazon lässt monatelang eine Session laufen - das Cookie von Google hat gar eine Haltbarkeit von teilweise mehreren Jahrzehnten[sic!].

            1. Warum nicht? Amazon lässt monatelang eine Session laufen - das Cookie von Google hat gar eine Haltbarkeit von teilweise mehreren Jahrzehnten[sic!].

              Ablauf eines Cookies und einer Session sind aber verschiedene Dinge!?

              1. Ablauf eines Cookies und einer Session sind aber verschiedene Dinge!?

                Ansich ja - aber mittels Cookie stellst du die Zuordnung zu einer Session her - und ich bezweifle, dass Google oder Amazon derart lange Werte für die Cookie-Lebensdauer nutzen, wenn die Werte nicht irgendwo serverseitig hinterlegt sind.

                Amazon hält mein Cookie z.B. bis 2036 vor - darin findet sich nur eine absonderliche Buchstaben-und-Zahlenwurst aber sicher keine informationen darüber, welche Artikel mich interesseren könnten oder wie ich heiße.

            2. Hi!

              Ich glaube nicht, dass Ebay, Google, Yahoo etc. 2 Wochen lang die Session laufen lassen.
              Warum nicht? Amazon lässt monatelang eine Session laufen - das Cookie von Google hat gar eine Haltbarkeit von teilweise mehreren Jahrzehnten[sic!].

              Ob das was dahinter steckt eine Session ist oder nicht beziehungsweise ob man das so nennt oder nicht, ist egal. Im Grunde genommen geht es nur darum, den Client bei jedem Request wiederzuerkennen und ihm serverseitig vorgehaltenen Daten zuzuordnen. "Session" impliziert oftmals den PHP-Weg der Ablage von Daten in temporären Dateien. Stattdessen kann man die Daten ja auch in einer Datenbank für beliebig lange Zeit festhalten.

              Ich denke, man kann ruhig erst einmal die Art der serverseitigen Datenhaltung in den Hintergrund stellen (aber nicht ganz außer Acht lassen) und zunächst ein Konzept zur Wiedererkennung auszuarbeiten. Wenn man das so tut, kann man auch die Problematik Benutzerdaten versus (Session-)ID etwas entspannter sehen. Wie dort gesagt, ob Benutzerdaten (Name und Passwort) oder nur eine ID übertragen werden, beides ist für eine Entführung auf dem Übertragungsweg in etwa gleichermaßen betroffen. Je länger die ID gültig ist, desto weniger Unterschied ist zwischen gestohlenen Benutzerdaten und einer gestohlenen ID. Auch mit einer ID authentifiziert kann man entzogene/geänderte Rechte gleich zur Wirkung kommen lassen, wenn man die serverseitig zu einer ID festgehaltenene Daten erst einmal auf Benutzernamen und Passwort beschränkt, anhand dieser die Autorisierung ermittelt und erst dann den Zugriff auf weitere Daten gestattet.

              Lo!

              1. Ob das was dahinter steckt eine Session ist oder nicht beziehungsweise ob man das so nennt oder nicht, ist egal.

                Natürlich muss man zwischen "Session" und "Session" unterscheiden ;) im kontext dieses Threads gehe ich davon aus dass "angemeldet sein über einen langen Zeitraum" als "Session" betrachtet werden kann.

                "Session" impliziert oftmals den PHP-Weg der Ablage von Daten in temporären Dateien.

                "Session"

                Stattdessen kann man die Daten ja auch in einer Datenbank für beliebig lange Zeit festhalten.

                "Session" :)

                Je länger die ID gültig ist, desto weniger Unterschied ist zwischen gestohlenen Benutzerdaten und einer gestohlenen ID.

                Aus dem Grund ist die über 25 Jahre gültige "Session" bei Amazon dennoch bei einem Bestellvorgang mit einem erneuten Login verbunden - eingeloggt bleiben gibts da einfach nicht.

                1. Hi!

                  Aus dem Grund ist die über 25 Jahre gültige "Session" bei Amazon dennoch bei einem Bestellvorgang mit einem erneuten Login verbunden - eingeloggt bleiben gibts da einfach nicht.

                  Richtig. Es dient lediglich zur Erkennung um bestimmte Dinge anzuzeigen. Als Angreifer mit dieser ID, wuesste man dann was der User sich zuletzt angeschaut hat und was Amazon glaubt, wofuer er sich interessiert. Alle sensitiven Bereiche erfordern immer noch eine Anmeldung.

                  Dabei ist es ja voellig egal wie das realisiert ist. Eine normale Session kann lediglich enthalten, wann der letzte Seitenaufruf war. Abhaengig davon gilt der User noch als eingeloggt oder es wird eine neue Authentifizierung gefordert. Welche Gefahr sollte da von einer 3 Monate lebenden Session ausgehen?

                  --
                  Ich bin dafuer verantwortlich was ich sage, nicht dafuer, was Du verstehst.
                  1. Hi!

                    Welche Gefahr sollte da von einer 3 Monate lebenden Session ausgehen?

                    Alle, keine oder irgendwas dazwischen. Es kommt auf den Anwendungsfall an - also was in der Session für Daten enthalten sind und was man damit anstellen kann.

                    Lo!

      2. Hi!

        Teil deinem Server mit, dass die Session 2 Wochen halten soll.
        Danke für die Antwort. Session 2 Wochen aufrecht erhalten ist generell kritisch. Sessions könnten groß sein, der Server muss diese verwalten. Auch könnte mal ein Neustart erforderlich sein. Für mich also keine Option.

        Üblicherweise kommt man als Administrator auch schlecht an die Session-Daten ran. Wenn du einem Benutzer ein Recht entziehst und dieser aber durch eine gültige Session sein Recht gewährt bekommt, kann er noch solange das Recht miss-/gebrauchen, wie die Session gültig ist. Das will man ja nicht. Wenn das Recht weg ist, soll das sofort wirken. Allein eine Session zur Authentifikation und Autorisation zu verwenden, ist auch deshalb schon bedenklich. Bleibt also nur, die Anmeldedaten selbst zu speichern und bei jedem Request zu prüfen. Und ob der Client selbige im Cookie oder einer browsereigenen Passwort-Datenbank ablegt, ist mit vergleichbaren Risiko auf der Clientseite behaftet. (Selbst eine Session-ID macht das nicht besser, die lässt sich auch zur unberechtigten Authentifizierung verwenden.) Wenn das Argument lautet, die Anmeldedaten nicht ungesichert zu übertragen, wäre eine Session-ID genauso betroffen.

        Lo!

  2. Hi,

    Nun die Frage: Wie funktioniert das technisch? Was wird im Cookie hinterlegt?

    Google ist dein Freund.

    MfG
    Naps

    1. Google ist dein Freund.

      Ich lese nichts von PHP in diesem Thread, wo kommst du also darauf?

    2. Google ist dein Freund.

      Danke. Es handelt sich um eine Flash-Applikation, also kämen Shared Objects zum Einsatz. Ausserdem habe ich natürlich schon gegoogelt. Viele Foreneinträge sind zu finden, mit verschiedenen Lösungsansätzen, die mir nicht alle gefallen. Daher hier die Frage, was DIE Lösung ist (wie es z.B. Yahoo oder Google implementiert).

      Wird wohl darauf hinauslaufen, dass das PW verschlüsselt im Cookie gespeichert ist...

      1. Wird wohl darauf hinauslaufen, dass das PW verschlüsselt im Cookie gespeichert ist...

        Dass das sicherheitstechnisch eine Katastrophe ist, ist dir aber klar?

        1. Dass das sicherheitstechnisch eine Katastrophe ist, ist dir aber klar?

          Genau darum dieser Thread.

      2. Hi,

        Es handelt sich um eine Flash-Applikation, also kämen Shared Objects zum Einsatz.

        Daher hier die Frage, was DIE Lösung ist (wie es z.B. Yahoo oder Google implementiert).

        Die nutzen für sowas vermutlich kein Flash.

        MfG ChrisB

        --
        “Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]