Frage:
Gründe für die zeitliche Begrenzung der Eingabe von Anmeldeinformationen?
BlueCompute
2017-06-19 17:15:54 UTC
view on stackexchange narkive permalink

Ein Dienst, den ich verwende, hat ein Zeitlimit (scheinbar ziemlich kurz - vielleicht 10 bis 20 Sekunden) für die Eingabe von Anmeldeinformationen auf der Anmeldeseite. Wenn Sie versuchen, sich nach diesem Zeitraum anzumelden, wird die folgende Meldung angezeigt: login error message

[Aus Sicherheitsgründen müssen Benutzer ihre Anmeldeinformationen innerhalb eines bestimmten Zeitraums eingeben. Dieser Zeitraum wurde überschritten. Wir möchten Sie bitten, sich erneut anzumelden.]

Die Seite wird dann aktualisiert und ich kann mich ohne Probleme anmelden.

Welche Sicherheitsbedenken versucht dieser Dienst möglicherweise zu lösen? Benötigen Sie die Anmeldung innerhalb eines bestimmten Zeitraums?

"Wir machen das aus ... Gründen ..."
Es ist eine dumme Entscheidung, so etwas zu implementieren, da es in vielen Situationen zu Verzögerungen im Datenverkehr aufgrund von Anbietern, schlechten Verbindungen, einer Deep Inspection-Firewall oder anderen Gründen kommen kann und die Anmeldung nicht funktioniert.
Nun, es schien mir eine seltsame Entscheidung zu sein, zumal ich sonst nirgends darauf gestoßen bin, aber ich bin daran interessiert, was sie dazu veranlasst haben könnte.
@Overmind Wenn Sie eine Latenz von 10-20 Sekunden haben, haben Sie andere Probleme
Sie erwarten eindeutig, dass Sie einen Passwort-Manager oder ein anderes Gerät verwenden, das den Benutzernamen und das Passwort automatisch ausfüllt, oder zwingen Sie sogar dazu.Personen 20 Sekunden Zeit zu geben, um Benutzername und Passwort einzugeben ** ist buchstäblich eine ADA-Verletzung **, da eine Person, die ein Hilfsmittel benötigt, keine Erfolgschance hat.
@Harper ADA-Überlegungen sind eine perfekte Metrik für Security UX und es ist eine Schande, dass Infosec-Profis dies nicht häufiger berücksichtigen.Danke, dass du das in den Vordergrund gerückt hast (ich hatte es nicht in Betracht gezogen!)
Mein Bankinstitut hat diese Sicherheitsmaßnahme ebenfalls.Der angegebene Zeitraum beträgt jedoch ungefähr 2 Minuten.Trotzdem hatte ich mich gefragt, welchen Nutzen dies bringen sollte.Noch unfreundlicher ist die Tatsache, dass sie Sie nur über den Ablauf der Frist informieren, nachdem Sie Ihre Anmeldeinformationen UND die 2-Faktor-Authentifizierung eingegeben haben.Für mich hat es nur mehrere Ebenen der Frustration hinzugefügt.
Beim Lesen der Antwort habe ich das Gefühl, dass das, was meine Bank tut, etwas anderes ist. Sollte ich ti vielleicht als separate Frage stellen?
Ich frage mich, ob es sich um ein falsch konfiguriertes CSRF-Token handelt, das unter normalen Bedingungen viel länger halten soll.
Fünf antworten:
Ivan
2017-06-19 20:29:36 UTC
view on stackexchange narkive permalink

Dies scheint eine Lösung zu sein, die auf die Verwaltung von Backend-Sitzungen ausgerichtet ist.

Ich spekuliere, dass anonyme Benutzer keine Sitzung initiieren, aber eine Sitzung wird instanziiert, sobald Sie auf die Anmeldeseite gelangen. Wenn Sie sich anmelden, wird dies in Ihrer Sitzung vermerkt und Sie können deren Website und Dienste nutzen. Wenn Sie sich nicht innerhalb einer bestimmten Zeit anmelden, beenden sie Ihre Sitzung.

Angesichts des Marktes, in dem sie tätig sind (Sicherheit), könnte ich sehen, dass sie über den Ressourcenverbrauch ein Ziel für DDoSing sind Dies wäre mehr eine Ressourcenverwaltungslösung als alles andere (verhindert, dass die Anzahl der offenen Sitzungen einen bestimmten Schwellenwert überschreitet).

Es handelt sich also um Sicherheit für die Infrastruktur und nicht um Sicherheit für Ihr Konto.

