Was ist fehlerhafte Authentifizierung? Beispiele und wie man sie verhindert

Was ist eine fehlerhafte Authentifizierung? Was macht ein sicheres Passwort aus? Wie kann eine schlechte Sitzungsverwaltung zu einer fehlerhaften Authentifizierung führen? Lesen Sie weiter, um es herauszufinden.

Die Zahl der Datenschutzverletzungen hat in den letzten Jahren zugenommen. Laut dem IBM-Bericht 2022 sind die weltweiten Kosten für Datenschutzverletzungen auf 4,35 Millionen Dollar gestiegen, während die USA mit durchschnittlichen Kosten von fast 9,5 Millionen Dollar den ersten Platz einnehmen. Hacker nutzen immer wieder alte Methoden und erfinden neue Techniken, um an sensible Verbraucherdaten zu gelangen.

Eine Möglichkeit, in ein bestimmtes System einzudringen, besteht darin, verschiedene Schwachstellen in der Authentifizierung auszuloten. Eine fehlerhafte Authentifizierung hängt oft von anderen Angriffen wie Social Engineering, Phishing, Man-in-the-Middle oder Cross-Site Scripting ab.

In diesem Artikel erläutern wir, welches Benutzerverhalten und welche Fehler von Entwicklern zu einer fehlerhaften Authentifizierung führen, und stellen wirksame Strategien vor, um dies zu verhindern.

Was ist fehlerhafte Authentifizierung?

Bevor wir uns mit der gebrochenen Authentifizierung befassen, sollten wir zunächst die Authentifizierung definieren. Im Wesentlichen bedeutet Authentifizierung die Überprüfung der Identität des Benutzers durch die Abfrage einiger privater Informationen, die nur diesem Benutzer bekannt sind, z. B. seine Benutzer-ID, seine E-Mail und sein Passwort oder ein Fingerabdruck-Scan.

Eine unvollständige Authentifizierung ist eine Schwachstelle im Web, die es Hackern ermöglicht, entweder die Authentifizierungskontrollen zu umgehen, die Identität einer Person zu stehlen, um sich anzumelden, oder andere Sicherheitsmechanismen zu umgehen. Eine unvollständige Authentifizierung kann sowohl durch eine nachlässige Verwaltung der Anmeldeinformationen als auch durch eine schlechte Sitzungsverwaltung verursacht werden.

Beispiele für schlechtes Credential Management

Die Verwendung fremder Anmeldedaten ist eine der häufigsten Möglichkeiten für böswillige Akteure, auf ein System zuzugreifen. Im Jahr 2022 waren gestohlene Zugangsdaten der primäre Angriffsvektor bei 19 % der Sicherheitsverletzungen in der IBM-Studie 2022. Und das ist nicht überraschend.

Zunächst einmal verwenden viele Menschen schwache Passwörter, und wir reden hier nicht von “123”, “admin”, Kosenamen und Geburtsdaten, auch wenn Millionen von Nutzern diese immer noch verwenden. Und wir übertreiben nicht – die folgenden Daten sprechen für sich.

Darüber hinaus zeigen Untersuchungen, dass 44 % der Verbraucher ihr Passwort nur alle Jubeljahre einmal ändern. Dies bedeutet, dass Hacker Brute-Force- und Passwort-Spraying-Angriffe starten und Anmeldedaten mit wenig Aufwand stehlen können.

Brute-Force-Angriffe sind automatisiert und beruhen auf einer einfachen Versuch-und-Irrtum-Methode. Passwort-Spraying ist eine Art von Brute-Force-Angriff. Anstatt jedoch zahlreiche Passwörter für ein einziges Konto auszuprobieren, wird das gleiche Passwort für mehrere Benutzer verwendet. Letzteres ermöglicht es Hackern, Kontosperren nach einer bestimmten Anzahl fehlgeschlagener Anmeldeversuche zu umgehen.

Eine andere Gruppe von Personen verwendet dieselbe E-Mail und dasselbe Passwort für alle ihre Konten. Laut Statista haben im Jahr 2021 nur 12 % der Nutzer bei der Registrierung neuer Konten immer neue Passwörter erstellt, während 45 % entweder immer oder meistens alte Passwörter wiederverwendet haben.

Dies führte zu “Credential-Stuffing”-Angriffen. Das Darknet ist randvoll mit geleakten E-Mails und Passwörtern verschiedener Organisationen. Da Menschen dieselben Passwörter für mehrere Anwendungen verwenden, können Angreifer die aus dem Darknet erhaltenen Anmeldeinformationen nutzen und sie für gezielte Websites ausprobieren. Credential Stuffing ist außerdem ein automatisierter Angriff, d. h. er ist für Hacker mit geringem Aufwand verbunden.

Aber nicht nur die Benutzer sind hier die Übeltäter, auch die Entwickler können Fehler machen. Beispielsweise können Passwörter im Klartext gespeichert werden oder schwache Hashes verwenden, was es Hackern leicht macht, sie mit Rainbow-Tables zu entschlüsseln.

Warum ist Sitzungsmanagement wichtig?

Die Sitzungsverwaltung ist ein wesentlicher Bestandteil moderner Webanwendungen. Eine Web-Sitzung ist eine Abfolge von HTTP-Anfragen und -Antworten im Netzwerk, die sich auf denselben Benutzer beziehen. Webanwendungen verwenden Sitzungen, um Informationen über einen bestimmten Benutzer zu speichern, damit sie auf alle seine Aktionen und Anfragen für die Dauer der Sitzung richtig reagieren können.

