- Richtlinien, die häufige Authentifizierung verlangen, führen ohne nennenswerten Effekt auf die Sicherheitsverbesserung nur zu Unannehmlichkeiten für Nutzer
- Durch den Anstieg moderner Bedrohungen wie MFA-Fatigue-Angriffen kann wiederholte Authentifizierung im Gegenteil sogar zu einer Schwachstelle werden
- Die Bildschirmsperrfunktion des Betriebssystems und Echtzeit-Updates von Zugriffsrichtlinien sind wirksamere Schutzmaßnahmen
- Zusätzliche Authentifizierung ist nur unmittelbar vor sensiblen Aktionen nötig; willkürlich kurze Login-Intervalle sind unnötig
- Moderne Zugriffskontrollmethoden setzen Richtlinien automatisch und schnell durch, ohne Nutzer zu behindern
Warum häufige Authentifizierung die Sicherheit nicht erhöht
Probleme durch wiederholte Authentifizierung
- Wenn Sitzungen während des Arbeitsflusses ablaufen und Passwort und MFA (Multi-Faktor-Authentifizierung) immer wieder eingegeben werden müssen, sinkt die Produktivität
- Anfangs reichte die erneute Eingabe des Passworts, doch mit dem zusätzlichen MFA-Schritt nahmen Zeitaufwand und Unzufriedenheit der Nutzer zu
- Je häufiger MFA-Anfragen auftreten, desto größer wird auch die Erfolgswahrscheinlichkeit von MFA-Fatigue-Angriffen (MFA fatigue attacks)
- Früher galten häufige Passwortwechsel oder kurze Session-Ablaufzeiten als wirksame Sicherheitsmaßnahme, doch in aktuellen Richtlinien werden sie eher als kontraproduktiv bewertet
- Sicherheit hängt nicht vom Login-Intervall ab, sondern davon, wie schnell Verwaltung von Zugriffsrechten und Richtlinienänderungen wirksam werden
Das Wesen der Authentifizierung
- Authentifizierung beweist in der Regel eines von zwei Dingen
- Nachweis des Gerätebesitzes: Windows Hello PIN, YubiKey, Smartcard usw. bestätigen, dass man das physische Gerät besitzt
- Nachweis der Identität: Passwort, Face ID, Touch ID usw. identifizieren, dass es sich um den betreffenden Nutzer handelt
- Die Hauptaufgabe eines Identity Provider (IdP) liegt im Identitätsnachweis
- Face ID, Touch ID, Windows Hello usw. sind integrierte Systeme, die Gerätebesitz und Identität gleichzeitig nachweisen und dadurch besonders sicher sind
- Administratoren setzen Session-Ablaufzeiten oft kurz, weil sie befürchten, dass Richtlinienänderungen nicht sofort wirksam werden
Reale Sicherheitsbedrohungen und die Rolle der Authentifizierung
- Die meisten Angreifer versuchen Angriffe per Remote-Phishing, wobei Passwörter sehr leicht gestohlen werden können
- Zum Schutz vor Remote-Angriffen ist die Nutzung von Zweitfaktoren (z. B. YubiKey) eine wichtige Verteidigungsmaßnahme
- Bei physischen Angriffen wie Verlust oder Diebstahl eines Geräts ist der Bildschirm in der Regel bereits gesperrt
- Je häufiger sich Nutzer anmelden müssen, desto mehr Gelegenheiten zum Diebstahl von Zugangsdaten entstehen für Angreifer, was sich negativ auf die Sicherheit auswirkt
Die Rolle von Betriebssystemen und Webdiensten
- Moderne Betriebssysteme schützen das System mit einer Bildschirmsperre automatisch, wenn Nutzer ihren Platz verlassen
- Statt Nutzer mit häufigerer zusätzlicher Authentifizierung zu belasten, ist die Durchsetzung einer automatischen Sperrrichtlinie sinnvoller
- Außer bei gemeinsam genutzten Computern sind kurze Web-Session-Ablaufzeiten kaum mehr als ein Relikt aus der Zeit der Internetcafés
- Außer bei sensiblen Diensten (z. B. Online-Banking) verschlechtern ungeeignete Session-Timeout-Richtlinien eher Sicherheit und Nutzbarkeit zugleich
Ein effizientes und nutzerfreundliches Sicherheitsmodell
- Sofortige Authentifizierung (on-demand authentication) unmittelbar vor sensiblen Aktionen ist ideal
- Der Check-Modus von Tailscale SSH, Slack Accessbot usw. bieten eine sofortige Nutzerbestätigung bei Bedarf
- In Kombination mit der erzwungenen Bildschirmsperre des Betriebssystems lässt sich ein Gleichgewicht zwischen Sicherheit und Komfort halten
- Kontinuierliche Überprüfung des Sicherheitszustands (device posture check) und Zugriffskontrolle in Echtzeit erfolgen automatisch, unabhängig vom Verhalten der Nutzer
- Beispiele:
- Wenn ein Gerät offline ist, verloren geht oder eine Sicherheitsprüfung nicht besteht, wird der Zugriff sofort entzogen
- Bei Rollenänderungen oder anderen Änderungen der Identität werden Zugriffsrichtlinien automatisch aktualisiert
- Im Vergleich dazu, Nutzer zu wiederholter Authentifizierung zu zwingen, ist Echtzeit-Automatisierung deutlich intelligenter und sicherer
Fazit
- Häufiges Einloggen erhöht die Sicherheit nicht wirksam und kann im Gegenteil zu Passwortwiederverwendung, Phishing und MFA-Fatigue führen
- Leise und automatisierte Sicherheitsmechanismen sind der beste Schutz
- Tailscale verfolgt adaptive, intelligente und praktisch hilfreiche Sicherheit
- Das System ist so gestaltet, dass Nutzer Login-Intervalle nicht selbst anpassen müssen und nur im nötigen Moment ein Mindestmaß an Authentifizierungsaufwand entsteht
- Die Echtzeit-Sicherheitsprüfungen von Tailscale lassen sich auch auf andere Apps ausweiten und schützen so sogar Legacy-Systeme sicher
Weiterführende Links
4 Kommentare
Wie auch in den HN-Kommentaren erwähnt wurde, bremsen Sicherheitsprüfungen und -vorschriften, die auf starren und veralteten Standards beruhen, angesichts einer sich schnell verändernden IT-Umgebung oft eher aus. Wahrscheinlich ist das für die Leute an der Front nichts Neues ... haha
Zahlreiche Dienste in Korea blenden die lästige Erinnerung ein, das Passwort alle 30 Tage zurückzusetzen.
Das ist wirklich sehr lästig, weil es über Jahre hinweg aufgrund von Pflichten zum Schutz personenbezogener Daten erzwungen wurde ... schnief
Hacker-News-Kommentare
Ich denke, dass erzwungene regelmäßige Passwortänderungen oder Ablaufregeln das größere Problem sind. Solche Richtlinien führen oft dazu, dass Menschen aus ihren Accounts ausgesperrt werden (z. B. wenn das Passwort im Urlaub abläuft). Danach muss man entweder persönlich zur IT gehen, stundenlang mit der IT telefonieren, um ein Zurücksetzen zu beantragen, oder über einen nicht gesperrten Kollegen Kontakt aufnehmen.
Viele (die meisten?) Unternehmen setzen solche Richtlinien immer noch ein, obwohl NIST inzwischen keine willkürlichen Passwortänderungen mehr empfiehlt.
NIST-Offizialdokument
Auch Microsoft empfiehlt Passwortablauf nicht mehr, weil er mehr schadet.
Microsoft-Offizialdokument
Trotzdem scheinen solche Empfehlungen in IT- oder Sicherheitsabteilungen nicht als ausreichend „autoritätsstark“ zu gelten, und außerdem gibt es immer noch Leitfäden, die solche Richtlinien empfehlen.
Wenn ich mich gelegentlich auf irgendeiner zufälligen Website anmelde und dann zwangsweise zum Zurücksetzen des Passworts aufgefordert werde, denke ich eher, dass der Account geleakt oder kompromittiert wurde, statt dass es an einem zeitbasierten Ablauf liegt.
Wenn der Betreiber weiß, dass bestimmte Accounts in einer Liste aus einem Datenleck enthalten sind, halte ich es für eine sinnvolle Reaktion, beim nächsten Login eine erzwungene Passwortänderung zu verlangen.
Als ich das einem Cybersecurity-Verantwortlichen sagte, bekam ich zu hören, dass der PCI-Standard regelmäßige Passwortänderungen verlange und es deshalb davon abhänge, welche Audits man wichtiger nimmt.
Früher haben mich solche Richtlinien so genervt, dass ich sie umgangen habe, indem ich einfach jedes Mal hinten einen Buchstaben von a bis z an mein Passwort gehängt habe.
Zum Glück kann ich in meiner jetzigen Firma seit drei Jahren dasselbe Passwort benutzen, und das ist angenehm.
Ich finde es unsinnig, dass Anbieter mich regelmäßig zum Passwortwechsel auffordern, obwohl mein Passwort gar nicht kompromittiert wurde.
Dass das immer noch wie ein offizieller Standard behandelt wird, ist absurd.
Am Ende verwenden alle meine Accounts nur noch das Muster 1234abcd@.
Wegen Apple-Produkten finde ich das wirklich unerquicklich.
Ich habe festgestellt, dass dieses Muster für alle Apple-Produkte gilt.
Wenn man auf dem Mac Touch ID eingerichtet hat, sich im App Store mit dem Apple-Account anmeldet und dann Apps installieren will, erscheint ständig ein Fenster zur Passworteingabe. Dabei müsste Touch ID doch zur Authentifizierung reichen, stattdessen wird jedes Mal das Passwort verlangt.
Das Gleiche gilt sogar bei kostenlosen Apps, und ich halte das für einen völlig unnötigen Schritt.
Dieses Muster tritt auf dem iPhone meines Ehepartners auch gelegentlich auf.
Besonders wenn man das Telefon zurücksetzt und neu einrichtet, wird man wiederholt aufgefordert, das Apple-Passwort erneut einzugeben.
Obwohl Touch ID die Situation bereits ausreichend absichert, läuft es immer wieder so ab, und das ist frustrierend.
Wenn man auf Apple-Dienste von einem Nicht-Apple-Gerät aus zugreift, ist es noch schlimmer.
Jedes Mal, wenn ich mich bei icloud.com anmelde, klicke ich auf „Diesem Gerät vertrauen“, und am nächsten Tag muss ich trotzdem wieder den gesamten 2FA-Ablauf mit Passwort plus Einmalcode durchlaufen.
Wenn Face ID bei einer Zahlung oder App-Installation fehlschlägt, wird nicht auf die PIN zurückgegriffen, sondern man muss unbedingt das komplette Apple-Account-Passwort eingeben, und gleichzeitig lässt sich nicht einmal die Passwortmanager-App öffnen.
Wenn einem das an der Kasse passiert, ist das wirklich unerquicklich.
Man sollte unbedingt prüfen, ob die Bestätigung von Käufen per Touch ID wirklich aktiviert ist.
(Dafür muss man zu Settings > Touch ID & Password gehen.)
Wenn das nicht aktiviert ist, kann es sein, dass ständig die Passworteingabe verlangt wird.
Nach einem Neustart ist meiner Erfahrung nach höchstens eine einmalige Authentifizierung nötig, danach lässt sich das meiste per Touch ID bestätigen.
Jedes Mal, wenn ich mein iPhone mit dem Mac verbinde, um zu synchronisieren, erscheint sowohl auf dem Mac als auch auf dem iPhone das Fenster „Diesem Gerät vertrauen?“. Und obwohl ich jedes Mal „Ja“ auswähle, wird beim nächsten Verbinden wieder gefragt.
Wenn für eine Aufgabe SUDO-Rechte nötig sind, finde ich eine erneute Authentifizierung ganz natürlich.
In solchen Fällen kann man verwandte Aufgaben bündeln, damit man sich nur einmal authentifizieren muss und die Zahl der erneuten Abfragen sinkt.
Mein Kind benutzt ein sehr altes iPad mit iOS 10.3, auf dem keine Passwortmanager-App mehr funktioniert, und der Browser ist ebenfalls noch eine 32-Bit-App, sodass moderne Websites gar nicht mehr richtig laden.
Deshalb muss ich jedes Mal bei der Nutzung des App Store ein über 50 Zeichen langes Passwort von Hand eingeben, was extrem lästig ist.
Ich finde, die Leute, die solche Artikel lesen sollten, sind die Auditoren, die Sicherheitsprüfungen durchführen.
Solange sich deren Erwartungshaltung nicht ändert, werden viele Unternehmen weiterhin dumme Richtlinien befolgen müssen, weil sie als Industriestandard gelten.
Gerade kleine Unternehmen in bestimmten Branchen müssen in Sicherheitsaudits ebenfalls hohe Bewertungen erreichen und übernehmen deshalb massenhaft nutzlose Sicherheitsverfahren.
Bei uns werden mindestens sechs Sicherheitsmaßnahmen erzwungen, von denen wir wissen, dass sie in der Praxis nichts bringen, und die Auditoren wollen daran bislang kaum etwas ändern.
Bei SOC2-Audits habe ich immer wieder konsequent die NIST-Richtlinien vorgelegt.
Wenn man den Link zeigt, akzeptieren die meisten am Ende doch den NIST-Standard.
Sowohl Apple als auch Microsoft unterstützen Unternehmensrichtlinien, mit denen Sicherheitsteams Optionen wie „Mein Gerät merken“ oder „Diesem Gerät vertrauen“ deaktivieren können.
Für Auditoren oder CISOs zählt nur die Checkliste. Ob die Sicherheit dadurch tatsächlich steigt, ist völlig egal; wichtiger ist, das Audit zu bestehen.
Solche Einstellungen verschlechtern nur die Nutzbarkeit und schwächen in der Realität sogar die tatsächliche Sicherheit.
Ich finde, Microsoft hat auf diese Weise auch PC-Gaming ruiniert.
Wenn ich Spiele wie Minecraft oder die Master Chief Collection starte, weiß ich schon, dass wieder aus dem Nichts ein Re-Auth-Fenster auftauchen wird, und schiebe es deshalb vor mir her.
Wegen solcher Unannehmlichkeiten habe ich sogar 2FA für den Account deaktiviert.
Es ist doch nur ein Spiel und keine Bankkonto-Authentifizierung; ich will einfach nur in Ruhe spielen können.
Angeblich gibt es inzwischen eine Funktion, bei der man zur Authentifizierung einen QR-Code scannt, aber ich habe das Gefühl, dass die Leute, die so ein System bauen, völlig vom realen Nutzungserlebnis entkoppelt sind.
Im Artikel wird ein Punkt kaum erwähnt.
Schlechte UX kann selbst eine Sicherheitslücke sein.
Wenn sich ein System im Alltag irrational verhält, ist die Wahrscheinlichkeit hoch, dass Nutzer echte Veränderungen oder Auffälligkeiten nicht mehr bemerken, wenn tatsächlich ein Problem auftritt.
Wenn zum Beispiel ständig die Passworteingabe verlangt wird, tippt man es irgendwann aus Gewohnheit ein und kann Risiken wie Phishing nicht mehr so leicht herausfiltern.
Und wenn das OS fragwürdige Startup-Programme oder im Hintergrund laufenden verdächtigen Code nicht sauber verwaltet, lässt sich das ebenfalls leicht ausnutzen.
Ein weiteres Problem ist, dass gewöhnliche Sicherheitsexperten die „menschliche Psychologie“ kaum als wichtigen Faktor berücksichtigen und alles eher auf Checklisten oder aus Unternehmenssicht entwerfen.
Das sind Fehler, die sich durch gutes Produktdesign verhindern ließen, aber Anbieter von Produkten und Diensten reagieren auf regulatorische Änderungen sehr viel aktiver als Verbraucher, weshalb Verbesserungen nur schleppend stattfinden.
Deshalb denke ich tatsächlich, dass stärkere Regulierung der Sicherheitsleistung helfen kann, auch wenn sich dadurch die merkwürdige Situation ergibt, dass Unternehmen strengere Regulierung für ihre eigenen Produkte und Dienste natürlich nicht begrüßen.
Systeme, die häufig eine erneute Authentifizierung verlangen, verbessern die Sicherheit praktisch nicht wirklich (allenfalls mit sehr langen Ablaufintervallen gibt es eine kleine Ausnahme).
Bei einem guten Authentifizierungssystem ist entscheidend, dass man Berechtigungen sofort über Session-Ablauf oder explizites Session-Management entziehen kann.
In der Praxis ist die „Verzögerung“ zwischen dem Widerruf einer Session-Berechtigung und dem Zeitpunkt, an dem diese Session tatsächlich vollständig abläuft und alle Zugriffsrechte verliert, viel wichtiger als das Re-Auth-Intervall.
Je komplexer die Architektur des Authentifizierungssystems und je mehr beteiligte Systeme es gibt, desto komplizierter wird das.
Genau dafür braucht man Refresh-Token.
Der eigentliche Token läuft zwar regelmäßig ab, aber der Client bekommt separat die Möglichkeit, einen neuen Token zu erneuern.
Der Entzug des Tokens wird dadurch gesteuert, dass die Erstellung neuer Token blockiert wird.
Ich sehe das ähnlich.
In unserer Firma verwenden wir ein zweistufiges Authentifizierungsmodell.
Ein- oder zweimal am Tag melde ich mich per ADFS + MFA bei keycloak an, und die meisten Systeme nutzen keycloak als OIDC provider und erneuern ihre Token alle 10 bis 15 Minuten.
Dadurch muss man den umständlichen Authentifizierungsvorgang in der Regel nur einmal am Tag durchlaufen, und bei Bedarf kann der Zugriff auf per VPN verbundene Dienste innerhalb von 15 Minuten vollständig gesperrt werden.
Der Vorteil ist, dass man diese Änderungen bei normaler Nutzung kaum bemerkt.
Es reicht, wenn nicht für eine erneute Authentifizierung gesorgt wird, sondern nur der bestehende Token regelmäßig erneuert wird.
Es ist sinnvoll, die Ablaufzeit der Authentifizierung (
auth) von der Ablaufzeit der Autorisierung (authorization) zu trennen.Wenn man Menschen häufig zu einer erneuten Authentifizierung zwingt, suchen sie eher nach Umgehungen.
Dann schreibt man Passwörter auf Papier, speichert sie in Google Docs, baut an einen Yubikey einen Arduino plus Servomotor, leitet SMS an E-Mail weiter oder schickt TOTP-Codes über Wechat — lauter solche „Workarounds“ entstehen dann.
Letztlich ist es ein Dilemma: Je härter unbequeme Authentifizierungsrichtlinien werden, desto eher suchen Nutzer nach unsichereren Umwegen, nur um ihren Computer wenigstens halbwegs frei benutzen zu können.
Im Artikel steht sinngemäß, dass man heutzutage auf den meisten OS mit Fingerabdruck- oder Gesichtserkennung entsperren könne und es daher keinen Grund mehr gebe, den Bildschirm beim Verlassen des Platzes nicht zu sperren. In der Realität gilt das für Workstations (Desktop-PCs) aber nur sehr eingeschränkt.
In 30 Jahren Vor-Ort-Support habe ich genau einen einzigen Desktop mit Fingerabdruckleser gesehen.
Kameras gibt es fast nie, und von den PCs an den fünf Standorten, die ich derzeit betreue, haben nicht einmal 2 % eine Kamera.
Gesichtserkennung ist außerdem ein zusätzlicher Faktor, den viele Nutzer als unangenehm empfinden.
Durch nicht einvernehmliche, heimliche Gesichtserkennung — Überwachungskameras, Schule/Firma/Polizei usw. — ist ohnehin bereits viel Misstrauen entstanden, und ich halte dieses Unbehagen für berechtigt.
Selbst wenn die Hardware mir gehört, sind Softwarefirmen in der Praxis so gebaut, dass sie meine Befugnisse ohne echte moralische Grenze überschreiten.
Deshalb halte ich Sicherheitsschlüssel für besser geeignet an Workstations.
Sicherheitsrichtlinien in der IT-Branche folgen oft der Denkweise „Niemand wird gefeuert, weil er IBM gekauft hat“ — alle machen einfach das, was die anderen auch machen.
Ob das System tatsächlich kaputt ist oder nicht, ist unwichtig; wichtiger ist, dass man „sich an das gehalten hat, was im Buch steht“.
Nur ist dieses Buch, also der Standard, ein äußerst schlechtes Werk von vor 30 Jahren.
Deshalb kostet es enorm viel Energie, einen Informationssicherheitsverantwortlichen davon zu überzeugen, dass Passwörter nicht alle drei Monate geändert werden müssen.
Bei einem Kundenunternehmen haben alle Systeme ein Session-Limit von 30 Minuten.
Ich mochte Jira ohnehin schon nicht, aber wenn ich mich jedes Mal erneut anmelden muss, nur um ein Ticket anzusehen, ist das extrem unerquicklich.
Am Ende lese ich dann einfach Hacker News, statt zu arbeiten.
Zum Glück speichern die meisten Dienste den Inhalt meiner Arbeit heute wenigstens im Cache.
SSO heißt zwar „SINGLE sign on“, aber in Wirklichkeit wird man endlos zu erneuter Authentifizierung aufgefordert.
Ich frage mich, warum ich hunderte Male am Tag SSO-Aufforderungen sehen muss.
Bei Mobiltelefonen kann man das wegen Verlust- oder Diebstahlrisiko noch nachvollziehen, aber bei Desktops kommt es immer noch oft vor, dass Leute sich an öffentlichen Rechnern (z. B. in Bibliotheken) nicht abmelden und den Platz verlassen; viele Nutzer sind sich dessen nicht bewusst.
So wie ich SSO verstanden habe, bedeutet es, dass man sich mit einer einzigen ID an mehreren Systemen anmeldet — nicht, dass man sich nur ein einziges Mal anmeldet.