Wenn ja, frage ich mich, was sie davon abhält, die Sitzungserstellung zu verschieben, bis die Anmeldeinformationen überprüft wurden.
Eine bessere Lösung wäre, die Sitzung in den Cookies für anonyme Benutzer zu verschlüsseln, da diese keine Berechtigungen haben sollten, die Probleme verursachen, wenn sie doppelt oder inkonsistent sind.
@meriton Ich stimme zu, es macht auch für mich keinen Sinn, aber ich stelle nichts an Webentwicklern vorbei.Selbst wenn Sie dies auf diese Weise tun, wird ein Angriff zur Erschöpfung der Ressourcen nicht vollständig gemindert.
Wenn die Infrastruktur ausfällt, können Sie nicht auf Ihr Konto zugreifen. Dies ist Sicherheit für Sie.
@OrangeDog Aber wenn ihre Infrastruktur ausfällt, können Hacker auch nicht auf Ihr Konto zugreifen!
@meriton Good Practice schreibt außerdem vor, dass Sie nach erfolgreicher Authentifizierung eine neue Sitzung erstellen, um sich vor Angriffen durch Pinning-Sitzungen zu schützen (zwingen Sie das Opfer, an einer vom Angreifer bereitgestellten Sitzung teilzunehmen, z. B. durch Fälschen von Cookies, damit sich der Benutzer bei einer Sitzung authentifiziert, die der Angreifer entführen kanndie Verwendung dieser Cookies).
ISMSDEV
2017-06-19 20:38:31 UTC
view on stackexchange narkive permalink

Es kann sein, dass sie eine Art Bestätigungstoken für das Formular ausgestellt haben, das sie im Rahmen der Anmeldung an den Server zurücksenden. Nach Ablauf einer bestimmten Zeit tritt eine Zeitüberschreitung auf. Nicht zu sagen, ob es eine gute Lösung ist oder nicht, nur dass es der Grund sein kann.

OWASP hat diese Informationen: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Initial_Login_Timeout

John Wu
2017-06-20 05:16:05 UTC
view on stackexchange narkive permalink

Ja, das Anmeldezeitlimit ist eine Abschwächung gegen den folgenden Angriff, der als Sitzungsfixierungsangriff bezeichnet wird:

  1. Böswilliger Benutzer verfügt über ein eigenes PandaCloud-Konto eine Reihe gefälschter Dateien.

  2. Böswilliger Benutzer greift auf einen öffentlichen Computer zu, z in einer Bibliothek, Universität oder einem Café und meldet sich an.

  3. Malicious erstellt eine Kopie seiner Sitzungscookies.

  4. Böswilliger Benutzer navigiert zurück zur PandaCloud-Anmeldeseite, meldet sich jedoch nicht an.

  5. Die PandaCloud-Seite löscht beim Laden alle Cookies, um den Browser in einen sauberen Zustand zurückzusetzen

  6. Böswilliger Benutzer ersetzt seine Cookies im Cookie-Store des Browsers.

  7. Böswilliger Benutzer verlässt den Schreibtisch und geht in eine Ecke zu sehen.

  8. Naiver Benutzer kommt vorbei und meldet sich an. Das Skript zum Löschen vorhandener Cookies wurde bereits in Schritt 5 ausgeführt und nicht erneut ausgeführt. Daher werden die Cookies des böswilligen Benutzers an die PandaCloud gesendet.

  9. Naiver Benutzer glaubt, auf seine zuzugreifen eigenes Konto, greift jedoch tatsächlich auf das Konto des böswilligen Benutzers zu.

  10. Naiver Benutzer lädt vertrauliche Dateien hoch und meldet sich dann ab.

  11. Der böswillige Benutzer meldet sich an und lädt die vertraulichen Dateien herunter.

  12. ol>

    Der Zweck des Zeitlimits besteht darin, die zwischen den Schritten 5 und 8 auftretende Gefährdung zu verringern. Wenn sie kurz genug ist, Es ist mehr oder weniger unmöglich, diesen Angriff abzuwehren.

    Es gibt jedoch viel bessere Möglichkeiten, damit umzugehen, z. B. mehr als ein Cookie zu verwenden und einen Teil der Seite des Benutzerinformationsservers zu speichern. Möglicherweise waren diese anderen Methoden aufgrund anderer technischer Einschränkungen nicht durchführbar.