Wenn zum Beispiel ein Benutzer zum ersten Mal auf der Website navigiert, werden seine Spracheinstellungen während der gesamten Sitzung gespeichert, was die Benutzerfreundlichkeit verbessert.

Sitzungen sind auch in Szenarien nach der Authentifizierung nützlich. Sobald sich der Benutzer authentifiziert hat, kann die Webanwendung diesen Benutzer bei nachfolgenden Interaktionen identifizieren und entsprechende Sicherheitskontrollen anwenden.

Sobald eine Sitzung erstellt ist, wird dem Benutzer eine Sitzungs-ID oder ein Token zugewiesen, das vorübergehend der stärksten Authentifizierungsmethode entspricht und vom Benutzer und der Webanwendung während der Sitzung ausgetauscht wird.

Beispiele für fehlerhafte Authentifizierung und Sitzungsverwaltung

Eine korrekte Sitzungsimplementierung spielt eine enorme Rolle bei der Vermeidung von Authentifizierungsschwachstellen. Hier sind nur einige Beispiele dafür, wie unsachgemäße Sitzungsverwaltung zu fehlerhafter Authentifizierung führt.

Session Hijacking. Dies kann viele Formen annehmen. Das einfachste Beispiel für Session Hijacking ist, wenn ein Benutzer es versäumt, seine Sitzung auf einem öffentlichen Computer ungültig zu machen: Er schließt vielleicht nur das Browserfenster, ohne sich von den Anwendungen abzumelden. In diesem Fall kann sich die Person, die danach denselben Computer übernimmt, leicht als dieser Benutzer ausgeben, da die Sitzung noch aktiv ist und die Anwendungen nicht gesperrt sind.

Aber Hacker gehen nicht einfach an öffentliche Orte und versuchen ihr Glück. Die meisten ihrer Angriffe werden im Voraus geplant und aus der Ferne durchgeführt. Eine andere Möglichkeit, eine Sitzung zu kapern, besteht darin, den Netzwerkverkehr mit Paket-Sniffern wie Wireshark abzuhören. Wenn Webanwendungen TLS-Verschlüsselung nur auf Anmeldeseiten verwenden, können Hacker den Datenverkehr auf anderen Seiten überwachen und Sitzungscookies stehlen.

Bösewichte könnten auch versuchen, das Sitzungs-Token mit Cross-Site-Scripting (XSS) zu stehlen. Dabei wird ein Link mit einem speziellen Code erstellt, der beim Anklicken ausgeführt wird. Das Skript kann in JavaScript oder einer anderen clientseitigen Sprache geschrieben sein. Hier ist ein Beispiel für ein bösartiges Skript, das den Cookie-Wert in einem Pop-up-Fenster offenbart:

<SCRIPT>

alert(document.cookie);

</SCRIPT>

Sitzungsfixierung. Bei einem Angriff zur Sitzungsfixierung stellt der Hacker eine Verbindung zur Webanwendung her, um eine gültige Sitzungs-ID zu erhalten, und bringt dann einen legitimen Benutzer durch Social Engineering oder eine Phishing-Website dazu, sich mit dieser Sitzungs-ID zu authentifizieren. Wenn die App die Sitzungs-ID bei der Authentifizierung nicht erneuert, kann sich der Hacker als der Benutzer ausgeben und auf sein Konto zugreifen.

Hier ist ein Beispiel für einen bösartigen Link, der den Wert der Sitzungs-ID des Opfers in seinem Cookie ändert, wenn er angeklickt wird:

http://website.com/<script>document.cookie=”sessionid=abcd”;</script>

URL-Umschreibung der Sitzungs-ID. Wenn eine Webanwendung die Sitzungs-ID in die URL einfügt, anstatt sie im Cookie zu speichern, wird sie offengelegt und ermöglicht es jedem, der der URL folgt, die Sitzung zu übernehmen. Wenn also eine solche URL versehentlich weitergegeben wird, kann ein anderer Benutzer die Sitzung übernehmen, ohne sich authentifizieren zu müssen.

Unternehmen, die von der fehlerhaften Authentifizierung betroffen sind

Schauen wir uns Beispiele aus der Praxis von Unternehmen an, bei denen es aufgrund einer falschen Verwaltung von Anmeldeinformationen oder anderer Schwachstellen bei der Authentifizierung zu Datenschutzverletzungen kam.

Revolut ist eine Geld-App, mit der man in über 200 Ländern Geld senden, Zahlungen anfordern und Rechnungen aufteilen kann. Im September 2022 kam es bei Revolut zu einer Datenpanne, bei der Namen, E-Mails, Telefonnummern, Postadressen, Gerätedaten, der Transaktionsverlauf und die letzten bekannten IP-Adressen von etwa 50.000 Nutzern offengelegt wurden.

Auch wenn die Debit- und Kreditkartendaten maskiert und unbrauchbar waren, können die gestohlenen Informationen für Identitätsdiebstahl und Phishing-Angriffe verwendet werden. Die Ermittler gehen davon aus, dass die Datenbank von einem Mitarbeiter kompromittiert wurde, der Opfer eines sorgfältig ausgearbeiteten Social-Engineering-Angriffs wurde und den Hackern die Anmeldedaten übergab.

