it-swarm.com.de

Auswirkungen auf die Sicherheit, wenn dem Benutzer mitgeteilt wird, dass er sich aufgrund zu vieler IP-Versuche nicht anmelden kann

Beim Code Exchange-Stapelaustausch wurde mir als Antwort auf Code mitgeteilt, der den Benutzer informiert, wenn sein Anmeldeversuch aufgrund zu vieler Anmeldeversuche von einer IP fehlgeschlagen ist

"Absolut nicht dem Endbenutzer mitteilen, warum die Anmeldung fehlgeschlagen ist. Sie geben einem potenziellen Angreifer wichtige Informationen, um ihn beim Angriff auf Ihre Anwendung zu unterstützen. Hier geben Sie an ein Angreifer sehr genaue Informationen, um Ihre IP-Einschränkung zu umgehen. "

https://codereview.stackexchange.com/a/164608/93616

Übe ich schlechte Sicherheit? Sollte ich vage Begriffe wie "Zu viele Anmeldeversuche" oder "Sie konnten nicht angemeldet werden" erklären?

Update : Falls es Unklarheiten gibt, ist es der Logik und Meldung für zu viele Versuche derzeit egal, ob die Versuche erfolgreich waren oder nicht.

42
Goose

Sagen Sie dem Endbenutzer auf keinen Fall, warum die Anmeldung fehlgeschlagen ist. Sie geben einem potenziellen Angreifer wichtige Informationen, um ihn beim Angriff auf Ihre Anwendung zu unterstützen.

Auf der anderen Seite ist es eine potenzielle Usability-Katastrophe, einem Benutzer nicht mitzuteilen, warum seine Anmeldung fehlgeschlagen ist.

Wenn Sie nicht klären, ob die IP-Adresse des Benutzers gesperrt wurde oder der Benutzer stattdessen ein falsches Kennwort verwendet hat, kann dies zu Panik führen, da er den Eindruck hat, dass jemand auf sein Konto zugegriffen und das Kennwort geändert hat, um ihn zu sperren. Wenn meine Anmeldung mit einem vorab ausgefüllten Passwort fehlschlägt, denke ich zuerst an einen Einbruch und nicht an einen IP-Block.

Ein naiver IP-Blockierungsmechanismus kann auch unwirksam sein und zusätzliche Probleme verursachen. Es ist möglicherweise trivial zu umgehen für einen Angreifer mit ausreichenden Ressourcen und jemand, der eine IP-Adresse mit anderen Benutzern teilt, könnte das IP-Verbot missbrauchen, um andere auszusperren. Stattdessen ist ein CAPTCHA nach n fehlgeschlagenen Versuchen pro IP möglicherweise eine weichere Lösung und für Ihre Anwendung besser geeignet.

Siehe auch:

80
Arminius

Die Bereitstellung allgemeiner Nachrichten, die nicht erwähnt wurden, bietet einen Sicherheitsvorteil.

Alice versucht, ein Konto auf Bobs Server brutal zu erzwingen. Bei den ersten Versuchen erhält Alice die Meldung "Fehlgeschlagener Anmeldeversuch" zurück. Beim nächsten Versuch erhält sie "Zu viele Anmeldeversuche von dieser IP-Adresse". Sie ist sich jetzt bewusst, dass (a) alle Anmeldeinformationen, die sie bis zu diesem Zeitpunkt ausprobiert hat, ungültig waren und (b) sie etwas anderes tun muss, bevor sie weitere Versuche unternimmt.

Aber was ist, wenn Bob die Nachricht nicht ändert? Alice fährt mit der Brute Force fort und erhält bei jedem Versuch den generischen "Fehlgeschlagenen Anmeldeversuch", auch wenn die Anmeldeinformationen korrekt sind . Wenn sie zufällig die richtigen Anmeldeinformationen versucht, lehnt Bob den Versuch ab, da das IP-Limit überschritten wurde, aber Alice weiß nicht, dass dies der Grund ist, und muss ihn als falschen Versuch behandeln (es sei denn, sie hat einen anderen Art zu wissen, was über den Rahmen dieser Frage hinausgeht). Ihre einzige Möglichkeit besteht darin, mit der Suche fortzufahren, ohne zu wissen, ob sie die richtigen Anmeldeinformationen bereits gefunden und überschritten hat.