Wenn Sie abstimmen, geben Sie bitte einen Kommentar ab, der die Antwort verbessern könnte.
"Naiver Benutzer kommt vorbei und meldet sich an" - Der Server sollte auf die Anmeldung mit neuen Cookies antworten, die mit den Anmeldeinformationen der naiven Benutzer verknüpft sind.Das oder ich habe die Schritte falsch verstanden.Nein, ich habe nicht abgelehnt.
So könnte der Hacker beispielsweise ein Cookie mit dem Pfad "/" setzen, während der Server mit "/ MySite" ein Cookie setzt.Der Browser zeigt beide an.Der Server kann sie nicht von den Headern unterscheiden.Außerdem setzen einige Plattformen passiv ein Sitzungscookie, das vom Authentifizierungscookie getrennt ist.
Aha.Ich glaube, der naive Ansatz, dies zu beheben, besteht darin, kein Anmeldeformular vorzulegen, wenn der Browser gültige Cookies vorlegt.Das könnte aber auch umgangen werden: 3.5.Der Malicius-Benutzer entfernt die Cookies aus dem Browser.
Der Hauptpunkt für diesen Angriff ist also, dass der naive Benutzer eine Anmeldeseite verwenden muss, die der böswillige Benutzer offen gelassen hat.In diesem Fall gibt es viel einfachere und bessere Angriffe, die nicht durch das Zeitlimit verhindert werden können und nicht erfordern, dass der Server Cookies fragwürdig behandelt.Beispiel: Ein böswilliger Benutzer meldet sich an und zeigt einfach eine gefälschte Anmeldeseite an, die der naive Benutzer verwendet.(Kopieren Sie den HTML-Code des echten Logins und fügen Sie ihn ein. Fügen Sie eine Zeile JS hinzu, um den gefälschten Login auszublenden, wenn Sie die Eingabetaste drücken oder auf OK klicken. Dies dauert wahrscheinlich genauso lange wie das Ersetzen von Cookies.)
@Theraot In einer Variante wird davon ausgegangen, dass die Webanwendung keine neue Sitzung generiert, wenn der Client eine bereitstellt.In diesem Fall könnte der böswillige Benutzer die ihm bekannte Sitzungs-ID verwenden, um eine Sitzung abzurufen, in der der naive Benutzer angemeldet ist. Dies kann jedoch trivial serverseitig behoben werden (wie Sie sagten: "Der Server sollte auf die Anmeldung antworten."mit neuen Cookies ") und ist keine gute Entschuldigung für dieses Login-Timeout.
Obwohl ich nichts Spezielles gegen die Antwort habe, mag ich Schritt 8 wirklich nicht. Wenn Benutzeranmeldeinformationen als Teil der Anmeldung gesendet werden, sollte dies immer Vorrang vor vorhandenen Cookies haben.Und dann hängt der Rest der Schritte davon ab, dass der Benutzer nicht weiß, dass der Kontoname nicht übereinstimmt, die Kontoinformationen nicht übereinstimmen, das Kontothema möglicherweise nicht übereinstimmt und viele andere Dinge, die er nicht beachten mussdamit der Plan funktioniert.
@JohnWu, Dies ist ein äußerst kompliziertes Szenario, das einen unwahrscheinlichen Fehler seitens des Website-Entwicklers erfordert, gefolgt von extremer Ahnungslosigkeit seitens des Benutzers.Fast jeder Website-Entwickler verwendet stattdessen Schritt (8b): "Bestehende Sitzungscookies durch neue Sitzungscookies ersetzen".Es ist einfacher, kinderleichter und passt auf natürliche Weise dazu, wie Browser mit Cookies umgehen.Ihr Schritt (8) erfordert, dass der Website-Entwickler den normalen Prozess der Cookie-Verarbeitung absichtlich untergräbt.Ihr Schritt (9) erfordert, dass der Benutzer Fehler wie "Hey, wohin sind meine Dateien gegangen?" Vollständig ignoriert.
@Mark - Hey, ich habe weder den Angriff noch die [Schadensbegrenzung] erfunden (https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Initial_Login_Timeout).Ich möchte jedoch darauf hinweisen, dass das Löschen von Cookies oder der Versuch, sie zu überschreiben, nicht so narrensicher ist, wie Sie denken.
subdigit
2017-06-20 17:33:17 UTC
view on stackexchange narkive permalink

Angesichts der Informationen, auf die wir uns stützen müssen, mag ich viele der bereits gegebenen Spekulationen. Einige besser als andere. Lassen Sie mich angesichts all der Spekulationen, zu denen wir berechtigt zu sein scheinen, ein weiteres wirklich sehr scharfes Szenario einwerfen:

Schutz des leicht abgelenkten Benutzers

Benutzer gibt Anmeldeinformationen ein, muss aber noch auf die Schaltfläche "Senden" klicken. Wird abgelenkt, abgerufen und beschließt, aufgrund einer Social-Media-Benachrichtigung oder was auch immer eine andere Seite zu durchsuchen. Im Grunde haben sie alle ihre Anmeldeinformationen ausgefüllt, aber nicht eingereicht.

Dann verlassen sie ihre Maschine: öffentliche Maschine, Bibliothek, Laptop in einem Café während einer Badezimmerpause (hey, ich habe gesehen, wie Leute ihre verlassen haben Autos, die laufen, während sie in einen Supermarkt gehen ... es kann passieren!)

Der potenzielle Angreifer kann Zugriff auf die Maschine erhalten und das Formular senden, aber mit der kurzen Zeitüberschreitung ist seine Sitzung abgelaufen. Anstatt zu senden, gibt es wahrscheinlich interessantere Möglichkeiten, ein Passwort aus einem ****** -Feld wiederherzustellen, damit es dann ordnungsgemäß für den Zugriff wiederverwendet werden kann. Dies ist jedoch ein anderes Sicherheitsproblem.

Es ist erwähnenswert, dass der Server sie abmelden kann, wenn sich der Benutzer anmeldet und seine Sitzung unbeaufsichtigt lässt.Wenn der Benutzer seine Anmeldeinformationen verlässt, werden diese praktisch unbegrenzt und auf viel besser lesbare Weise angezeigt.
wahr!Dies ist immer eine gute Vorgehensweise für Websites mit vertraulichen Informationen.In diesem Fall ging es speziell darum, die Anmeldeseite zu überschreiten, noch bevor sich der Benutzer anmeldet, was wie ein Overkill erscheint, aber ich denke, es kann seine Verwendung haben.
Michael
2017-06-19 17:23:10 UTC
view on stackexchange narkive permalink

Folgendes kann ein Grund sein:

1) Sie geben Benutzernamen und Anmeldeinformationen an und veranlassen Sie, den Computer zu verlassen, bevor Sie auf die Schaltfläche "Senden" klicken.