Twilio ist eine Plattform zur Kundenbindung, die Kommunikations-APIs für SMS-, Sprach- und Videokanäle bereitstellt. Twilio wurde im August 2022 angegriffen; Hacker griffen auf die Daten von 125 Twilio-Kunden zu. Zu den sekundären Opfern der Sicherheitsverletzung gehörten große Namen wie Signal und Okta. Auch hier wurde der Angriff durchgeführt, indem Mitarbeiter dazu verleitet wurden, einer Phishing-URL per SMS zu folgen, um angeblich abgelaufene Passwörter zu aktualisieren oder Änderungen in der Terminplanung anzuzeigen.

Twitter, eines der größten sozialen Netzwerke der Welt, wurde 2022 ebenfalls gehackt. Die Aktualisierung des Codes im Juni 2021 führte zu folgender Schwachstelle: Wenn Hacker eine E-Mail oder Telefonnummer an das Twitter-System übermittelten, gab die Website das mit dieser Telefonnummer oder E-Mail verbundene Twitter-Konto preis. Infolgedessen wurden die persönlichen Daten von 200 Millionen Nutzern offengelegt, was in Zukunft zu Phishing-Betrug oder Identitätsdiebstahl führen kann.

Crypto.com ist eine Kryptowährungsbörse, die etwa 30 Mio. $ in Bitcoin und Ethereum verloren hat. Das Zwei-Faktor-Authentifizierungssystem erwies sich als so schwach, dass es von Hackern umgangen werden konnte. Den Hackern gelang es, Gelder von 483 Kundenkonten abzuheben. Das Unternehmen beabsichtigt, die Zwei-Faktor-Authentifizierung durch eine Multifaktor-Authentifizierung zu ersetzen, um solche Vorfälle in Zukunft einzudämmen.

LastPass ist ein Passwort-Manager, mit dem Sie Passwörter und andere wichtige Dokumente speichern und weitergeben können. Er wurde zweimal angegriffen. Beim ersten Mal stahlen Hacker einen Teil des Quellcodes und einige geschützte technische Informationen über das Konto eines kompromittierten Entwicklers. Beim zweiten Mal stahlen sie die Passwort-Tresore der Kunden. Letztere sind zwar verschlüsselt, aber Hacker können die Master-Passwörter, mit denen die Tresore gesperrt sind, mit roher Gewalt knacken.

Wie man eine fehlerhafte Authentifizierung verhindert

Der beste Weg, um eine fehlerhafte Authentifizierung zu verhindern, ist die Implementierung eines mehrschichtigen Sicherheitsansatzes. Lassen Sie uns die wichtigsten Punkte besprechen, die Ihnen dabei helfen werden, dies zu erreichen.

Multi-Faktor-Authentifizierung hinzufügen

Bei der Multi-Faktor-Authentifizierung (MFA) handelt es sich um eine zusätzliche Sicherheitsebene, bei der der Nutzer einen weiteren Beweis vorlegen muss, um sich anzumelden. Dabei kann es sich um eine PIN, einen an Ihr Telefon oder Ihre E-Mail gesendeten Code, einen Fingerabdruck, einen Gesichts- oder Iris-Scan oder ein zeitbasiertes Einmalpasswort (TOTP) aus einer entsprechenden Authentifizierungs-App handeln.

Microsoft ist der Ansicht, dass die Einführung von MFA 99,9 % der automatisierten Angriffe auf Passwörter verhindert hätte. MFA hat jedoch mehrere Nachteile: Es verringert die Benutzerfreundlichkeit, fügt dem System externe Abhängigkeiten hinzu und bietet keine einfache Möglichkeit, es zurückzusetzen, ohne seinen Zweck zu vereiteln.

Als Ausweg kann MFA nur für Administratoren und Benutzer mit hohen Rechten oder nur für Transaktionen mit hohen Auswirkungen implementiert werden. Die Form, in der MFA implementiert werden muss, hängt von Faktoren wie dem Bedrohungsmodell der App, dem technischen Verständnis der Benutzer, dem Umfang der administrativen Kontrolle über die Benutzer und den Gemeinkosten ab.

CAPTCHA hinzufügen

CAPTCHA ist die Abkürzung für den Completely Automated Public Turing Test to Tell Computers and Humans Apart. Für den Laien ist es eine schnelle Prüfung, um Menschen von Bots zu unterscheiden.

Bei den ursprünglichen CAPTCHAs musste der Benutzer die verzerrten und überlappenden Zeichen und Zahlen erraten und in das Eingabefeld eingeben. Da Bots bei der Mustererkennung immer schlauer werden, entstand die Notwendigkeit für kompliziertere bildbasierte Tests.

CAPTCHAs erhöhen definitiv die Reibung in der Benutzerführung, daher ist es sinnvoll, sie erst nach einigen fehlgeschlagenen Anmeldeversuchen zu verwenden.

CAPTCHA macht Brute-Force-Angriffe zwar unbequemer und kostspieliger, kann aber keinen 100-prozentigen Schutz vor ihnen bieten.

Passwörter sicher speichern

Wahrscheinlich hat jeder schon einmal gehört, dass Kennwörter niemals im Klartext gespeichert werden sollten, weil Datenbanken ständig kompromittiert werden. Selbst wenn also ein Hacker die Datenbank in die Hände bekommt, bleibt ihr Inhalt verschlüsselt.

