Kurze Session-Ablaufzeiten helfen der Sicherheit nicht

• Webanwendungen lassen Sessions in der Regel nach einer festen Zeit oder nach einer Phase der Inaktivität ablaufen; aktuelle Sicherheitsempfehlungen raten dabei oft zu kurzen Session-Timeouts
• Viele populäre Webanwendungen wie Gmail oder GitHub folgen dieser Praxis jedoch nicht, was die Frage aufwirft, ob kurze Session-Timeouts die Sicherheit tatsächlich wirksam erhöhen
• Das betrachtete Bedrohungsmodell umfasst Angreifer, die sich unbefugt Zugang zu der aktiven Session eines Nutzers verschaffen, etwa durch das Stehlen von Session-Cookies, das Ausnutzen von Session-Fixation-Schwachstellen oder die Nutzung desselben Geräts wie das Opfer
• Als Szenarien, in denen kurze Session-Timeouts nützlich sein könnten, wird etwa ein Angreifer genannt, der in Protokollen oder auf einem gestohlenen Computer alte Session-Tokens findet; das ist jedoch eher ein Argument für Session-Ablaufzeiten im Allgemeinen und nicht speziell für kurze
• Das Problem gemeinsam genutzter öffentlicher Computer ist für die meisten Webanwendungen in der Praxis kaum relevant, und ein Angreifer mit Zugriff auf ein entsperrtes Gerät braucht keine aktive Session, sondern kann dies durch das Erstellen einer neuen Session umgehen
• Kurz gesagt können kurze Sessions sowohl für die Benutzererfahrung als auch für die Sicherheit Nachteile haben, und häufige erneute Authentifizierung kann Nutzer dazu bringen, weniger sichere Praktiken zu übernehmen
• Das Fazit lautet, dass Session-Tokens im Allgemeinen sicher sind und Angriffe, die sich durch kurze Session-Timeouts verhindern lassen, selten sind. Andere Maßnahmen wie Festplattenverschlüsselung und das Sperren des Computers können wirksameren Schutz bieten
• Große Unternehmen wie Facebook, Google, Amazon und GitHub verwenden Sessions ohne Ablauf und scheinen dieses Risiko daher für akzeptabel zu halten

[GN⁺]

Hacker-News-Kommentar

• In Banking- und Finanz-Apps sind kurze Session-Ablaufzeiten weit verbreitet; das ist angesichts einer sehr breiten Nutzerbasis, der Attraktivität für opportunistische Angreifer und der Nutzung in Stresssituationen oder ungewöhnlichen Umständen vertretbar.
• Wenn es keinen vertrauenswürdigen Backchannel gibt und ein Identity Provider einem Service das Ablaufen einer Session nicht mitteilen kann, werden kurze Session-Ablaufzeiten oft verwendet, um unzureichende Authentifizierungsstandards auszugleichen.
• Die Bedrohung durch die Nutzung von Anwendungen auf gemeinsam genutzten Geräten ist real, und besonders in Umgebungen, in denen Geräte etwa innerhalb der Familie geteilt werden, sollte das Session-Timeout anwendungsspezifisch sein.
• Einige Nutzer argumentieren, dass kurze Session-Ablaufzeiten als Sicherheitsmaßnahme auf Kosten der Benutzerfreundlichkeit eingesetzt werden, und verweisen dabei auf das Beispiel von Self-Checkout-Systemen.
• Gemeinsam genutzte Computer ohne Nutzertrennung existieren in der Realität und werden oft verwendet, um auf Webanwendungen mit sensiblen Informationen zuzugreifen.
• Der Artikel wird dafür kritisiert, unbegründete Annahmen zu treffen und kurze Sessions als Sicherheitskontrolle auf Basis einer imaginären Endnutzerumgebung auszuschließen.
• Einige Nutzer vermuten, dass Googles Entscheidung, keine kurzen Sessions zu verwenden, weniger aus Sicherheitsbedenken resultiert als aus dem Wunsch, mehr Nutzerdaten für Werbezwecke zu sammeln.
• Kurze Sessions können nutzerfeindlich und unbequem sein, besonders wenn sie Arbeitsabläufe unterbrechen und ohne Vorwarnung eine erneute Authentifizierung verlangen.
• Einige Nutzer bevorzugen längere Session-Timeouts und argumentieren, dass kurze Timeouts ineffektiv seien und nur dazu dienten, Checkbox-Tests von Auditoren und Pentestern zu erfüllen.
• Es gibt einen Unterschied zwischen weichen Session-Timeouts, die bei Nutzeraktivität zurückgesetzt werden, und harten Session-Timeouts, die eine Session nach einer festen Zeitspanne unabhängig von der Aktivität des Nutzers beenden.