2) An Der Angreifer greift auf Ihren Computer zu und drückt auf die Schaltfläche "Senden". Schließlich kann der Angreifer Ihre Anwendungen verwenden.

Beispielsweise beschränkt der Keycloak OpenIDConnect-Anbieter die Anmeldezeit.

Wie unterscheidet sich dies vom Verlassen des Computers, sobald Sie angemeldet sind?Wie erhöht der Timer den Wert des Anmeldebildschirms?
Ich habe ähnliche Implementierungen auf Webseiten gesehen, die von internen Mitarbeitern (z. B. einem Reisebüro) verwendet werden. Der Grund für die Implementierung war, die beschriebene Situation zu beenden, in der der Benutzername und das Kennwort eingegeben wurden, der Benutzer jedoch nicht auf "Senden" drückteund geht vom Schreibtisch weg.In einem offenen Büro mit der Öffentlichkeit (Kunden) in Reichweite wurde dies als geeignete Kontrolle angesehen.Die Webanwendung hat auch die Zeit für angemeldete Benutzer nach einer etwas längeren Zeit abgelaufen. Ich glaube, es waren 3 Minuten inaktiver Nutzung.
2) Der Angreifer überprüft das Kennwortfeld mit den Browser-Entwicklungstools.
@xehpuk Nur wenn sie wissen, dass dieses System vorhanden ist.Wenn sie sich dessen nicht bewusst waren, versuchten sie einfach, sich anzumelden, und löschten so das Passwort-Eingabefeld.
@GrumpyCrouton Die Annahme, dass ein potenzieller Angreifer dumm ist, ist bei der Implementierung von Sicherheitsmaßnahmen keine gute Idee.Der Angriffsvektor existiert unabhängig von diesem System in beiden Richtungen.
@GrumpyCrouton Ich bin anderer Meinung.Die wahrscheinlichste Vorgehensweise besteht darin, zuerst zu überprüfen.Und dann klicken Sie auf Login.Auf diese Weise haben Sie jetzt Zugriff, können später darauf zugreifen und wahrscheinlich auch das Passwort zurücksetzen (wenn es nicht auf einer E-Mail-Bestätigung beruht) :)
@xDaizu Ich denke, dass die meisten Leute bei einer Gelegenheit in einem Konto nicht so weit voraus denken würden, ohne zu wissen, wie lange Sie noch Zeit haben, bis der Inhaber des Kontos zurückkommt.Der typische Täter in dieser Situation würde meiner Meinung nach nicht vorausdenken, wie er es später wieder tun wird, aber einige mögen es tun.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...