Die Entwickler können dies mit modernen Hashing-Algorithmen erreichen. Im Gegensatz zur Verschlüsselung ist das Hashing eine Einwegfunktion, d. h. es kann nicht entschlüsselt werden.

Gleichzeitig gibt es immer noch Umgehungsmöglichkeiten, wie z. B. die Berechnung von Hashes für häufig verwendete Kennwörter und den anschließenden Vergleich mit den Hashes aus der angegriffenen Datenbank. Um Hackern die Arbeit zu erschweren, sollten Passwort-Hashes gesalzen werden, d. h. den Hashes wird eine zufällig generierte, für jeden Benutzer einzigartige Zeichenfolge hinzugefügt.

Gesalzene Passwort-Hashes benötigen wesentlich mehr Zeit zum Knacken und machen es unmöglich, festzustellen, ob zwei Benutzer das gleiche Passwort haben, da unterschiedliche Salze zu unterschiedlichen Hashes führen, unabhängig davon, ob die Passwörter der Benutzer identisch sind.

Durchsetzung strenger Passwortrichtlinien

Was gilt als sicheres Passwort? Nach Angaben des National Institute of Standards and Technology sollten Passwörter mindestens 8 Zeichen lang sein und keine sich wiederholenden oder aufeinanderfolgenden Zeichen enthalten (wie aaaa oder abc123). Außerdem müssen die Benutzer die Möglichkeit haben, aus allen Zeichen zu wählen, einschließlich Unicode und Leerzeichen.

Das ist jedoch die niedrigste Schwelle, und Sie wollen in puncto Sicherheit nicht ganz unten ankommen. Der OWASP Application Security Verification Standard schreibt vor, dass Kennwörter mindestens 12 Zeichen lang sein müssen, während Entwickler von Kennwortstärke-Messgeräten wie Bitwarden 14 bis 16 Zeichen empfehlen.

Im Allgemeinen gilt: Je länger das Kennwort, desto besser, da es die Anzahl der Kombinationen erhöht, die ein Botnet knacken muss. Denken Sie aber daran, dass die Zeichen nach dem Zufallsprinzip generiert werden müssen.

Einige Websites beschränken die Anzahl der Zeichen, die Sie verwenden können. Eine weitere Möglichkeit, Ihr Passwort komplexer zu gestalten, ist die Verwendung von Großbuchstaben, Sonderzeichen und Zahlen. Auch hier ist die Zufälligkeit ein Schlüsselfaktor, wenn Sie diese hinzufügen. Ein Beispiel: “Logmein!321” ist ein schreckliches Passwortmuster, während “l_w4XgH9~Wiq” das ist, was wir erreichen wollen.

Das Anmeldeformular sollte über einen eingebauten Kennwortstärkemesser verfügen, der die Kennwörter mit Wörterbuchwörtern, bereits geknackten Kennwörtern oder kontextspezifischen Wörtern wie dem Dienst- oder Benutzernamen und deren Ableitungen vergleicht.

Bei der Einführung von Richtlinien für das Ablaufdatum von Passwörtern ist zu bedenken, dass Mitarbeiter in der Regel nur ein Zeichen ändern, um es hinter sich zu bringen und mit ihren täglichen Aufgaben fortzufahren. Daher ist es wichtig, die Mitarbeiter darüber aufzuklären, was ein sicheres Kennwort ausmacht, und die Änderung des Kennworts nur dann zu verlangen, wenn der Verdacht besteht, dass es tatsächlich zu einer Kompromittierung gekommen ist. Da Hacker nicht auf offengelegten Anmeldedaten sitzen bleiben, handeln sie sofort.

Sich starke Passwörter für zahlreiche Dienste auszudenken und sie sicher zu speichern, ist definitiv eine zusätzliche Belastung für die Mitarbeiter. Unternehmen müssen daher eine anerkannte Methode für die Erstellung und Speicherung von Unternehmenspasswörtern bereitstellen, sei es ein physischer Speicher, eine Passwortverwaltungssoftware oder eine Kombination aus beidem, und das Vorgehen der Mitarbeiter in verschiedenen Szenarien klar definieren.

Andernfalls werden die Mitarbeiter weiterhin schwache, leicht zu merkende Passwörter verwenden und bei der Speicherung improvisieren, indem sie Passwörter auf persönlichen Telefonen oder in Gmail-Entwürfen speichern.

Um lange Passwort-Denial-of-Service-Angriffe zu verhindern, sollte die maximale Passwortlänge festgelegt werden, die in der Regel 64 Zeichen beträgt.

Schwellenwert für Kontosperrung verbessern

Eine Kontosperrung ist ein zweischneidiges Schwert. Einerseits ist sie einer der gängigsten und wirksamsten Schutzmaßnahmen gegen Brute-Force-Angriffe, da das Konto nach einer bestimmten Anzahl von Fehlversuchen einfach gesperrt wird.

Andererseits können Kontosperrungen leicht zu einer Denial-of-Service-Situation führen. Hacker können automatisierte Angriffe gegen alle Benutzer in einem Unternehmen starten, die zu massiven Kontosperrungen führen und die Kundendienstteams mit Anrufen von Benutzern überfluten. Die Kosten für Ausfallzeiten und Reputationsrisiken wären immens.