Beachten Sie, dass dieser Vorteil Sicherheit durch Dunkelheit ist, da Alice darauf angewiesen ist, dass sie Bobs IP-Blockierungsrichtlinie nicht kennt. Abhängig vom Setup sind diese Informationen möglicherweise trivial zu erhalten. Wenn Alice beispielsweise Zugriff auf ein anderes Konto im System hat (einfach, wenn es die Registrierung eines öffentlichen Kontos akzeptiert), kann sie mithilfe von Versuch und Irrtum feststellen, ob ein korrekter Versuch nach zu vielen falschen Versuchen schließlich abgelehnt wird.

Andere Antworten haben den Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit erklärt, daher werde ich das nicht wiederholen.

14
Jon Bentley

Ja, technisch gesehen geben Sie Informationen zurück, die von einem Angreifer zur Feinabstimmung eines Brute-Force-Botnetzes verwendet werden könnten. Außerdem bin ich mir nicht sicher, wie nützlich die Fehlermeldung "Zu viele Anmeldeversuche von dieser IP" für einen Standardbenutzer sein wird. Es sollte auch beachtet werden, dass jeder erfahrene Angreifer entweder einen sich ändernden Reaktionstyp oder einen Zeitunterschied bemerkt und wahrscheinlich sowieso herausfindet, was passiert.

Möglicherweise möchten Sie einen Dienst wie CloudFlare verwenden. Sie verfügen über eine skriptfähige API, die unter bestimmten Umständen eine Interstitial-Seite dynamisch einfügen oder eine WAF-Regel aktualisieren kann. Troy Hunt hat ein gutes Tutorial, in dem er dies für Windows Azure mithilfe von Azure-Funktionen ausführt.

13
Dan Landberg

In diesem Fall sind Sicherheit und Benutzerfreundlichkeit gegensätzliche Ziele. Die sicherste Implementierung würde zwar kein Feedback bieten, wäre aber auch am wenigsten benutzerfreundlich. Sie müssen entscheiden, wie anfällig Ihr System für das Erzwingen von Anmeldungen ist, welche anderen Abhilfemaßnahmen vorhanden sind und wie effektiv die spezifische Abschwächung ist, wenn sie gegen Unannehmlichkeiten für den Benutzer bewertet wird.

Wenn ich zum Beispiel ein Login für ein Consumer-Gerät entwerfe, würde ich es so benutzerfreundlich wie möglich gestalten, indem ich detailliertes Feedback habe und zusätzliche Abhilfemaßnahmen einführe, um dies zu kompensieren. Wenn ich eine HSM-Anmeldung entwerfen würde, würde ich kein Feedback und lästige geräteweite Zeitüberschreitungen anbieten.

5
Kirill Sinitski

Alles hängt davon ab, was Sie bauen. Wenn es sich um ein Blog oder eine andere schicke Website handelt, bei der es nicht wirklich wichtig ist, legitime Versuche abzulehnen, und bei der Sie der Robustheit der Anwendung nicht wirklich vertrauen, sollten Sie sie wirklich vor allem schützen, was ein Angriff sein könnte, und niemals sagen, warum Sie lehnen eine Anmeldung ab.

Wenn Sie eine professionelle Anwendung erstellen und professionelle Zugriffe erwarten, beschränken Sie die Zugriffe von einer einzelnen IP nicht, wenn Ihre Anwendung robust genug ist. Wenn Sie dies tun, informieren Sie den Benutzer unbedingt über den Grund und richten Sie eine einigermaßen reaktionsschnelle Hotline ein (höchstens 1 Arbeitstag, um eine Nachricht zu lesen und zu verstehen und bei Bedarf eine Korrekturmaßnahme einzuleiten ). Weil es für große Unternehmen üblich ist, einen einzigen ausgehenden Proxy für alle ihre HTTP- und HTTPS-Zugriffe einzurichten. Möglicherweise haben Sie Tausende von Mitarbeitern an verschiedenen Standorten in einem Land, die alle anscheinend dieselbe IP-Adresse verwenden. Eine weiße Liste, die unbegrenzte Verbindungen von bekannten Proxys zulässt, reicht aus, aber Sie müssen bereit sein, sie schnell zu ändern, wenn einer Ihrer Kunden sein Netzwerk weiterentwickelt und seine Proxy-Adresse ändert.

2
Serge Ballesta