Ein anderes Szenario ist, dass ein Benutzer in Eile oder Aufregung seine E-Mail oder sein Passwort ein paar Mal falsch geschrieben hat. Wenn der Schwellenwert für die Kontosperrung zu niedrig ist, kann dies eine versehentliche Sperrung auslösen.

Leider gibt es kein Patentrezept, das das Dilemma der Kontosperrung lösen würde. Es liegt in der Verantwortung jedes Unternehmens, einen goldenen Mittelweg zwischen Sicherheit und betrieblicher Effizienz zu finden. Bei der Festlegung des Schwellenwerts für die Kontosperrung ist es wichtig, zu berechnen, wie viele Versuche Angreifer pro Tag unternehmen können, und diese zu verlangsamen, indem der Schwellenwert für die Kontosperrung, die Dauer und die Rücksetzeinstellungen entsprechend angepasst werden.

Allgemeine Fehler anzeigen

Die Fehlerbehandlung ist ein weiterer Spielraum für böswillige Akteure, um Informationen zu sammeln und einzudringen. Wenn Fehlermeldungen sehr spezifisch sind, erleichtern sie dem Hacker die Arbeit, da er genau weiß, was schief gelaufen ist, welche Technologien und Framework-Versionen verwendet werden und er seinen Angriff entsprechend planen kann.

Wenn ein Bösewicht beispielsweise versucht, sich mit den Anmeldedaten einer anderen Person anzumelden, und die Meldung “Anmeldung fehlgeschlagen; Konto deaktiviert” sieht, wird er seine Zeit nicht verschwenden und zu einem anderen Konto wechseln. Oder schlimmer noch, der Name des Benutzers könnte in der Meldung selbst auftauchen, z. B. “Anmeldung für Benutzer Boo: ungültiges Passwort”.

Deshalb ist es besser, allgemeine Fehlermeldungen für die Registrierung, die Anmeldung eines bestehenden Benutzers und die Wiederherstellung des Passworts anzuzeigen.

Ein weiterer zu berücksichtigender Aspekt ist die Verarbeitungszeit. Sie sollte unabhängig vom Ergebnis gleich sein, damit der Hacker keinen zeitbasierten Angriff durchführen kann.

Bei der “Quick Exit”-Methode wird die App beispielsweise schnell einen Fehler ausgeben, wenn der Benutzer nicht existiert. Wenn der Benutzer jedoch existiert, aber das Passwort falsch ist, durchläuft die App mehr Schritte und braucht länger, um zu reagieren. So kann der Hacker anhand der Fehlerreaktionszeit zwischen einem falschen Benutzernamen und Passwort unterscheiden.

Außerdem muss sichergestellt werden, dass keine Informationen über die URL weitergegeben werden. Die Anwendung kann dem Benutzer eine allgemeine Meldung zurückgeben, aber einen anderen HTTP-Fehlercode, je nachdem, ob die Anmeldung erfolgreich war (200 OK) oder nicht (403 Forbidden).

Generische Meldungen erschweren Hackern zwar die Auskundschaftung, können aber die Verbraucher verwirren und sich negativ auf die Akzeptanz der App und die Benutzerbindung auswirken. Das Gleichgewicht zwischen Benutzerfreundlichkeit und Sicherheit sollte also jedes Unternehmen für sich selbst festlegen.

Keine Sicherheitsfragen mehr

Sicherheitsfragen werden nicht mehr als akzeptabler Authentifizierungsmechanismus angesehen. Es ist auch erwähnenswert, dass die Verwendung eines Passworts in Kombination mit einer Sicherheitsfrage nicht mit MFA gleichzusetzen ist, da der Faktor in beiden Fällen derselbe ist – etwas, das Sie wissen.

Es gibt zwei Arten von Sicherheitsfragen – benutzerdefinierte und systemdefinierte, und beide sind leicht zu knacken. Werfen wir einen Blick auf gängige benutzerdefinierte Sicherheitsfragen und warum sie schlecht sind:

Natürlich können Sie sich auch kompliziertere Fragen ausdenken, wie z. B. “Wie heißt das College, an dem Sie sich beworben haben, das Sie aber nicht besucht haben?” oder “Wie lautet der Nachname Ihres Mathelehrers in der 7. Aber sind Sie sicher, dass sich alle Nutzer diese Fragen sehr gut merken können? Eine Lösung besteht darin, eine Liste von Fragen zur Auswahl zu stellen, aber es gibt keine Garantie, dass die Antworten nicht vorhergesagt werden.

Im Jahr 2015 bestätigte eine Untersuchung von Google bestätigt, dass Sicherheitsfragen entweder sicher oder leicht zu merken sind, aber niemals beides. Während sich 40 % der Nutzer nicht an die Antworten auf ihre Sicherheitsfragen erinnern konnten, gaben 37 % absichtlich falsche Antworten, um sie schwerer zu erraten, erreichten aber genau das Gegenteil.

Systemdefinierte Fragen stützen sich auf die bereits im System gespeicherten Informationen wie Name, Geburtsdatum oder Adresse des Benutzers. Letztere können jedoch auch über soziale Medien oder Dark Web Dumps herausgefunden werden.

Aktualisieren Sie Ihre Frameworks

Die Implementierung eines Moduls zur sicheren Sitzungsverwaltung ist eine ziemliche Herausforderung, da es Authentifizierung, Benutzer-HTTP-Verkehr und von der Webanwendung erzwungene Zugriffskontrollen kombiniert. Deshalb wird empfohlen, integrierte Sitzungsmanagement-Funktionen und Implementierungsleitfäden bekannter Frameworks zu verwenden, anstatt sie selbst zu programmieren.

Gleichzeitig können auch weit verbreitete und gut getestete Frameworks Schwachstellen enthalten. Achten Sie also darauf, dass Sie die neuesten Versionen von Frameworks verwenden, in denen bekannte Sicherheitslücken behoben wurden. Ändern Sie außerdem die Standardkonfiguration, um die Sicherheit Ihrer Anwendung zu erhöhen.

Sichere Sitzungs-ID generieren

Der Name der Standardsitzungs-ID kann Aufschluss über die von der Webanwendung verwendeten Technologien und Programmiersprachen geben. PHPSESSID beispielsweise deutet auf PHP hin, JSESSIONID wird von J2EE generiert, während CFID & CFTOKEN darauf hinweisen, dass die Anwendung mit ColdFusion erstellt wurde. Daher sollte der Standardname in einen generischen und nicht sehr beschreibenden Namen geändert werden.

Die Länge der Sitzungs-ID ist wichtig. Wie bei Passwörtern sollte sie lang genug sein, um automatisierte Angriffe zu verhindern; OWASP empfiehlt mindestens 128 Bit; diese Zahl ist jedoch nicht starr und andere Implementierungsdetails sollten berücksichtigt werden.

Die Sitzungs-ID sollte auch eine effektive Entropie haben. Mit anderen Worten: Sie sollte zufällig und unvorhersehbar sein, um statistischen Analyseverfahren standzuhalten. Dies kann mit einem glaubwürdigen CSPRNG (Cryptographically Secure Pseudorandom Number Generator) erreicht werden.

Die Sitzungsobjekte und -eigenschaften wie die IP-Adresse des Benutzers, seine E-Mail, seine Zugriffsrechte oder seine letzte Anmeldung müssen auf dem Server in einer geschützten Sitzungsverwaltungsdatenbank oder einem Repository gespeichert werden.

Nicht zuletzt muss die Sitzungs-ID eindeutig sein, d. h. eine aktuelle Sitzung darf keine doppelten IDs enthalten.

Wählen Sie den richtigen Mechanismus für den Austausch von Sitzungs-IDs

Die Webanwendung und der Benutzer benötigen einen bestimmten Mechanismus, um die Sitzungs-ID gemeinsam zu nutzen und auszutauschen. Es gibt mehrere Möglichkeiten, dies zu tun – mit Cookies, URL-Parametern, URL-Argumenten bei GET-Anfragen oder Body-Argumenten bei POST-Anfragen.

Bei der Auswahl eines geeigneten Mechanismus für den Austausch von Sitzungs-IDs ist darauf zu achten, dass er die Definition erweiterter Token-Eigenschaften wie Ablaufdatum und -zeit des Tokens sowie granulare Nutzungsrichtlinien ermöglicht. HTTP-Cookies gehören zu den am weitesten verbreiteten Mechanismen für den Austausch von Sitzungs-IDs, da sie nicht nur diese Funktionen bieten.

URL-Parameter hingegen gelten als veralteter Mechanismus für den Austausch von Sitzungs-IDs, da sie die Sitzungs-ID in der URL offenlegen und Hackern die Möglichkeit geben können, Angriffe zur Sitzungsfixierung oder andere ID-Manipulationen durchzuführen.

Ein weiterer zu berücksichtigender Punkt ist, dass die App, auch wenn sie standardmäßig Cookies verwendet, unter bestimmten Bedingungen andere Austauschmechanismen akzeptieren oder von Cookies auf URL-Parameter umschalten kann. Daher sind strenge Tests erforderlich, um zu definieren, wie die App Sitzungs-IDs in verschiedenen Szenarien verarbeitet und verwaltet, und um sicherzustellen, dass sie sich ausschließlich auf Cookies stützt.

Implementierung von Kontrollen gegen Lauschangriffe

Sitzungskennungen können abgefangen oder gestohlen werden, indem der Netzwerkverkehr abgehört wird. Um dies zu verhindern, sollten Webanwendungen einen Transportschichtschutz implementieren.

Transport Layer Security (TLS) ist eines der modernsten Protokolle zur Verschlüsselung der Kommunikation zwischen einer Webanwendung und einem Server.

Natürlich sollten Webentwickler die neueste TLS-Version verwenden, da sie schneller und weniger anfällig ist als ihre Vorgänger; zum Zeitpunkt der Erstellung dieses Artikels ist dies TLS 1.3.

TLS sollte auf alle Seiten angewendet werden, unabhängig von ihrer Empfindlichkeit. Andernfalls bieten Sie einem böswilligen Akteur ein Schlupfloch, um Sitzungs-Token auszuspähen oder bösartigen JavaScript-Code einzuschleusen, um andere Angriffe auszuführen. Aus denselben Gründen sollte es keine Vermischung von TLS- und Nicht-TLS-Inhalten geben. Seiten, die über TLS verfügbar sind, dürfen keine JavaScript- oder CSS-Dateien enthalten, die über unsicheres HTTP geladen wurden.

TLS schützt zwar die Daten während der Übertragung, nicht aber die Daten, die das System erreicht haben, z. B. die im Cache des Browsers des Benutzers gespeicherten Daten.

Sitzungs-ID nach Änderung der Berechtigung erneuern

Es muss unbedingt sichergestellt werden, dass Ihre Webanwendung kein zuvor zugewiesenes Token verwendet, wenn sich die Berechtigungsstufe des Benutzers ändert. Wenn der Benutzer zum Beispiel von einem normalen Benutzer zu einem Administrator oder Superuser wechselt, sollte die Anwendung alte Sitzungs-IDs ignorieren und eine aktuelle generieren.

OWASP empfiehlt außerdem, eine andere Sitzungs-ID zu vergeben, wenn der Benutzer von einem anonymen zu einem authentifizierten Besucher wird. Letzteres hilft, das Risiko einer Bindung der Benutzersitzung zwischen den beiden Zuständen zu vermeiden. Die Erneuerung der Sitzungs-ID ist unerlässlich, um Angriffe zur Sitzungsfixierung zu verhindern.

Zeitüberschreitungen für den Sitzungsablauf festlegen

Zeitlimits für den Ablauf von Sitzungen sind insofern hilfreich, als sie die Zeit begrenzen, die ein böser Akteur hat, um die Sitzung zu kapern. Je kürzer also die Sitzungsdauer ist, desto besser. Aus diesem Grund bieten hochsensible Anwendungen nur 2-5 Minuten, bevor sich der Benutzer erneut authentifizieren muss.

Natürlich hängt das Ablaufintervall der Sitzung von der Art der Anwendung und den tatsächlichen Anwendungsfällen ab. Ein Büroangestellter benötigt 8 Stunden aktive Sitzungszeit, vorausgesetzt, alle seine Aufgaben stehen im Zusammenhang mit der Interaktion mit der App.

Es gibt verschiedene Arten von Zeitüberschreitungen, z. B. Leerlauf, absolute Zeitüberschreitungen und Verlängerungen. Leerlaufzeitüberschreitungen werden erzwungen, wenn nach einer bestimmten Zeit keine neue Aktivität stattfindet. Leerlaufzeitüberschreitungen sollen die Zeit verkürzen, in der ein Hacker eine gültige Sitzungs-ID erraten kann. Andererseits kann der Angreifer, wenn die Sitzung bereits gekapert wurde, in regelmäßigen Abständen eine Aktivität erzeugen, um die Sitzung zu verlängern.

Absolute Timeouts legen die maximale Zeit fest, die eine Sitzung aktiv sein kann, und schließen sie automatisch nach Ablauf. Bei Verlängerungszeitüberschreitungen wird in der Mitte der laufenden Sitzung unabhängig von der Benutzeraktivität eine neue Sitzungs-ID erzeugt, und die vorherige ID wird ungültig, sobald der Benutzer eine neue Anfrage sendet.

Sobald das Sitzungslimit erreicht ist, sollte die Webanwendung die Sitzung auf der Client- und Serverseite ungültig machen, damit der Angreifer keine Client-Parameter für die Zeitverfolgung manipulieren kann, wie z. B. die Anzahl der Minuten seit der Anmeldung.

Erkennen und Überwachen von Sitzungsanomalien

Webanwendungen sollten über integrierte Funktionen zur Erkennung von Anomalien verfügen, um Benutzer vor ungewöhnlichem Verhalten zu warnen oder verdächtige Sitzungen zu beenden. Hier sind Dinge, die auf ein mögliches Eindringen hindeuten:

• verschiedene Sitzungs-IDs von derselben IP-Adresse aus nacheinander ausprobiert werden
• ein bestehendes Cookie wird gelöscht oder geändert
• ein neues Cookie hinzugefügt wird
• die Sitzungs-ID eines anderen Benutzers wird wiederverwendet
• der Standort des Benutzers ändert sich mitten in einer Sitzung

Webanwendungen sollten Sitzungsinformationen während ihres gesamten Lebenszyklus protokollieren, von der Erstellung und Erneuerung bis zur Zerstörung der Sitzungsnummer. Ereignisse wie An- und Abmeldung, fehlgeschlagene Anmeldeversuche, gleichzeitige Anmeldungen, Änderungen von Berechtigungen und wichtige Transaktionen sollten ebenfalls protokolliert werden. Die Sitzungs-ID selbst muss als gesalzener Hash protokolliert werden.

Was die Client-Funktionen betrifft, so sollten die Benutzer in der Lage sein, Details über aktive Sitzungen, verbundene Geräte und IP-Adressen anzuzeigen. Sie sollten Benachrichtigungen über gleichzeitige Anmeldungen erhalten und die Möglichkeit haben, Sitzungen auf allen Geräten aus der Ferne zu beenden.

Passwortlos gehen

Wenn es so viele Probleme mit Passwörtern gibt, warum sollten sie dann überhaupt verwendet werden? Viele Unternehmen haben die passwortlose Authentifizierung bereits eingeführt oder beabsichtigen, sie einzuführen. Laut der Bitwarden-Umfrage aus dem Jahr 2022 glauben 41 % von 800 IT-Entscheidern, dass die passwortlose Authentifizierung die Sicherheit verbessert, während der Rest die Auswirkungen auf die Steigerung der Produktivität am Arbeitsplatz, eine bessere Benutzererfahrung und einen geringeren Helpdesk-Service feststellt.

Wenn Ihre Webanwendung mit einer Anwendung eines Drittanbieters verbunden ist, möchten Sie außerdem nicht, dass letztere die Anmeldedaten der Benutzer speichert, da dies das Risiko eines Einbruchs erhöht und Sie keine Kontrolle über die Sicherheit der Anwendung des Drittanbieters haben. Hier ist die Verwendung passwortloser Authentifizierungsprotokolle die einzige Option.

Hier sind einige der bekanntesten Authentifizierungsprotokolle, die kein Passwort erfordern.

• OAth 2.0 – ein Open-Source-Autorisierungs-Framework, das es einer Drittanbieter-Anwendung ermöglicht, begrenzten Zugriff auf einen HTTP-Dienst zu erhalten. Anstatt sich auf die Anmeldeinformationen des Benutzers zu verlassen, erhält die Drittanbieter-App ein spezielles Zugriffstoken. OAth 2.0 wird von großen Namen wie Meta, Google, Twitter und Microsoft verwendet.
• OpenID – eine quelloffene, dezentralisierte Technologie, die die Verwendung eines Kontos für den Zugriff auf mehrere Websites ermöglicht. Im Grunde teilen Sie Ihre Anmeldedaten mit einem einzigen Identitätsanbieter, dem Sie vertrauen, und melden sich dann mit diesem Identitätsanbieter an, ohne Ihre tatsächlichen Anmeldedaten preiszugeben. Über 50.000 Websites akzeptieren OpenID für die Anmeldung.
• SAML – Security Assertion Markup Language. Ähnlich wie OpenID ermöglicht SAML den Zugriff auf mehrere Webanwendungen mit einem Satz von Anmeldedaten. Der Unterschied besteht darin, dass es XML-basiert ist, mehr Flexibilität bietet und besser für Unternehmensumgebungen geeignet ist.
• FIDO – steht für Fast Identity Online. Die FIDO-Protokolle beruhen auf Verschlüsselungstechniken mit öffentlichen Schlüsseln. Bei der Registrierung auf einer Website erzeugt das Gerät des Benutzers ein Schlüsselpaar, wobei der private Schlüssel gespeichert und der öffentliche Schlüssel beim Online-Dienst registriert wird. Um sich zu authentifizieren, muss der Benutzer den Besitz des privaten Schlüssels nachweisen, indem er ihn lokal auf seinem Gerät durch Eingabe einer PIN, Sprechen in ein Mikrofon, Einsetzen eines Zweitfaktorgeräts, Wischen mit dem Finger usw. entsperrt.

In Penetrationstests investieren

Penetrationstests sind eine Art von Tests, bei denen ein Hackerangriff in einer kontrollierten Umgebung simuliert wird. Penetrationstester verwenden eine Kombination aus Sicherheitstools wie Schwachstellen-Scannern und manuellen Techniken, die von realen Angreifern eingesetzt werden. Daher sind Penetrationstests von grundlegender Bedeutung für die Verbesserung der Sicherheitslage eines Unternehmens.

Penetrationstests sind ein unverzichtbarer Bestandteil von Compliance-Vorschriften wie HIPAA, SOC 2 oder PCI-DSS, was ihre Wirksamkeit bei der Aufdeckung von Sicherheitslücken und deren rechtzeitiger Schließung bestätigt.

Wir von QAwerk helfen Startups und etablierten Unternehmen, ihre Authentifizierungsmodule gründlich zu testen, potenzielle Bedrohungen aufzudecken und effektive Wege zu finden, diese Schwachstellen zu beheben. Unsere Checkliste für Penetrationstests umfasst alle genannten Punkte und mehr, abhängig von den technischen Besonderheiten Ihres Produkts.

Neben einer dynamischen Analyse Ihrer Anwendung können wir auch den Quellcode vor einer größeren Veröffentlichung oder der Markteinführung eines neuen Produkts untersuchen, damit Sie Ihren Kunden unbesorgt neue Funktionen anbieten können. Wenn Sie mehr darüber erfahren möchten, wie wir Sie dabei unterstützen können, Ihre Software zukunftssicher gegen Hacker zu machen, und wie unser Penetrationstest-Prozess aussieht, senden Sie uns eine E-Mail. Wir bieten Ihnen kostenlose und unverbindliche Beratungsgespräche an, um herauszufinden, ob wir die richtige Wahl für Sie sind.

Resümee

Eine fehlerhafte Authentifizierung gehört zu den zehn größten Web-Schwachstellen, die von OWASP klassifiziert wurden. Auch wenn Identifizierungs- und Authentifizierungsfehler in den letzten Jahren dank standardisierter Frameworks zurückgegangen sind, stellen sie immer noch ein erhebliches Risiko dar und werden täglich von bösen Akteuren ausgenutzt.

Wenn Sie Ihre Anwendung an den besten Sicherheitspraktiken für die Verwaltung von Anmeldeinformationen und Sitzungen ausrichten, Ihre Mitarbeiter über Social Engineering und Online-Hygiene aufklären und regelmäßige Sicherheitsprüfungen durch eine qualifizierte Partei durchführen, können Sie sich vor Datenschutzverletzungen und den damit verbundenen Folgen schützen.