Der definitive Leitfaden für formularbasierte Website-Authentifizierung

stimmen
4k

Formularbasierte Authentifizierung für Websites

Wir glauben, dass Stack-Überlauf sollte nicht nur eine Ressource für sehr spezifische technische Fragen, sondern auch für die allgemeinen Richtlinien, wie Variationen über gemeinsame Probleme zu lösen. „Form basierte Authentifizierung für Websites“ sollte ein schönes Thema für ein solches Experiment sein.

Es soll Themen umfassen wie zum Beispiel:

  • Wie anmelden
  • Wie man sich abmeldet
  • Wie bleiben angemeldet
  • Verwalten von Cookies (einschließlich empfohlenen Einstellungen)
  • SSL / HTTPS-Verschlüsselung
  • Wie zum Speichern von Passwörtern
  • Mit geheimen Fragen
  • Forgotten Benutzername / Passwort-Funktionalität
  • Die Verwendung von Nonces zu verhindern Cross-Site Request Fälschungen (CSRF)
  • OpenID
  • „Passwort merken“ Checkbox
  • Browser die automatische Vervollständigung von Benutzernamen und Passwörtern
  • Geheime URLs (öffentliche URL durch Digest geschützt)
  • Überprüfung der Passwortstärke
  • E-Mail-Validierung
  • und vieles mehr über formularbasierte Authentifizierung ...

Es sollte nicht gehören Dinge wie:

  • Rollen und Autorisierung
  • HTTP-Basisauthentifizierungs

Bitte helfen Sie uns durch:

  1. was darauf hindeutet, untergeordnete Themen
  2. Einreichen gute Artikel zu diesem Thema
  3. Bearbeiten der offiziellen Antwort
Veröffentlicht am 02/08/2008 um 20:51
quelle vom benutzer
In anderen Sprachen...                            


12 antworten

stimmen
3k

TEIL I: Wie Anmelden

Wir werden annehmen, dass Sie bereits wissen, wie ein Login + Passwort HTML-Formular erstellen, die POSTs die Werte an ein Skript auf der Serverseite für die Authentifizierung. Die Abschnitte werden unten mit Mustern für Sound praktische Auth umgehen, und wie Sie die häufigsten Sicherheits Fallen zu vermeiden.

Um HTTPS oder nicht zu HTTPS?

Es sei denn, die Verbindung bereits sicher ist (das heißt, getunnelt über HTTPS mit SSL / TLS), werden Ihre Login-Formular Werte unverschlüsselt gesendet werden, die jemand auf der Linie zwischen Browser und Web-Server in der Lage, Anmeldungen zu lesen Abhören erlaubt, wie sie passieren durch. Diese Art von wiretapping wird routinemäßig von den Regierungen getan, aber im Allgemeinen werden wir nicht ‚im Besitz‘ Drähte andere Adresse als das zu sagen: Wenn Sie etwas Wichtiges, schützen HTTPS verwenden.

Im Wesentlichen die einzige praktische zu schützen Art und Weise gegen Abhören / Paket bei der Anmeldung Schnüffeln ist mithilfe von HTTPS oder anderem Zertifikat-basiertes Verschlüsselungsschema (zB TLS ) oder ein bewährter und geprüfte Challenge-Response - Schema (zum Beispiel des Diffie-Hellman -basierte SRP). Jedes andere Verfahren kann leicht umgangen werden durch einen Lausch Angreifer.

Natürlich, wenn Sie bereit sind, ein wenig unpraktisch zu bekommen, können Sie auch eine Form von Zwei-Faktor-Authentifizierungsschema (zB des Google Authenticator-App, ein physisches ‚kalten Krieg-Stil‘ Codebuch oder einen RSA-Schlüsselgenerator Dongle) verwenden. Bei richtigen Anwendung könnte diese Arbeit auch mit einer ungesicherten Verbindung, aber es ist schwer vorstellbar, dass ein Entwickler bereit wäre, Zwei-Faktor-Authentifizierungs zu implementieren, aber nicht SSL.

(Nicht) Roll-your-own JavaScript Verschlüsselung / Hashing

Aufgrund der Nicht-Null-Kosten und wahrgenommen technischer Schwierigkeiten bei der Einstellung ein SSL-Zertifikats auf Ihrer Website, sind einige Entwickler versucht, ihr eigenes in-Browser-Hashing oder Verschlüsselungsschema zu rollen, um unverschlüsselt Anmeldungen über einen ungesicherten Draht zu vermeiden vorbei.

Während dies ein edler Gedanke ist, ist es im Wesentlichen nutzlos (und kann eine seiner Sicherheitslücke ) , wenn es mit einem der oben kombiniert wird - das heißt, entweder die Linie mit starken Verschlüsselung zu sichern oder ein erprobte und bewährtes Challenge-Response mit Mechanismus (wenn Sie nicht wissen , was das ist, weiß nur, dass es eines der am schwierigsten zu beweisen, am schwierigsten zu entwerfen, und am schwierigsten zu implementieren Konzepte im Bereich digitale Sicherheit).

Es stimmt zwar, dass die Passwort - Hashing sein kann gegen wirksames Passwort Offenlegung , es ist anfällig Angriffe zu wiederholen, Man-In-The-Middle - Angriffe / Entführungen (wenn ein Angreifer ein paar Bytes in der ungesicherte HTML - Seite injizieren kann , bevor es erreicht Ihre Browser, können sie einfach das Hashing in der JavaScript - Kommentar aus) oder Brute-Force - Angriffe (da Sie die Angreifer beiden Benutzername, Salz verteilen und Hash - Passwort).

CAPTCHAS gegen die Menschlichkeit

CAPTCHAs soll eine bestimmte Kategorie von Angriff vereiteln: automatisierte Wörterbuch / Brute - Force - Trial-and-error ohne menschliche Bediener. Es besteht kein Zweifel , dass dies eine reale Bedrohung ist, aber es gibt Wege für den Umgang damit , dass sich nahtlos ein CAPTCHA nicht erfordern, und zwar richtig server Login Drosselung der Konzeption von Systemen - wir diejenigen später besprechen werden.

Wissen , dass die CAPTCHA - Implementierungen sind nicht gleich geschaffen; sie sind oft nicht menschlich-auflösbar, sind die meisten von ihnen tatsächlich unwirksam gegen Bots, alle von ihnen sind unwirksam gegen billige Arbeitskräfte der Dritten Welt (nach OWASP , die aktuelle ausbeute Rate $ 12 pro 500 Tests), und einige Implementierungen können technisch illegal in einigen Ländern (siehe OWASP Authentication Cheat Sheet ). Wenn Sie ein CAPTCHA verwenden müssen, verwenden Googles reCAPTCHA , da es OCR-hart ist per Definition (da es bereits verwendet OCR-fehlklassifiziert Buch - Scans) und bemüht sich sehr benutzerfreundlich zu sein.

Persönlich neige ich CAPTCHAS ärgerlich, und nutzen sie nur als letztes Mittel zu finden, wenn ein Benutzer eine Anzahl von Malen und Drosselung Verzögerungen einzuloggen sind maxxed out ausgefallen ist. Dies wird geschehen, selten genug, um akzeptabel zu sein, und es stärkt das System als Ganzes.

Das Speichern von Kennwörtern / Überprüfen der Anmeldungen

Dies kann schließlich allgemein bekannt sein, nachdem alle viel beachteten Hacks und Lecks Benutzerdaten, die wir in den letzten Jahren gesehen haben, aber es muss gesagt werden: Sie Passwörter nicht speichern unverschlüsselt in der Datenbank. Benutzerdatenbanken werden regelmäßig gehackt, durchgesickert oder durch SQL-Injektion aufgelesen, und wenn Sie roh, Klartext-Passwörter speichern, dh Instant-Spiel über für Ihre Login-Sicherheit.

Also , wenn Sie das Passwort nicht speichern können, wie überprüfen Sie , dass die Anmeldung + Passwort - Kombination aus dem Login - Formular POSTed korrekt ist? Die Antwort ist Hashing einer mit Schlüsselableitungsfunktion . Jedes Mal , wenn ein neuer Benutzer angelegt wird oder ein Passwort geändert wird, nehmen Sie das Passwort ein und führen Sie es durch eine KDF, wie Argon2, bcrypt, Scrypt oder PBKDF2, das Klartextpasswort drehen ( „correcthorsebatterystaple“) in einen langen, zufällig aussehende Zeichenfolge , was viel sicherer ist in Ihrer Datenbank zu speichern. Um zu überprüfen , ein Login, führen Sie die gleiche Hash - Funktion auf dem eingegebenen Passwort, dieses Mal in dem Salz vorbei und vergleichen Sie den resultierenden Hash - String auf den Wert in der Datenbank gespeichert. Argon2, bcrypt und Scrypt speichert das Salz mit dem Hash bereits. Schauen Sie sich diesen Artikel auf sec.stackexchange für weitere Informationen.

Der Grund , ein Salz verwendet wird, weil an sich Hashing nicht ausreichend ist - Sie werden ein so genanntes ‚Salz‘ hinzufügen wollen den Hash gegen schützen Rainbow - Tabellen . Ein Salz verhindert effektiv zwei Passwörter , die genau von Übereinstimmen als den gleichen Hash - Wert gespeichert werden, die gesamte Datenbank zu verhindern in einem Durchgang gescannt werden , wenn ein Angreifer ein Passwort ausführt erraten Angriff.

Ein kryptographisches Hash sollte nicht für Passwortspeicherung verwendet werden , da Benutzer gewählten Passwörter nicht stark genug sind (dh in der Regel nicht enthalten genug Entropie) und ein Passwort zu erraten Angriff könnte mit Zugriff auf die Hash - Werte in einer relativ kurzen Zeit von einem Angreifer abgeschlossen sein. Aus diesem Grunde ist ein KDF verwendet wird - diese effektiv „den Schlüssel strecken“ was bedeutet , dass jedes Passwort erraten ein Angreifer macht beinhaltet Iterieren die Hashing - Algorithmus mehrfach, beispielsweise 10.000 Mal, so dass das Passwort des Angreifers zu raten 10.000 mal langsamer.

Sitzungsdaten - „Sie sind angemeldet als Spiderman69“

Sobald der Server den Benutzernamen und das Passwort gegen Ihre Benutzerdatenbank überprüft hat und eine Übereinstimmung gefunden wird, muss das System eine Möglichkeit, sich daran zu erinnern, dass der Browser authentifiziert wurde. Diese Tatsache sollte immer nur Serverseite in den Sitzungsdaten gespeichert werden.

Wenn Sie mit Sitzungsdaten nicht vertraut sind, ist hier, wie es funktioniert: Eine einzelne zufällig generierte Zeichenfolge wird in einer auslaufenden Cookie gespeichert und verwendet, um eine Sammlung von Daten zu verweisen - die Sitzungsdaten - die auf dem Server gespeichert ist. Wenn Sie einen MVC-Framework verwenden, ist dies zweifellos bereits behandelt.

Wenn möglich, stellen Sie sicher , dass der Session - Cookie die sicheren und HTTP hat nur Flags gesetzt , wenn an den Browser gesendet. Die Httponly - Flag bietet einen gewissen Schutz gegen den Cookie durch einen XSS - Angriff gelesen werden. Die sichere Flag sorgt dafür , dass das Cookie nur über HTTPS zurückgeschickt, und schützt somit vor Netzwerk - Sniffing - Angriffen. Der Wert des Cookies sollte nicht vorhersehbar sein. Wo ein Cookie eine nicht existierende Sitzung Referenzierung präsentiert wird , soll sein Wert sofort ersetzt werden , um zu verhindern , dass Session - Fixation .

TEIL II: Wie angemeldet bleiben - The Infamous "Remember Me" Checkbox

Persistent Login-Cookies ( "remember me" -Funktionalität) sind eine Gefahrenzone; auf der einen Seite sind sie ganz so sicher wie konventionelle Anmeldungen, wenn Benutzer zu verstehen, wie sie zu handhaben; und auf der anderen Seite sind sie ein enormes Sicherheitsrisiko in den Händen von unvorsichtigen Anwendern, die sie auf öffentlichen Computern verwenden können und vergessen, sich abzumelden, und wer kann sie nicht wissen, welche Browser-Cookies sind oder wie sie löschen.

Ich persönlich mag persistent Anmeldungen für die Web-Seiten, die ich auf einer regelmäßigen Basis zu besuchen, aber ich weiß, wie sie sicher zu handhaben. Wenn Sie sicher sind, dass die Benutzer das gleiche kennen, können Sie persistent Logins mit einem sauberen Gewissen verwenden. Wenn nicht - na ja, dann können Sie auf die Philosophie abonnieren, die Benutzer, die mit ihren Zugangsdaten sorglos brachte es auf sich, wenn sie gehackt. Es ist nicht wie wir unseren Benutzer-Häuser gehen und abreißen alle facepalm auslösende Post-It Notes mit Passwörtern sie haben, entweder auf dem Rand ihrer Monitore aufgereiht.

Natürlich leisten einige Systeme nicht haben keine gehackten Accounts; für solche Systeme, gibt es keine Möglichkeit, persistente Anmeldungen mit rechtfertigen kann.

Wenn Sie sich entscheiden persistent Login-Cookies zu implementieren, das ist, wie Sie es tun:

  1. Zuerst nehmen Sie sich etwas Zeit zu lesen Paragon Initiative Artikel zu diesem Thema. Sie werden eine Reihe von Elementen , rechts, und der Artikel macht einen guten Job zu erklären , jeder bekommen müssen.

  2. Und nur eine der häufigsten Fallen zu wiederholen, NICHT die persistenten LOGIN COOKIE (TOKEN) in der Datenbank speichern, NUR EIN HASH OF IT! Der Login - Token ist Passwort - Äquivalent, also wenn ein Angreifer ihre Hände auf die Datenbank erhalten, sie die Token verwenden könnte zu jedem Konto anmelden, so als ob sie unverschlüsselt Login-Passwort - Kombinationen waren. Verwenden Sie daher Hashing (nach https://security.stackexchange.com/a/63438/5002 einem schwachen Hash wird zu diesem Zweck nur gut tun) , wenn persistent Login - Token gespeichert werden .

TEIL III: Mit Geheimfragen

Sie nicht ‚geheime Fragen‘ implementieren . Die ‚Geheimnis Fragen‘ -Funktion ist ein Sicherheits - anti-Muster. Lesen Sie das Papier von Verbindungsnummer 4 aus der MUST-READ - Liste. Sie können über diese eine Sarah Palin fragen nach ihrem Yahoo! E - Mail - Konto wurde während einer früheren Präsidentschafts - Kampagne gehackt , weil die Antwort auf ihre Sicherheitsfrage war ... „Wasilla High School“!

Auch mit vom Benutzer angegebenen Fragen, ist es sehr wahrscheinlich, dass die meisten Nutzer entweder wählen werden:

  • Eine ‚Standard‘ geheime Frage wie Mädchenname der Mutter oder Lieblingstier

  • Ein einfaches Stück Trivia, dass jemand aus ihrem Blog, LinkedIn Profil heben konnte, oder ähnlich

  • Jede Frage, die leichter zu beantworten als ihr Passwort zu erraten. Welche, für jedes anständiges Passwort, jede Frage, die Sie sich vorstellen können

Abschließend sind Sicherheitsfragen von Natur aus unsicher in nahezu allen Formen und Variationen, und sollte nicht in einem Authentifizierungsschema aus irgendeinem Grund verwendet werden.

Der wahre Grund, warum Sicherheitsfragen auch in der freien Natur gibt, ist, dass sie bequem die Kosten für ein paar Support-Anrufe von Benutzern speichern, die nicht ihre E-Mail an einen Reaktivierungscode erhalten zugreifen können. Dies auf Kosten der Sicherheit und Sarah Palins Ruf. Es ist es wert? Wahrscheinlich nicht.

TEIL IV: Passwort vergessen Funktionalität

Ich habe bereits erwähnt , warum sollten Sie nie Sicherheitsfragen verwenden für den Umgang vergessen / verloren Benutzer - Passwörter; es ist auch selbstverständlich , dass Sie nie ihre tatsächlichen Passwörter E-Mail - Nutzer sollten. Es gibt mindestens zwei weitere allzu häufige Probleme in diesem Bereich zu vermeiden:

  1. Nicht zurückgesetzt ein vergessenes Kennwort zu einem automatisch generierten starkes Passwort - solche Passwörter sind bekanntlich schwer zu erinnern, was bedeutet , dass der Benutzer muss entweder ändern oder schreiben Sie es auf - sagen wir, auf einem leuchtend gelben Post-It auf dem Rand ihres Monitors. Anstatt ein neues Passwort setzen, lassen Sie Benutzer sofort eine neue holen - das ist , was sie ohnehin tun wollen.

  2. Immer Hash das verlorene Passwort Code / Token in der Datenbank. WIEDER , ist dieser Code ein weiteres Beispiel eines Passwort - äquivalent, also muss es ein Angreifer bekam ihre Hände auf Ihrer Datenbank bei gehasht werden. Wenn ein verlorenes Passwort Code angefordert wird, die Klartextcode an die E - Mail - Adresse des Benutzers zu senden, dann ist es Hash, den Hash in der Datenbank speichern - und das Original wegzuwerfen . Genau wie ein Passwort oder eine persistente Login - Token.

Eine letzte Anmerkung: immer Ihre Schnittstelle zur Eingabe des ‚verlorenen Passwort Code‘ stellen Sie sicher, zumindest so sicher wie Ihr Login-Formular selbst oder ein Angreifer einfach diesen Zugriff zu erhalten stattdessen verwenden. Sicherstellen, dass Sie sehr lange generieren ‚verlorenen Passwort-Codes‘ (zum Beispiel 16 Groß- und Kleinschreibung alphanumerische Zeichen) ist ein guter Anfang, aber bedenken Sie das gleiche Drosselschema hinzufügen, die Sie für das Login-Formular tun sich.

TEIL V: Überprüfung der Kennwortstärke

Zunächst werden Sie mit diesen kleinen Artikel für einen Reality - Check lesen wollen: Die 500 häufigsten Passwörter

Okay, vielleicht die Liste ist nicht die kanonische Liste der häufigsten Passwörter auf jedem System überall immer , aber es ist ein guter Indikator dafür , wie schlecht die Menschen ihre Passwörter wählen , wenn es keine erzwungene Politik an seinem Platz ist. Außerdem sieht die Liste erschreckend Nähe von zu Hause , wenn Sie es vergleichen zu öffentlich zugänglichen Analysen vor kurzem gestohlen Passwörter.

Also: ohne Mindest Passwort Festigkeitsanforderungen, 2% der Nutzer verwenden eine der Top 20 am häufigsten Passwörter. Das heißt: wenn ein Angreifer nur 20 Versuche bekommt, 1 in 50 Konten auf Ihrer Website zu knacken sein.

Vereitelung erfordert dies die Entropie eines Passworts zu berechnen und dann einen Schwellenwert anzuwenden. Das National Institute of Standards and Technology (NIST) Special Publication 800-63 hat eine Reihe von sehr guten Vorschläge. Das, wenn sie mit einem Wörterbuch und Tastaturlayout Analyse kombiniert (zum Beispiel ‚qwertyuiop‘ ist ein falsches Kennwort) können 99% aller schlecht gewählten Passwörter ablehnen auf einem Niveau von 18 Bits der Entropie. Einfach die Berechnung der Stärke von Passwörtern und eine visuelle Stärke Meter zeigt auf ein Benutzer gut, aber nicht ausreichend. Es sei denn , es erzwungen wird, werden viele Nutzer wahrscheinlich ignorieren.

Und für ein erfrischendes nehmen auf Benutzerfreundlichkeit mit hoher Entropie Passwörter, Randall Munroe Passwort Stärke xkcd ist sehr zu empfehlen.

TEIL VI: Viel mehr - Oder: Verhindern Schnellfeueranmeldeversuche

Zuerst müssen Sie einen Blick auf die Zahlen: Password Recovery Geschwindigkeiten - Wie lange wird Ihr Passwort aufstehen

Wenn Sie die Tabellen nicht die Zeit haben, um in diesem Link durchschauen, hier ist die Liste von ihnen:

  1. Es dauert fast keine Zeit , ein schwaches Passwort zu knacken, auch wenn Sie es mit einem Abakus sind Cracken

  2. Es dauert fast keine Zeit , ein alphanumerisches 9-Zeichen - Passwort zu knacken, wenn es Groß- und Kleinschreibung

  3. Es dauert fast keine Zeit , eine komplizierten, Symbole-und-Buchstaben-and-Zahlen zu knacken, mit oberem und Klein Passwort, wenn es weniger als 8 Zeichen lang sein (ein Desktop - PC kann den gesamten Schlüsselraum in einem bis 7 Zeichen sucht nach oben Frage von Tagen oder sogar Stunden)

  4. Es wäre jedoch nehmen unmäßig viel Zeit sogar ein 6-stelliges Passwort zu knacken, wenn Sie pro Sekunde auf einen Versuch beschränkt waren!

Was können wir aus diesen Zahlen lernen? Nun, viele, aber wir können auf den wichtigsten Teil konzentrieren: die Tatsache , dass die Prävention eine große Anzahl von Schnellfeueraufeinanderfolgende Anmeldeversuche (dh. Brute - Force - Angriff) wirklich nicht so schwierig ist. Aber es verhindert Recht ist nicht so einfach wie es scheint.

Im Allgemeinen haben Sie drei Möglichkeiten , die alle wirksam gegen Brute-Force - Angriffe sind (und Wörterbuch - Attacken, aber da Sie bereits eine starke Passwörter Politik beschäftigen, sollten sie nicht ein Problem sein) :

  • Präsentieren Sie eine CAPTCHA nach N fehlgeschlagenen Versuchen (ärgerlich wie die Hölle und oft wirkungslos - aber ich wiederhole mich hier)

  • Sperren Konten und erfordern E - Mail - Überprüfung nach N fehlgeschlagenen Versuchen (dies ist ein DoS wartet Angriff passieren)

  • Und schließlich Login Drosselung : das heißt, eine Zeitverzögerung zwischen dem Versuchen Einstellung nach N fehlgeschlagenen Versuchen (ja, Schutz vor DoS - Angriffe sind immer noch möglich, aber zumindest sind sie weit weniger wahrscheinlich und viel komplizierter abziehen).

Best practice # 1: Eine kurze Zeitverzögerung , die mit der Anzahl der Fehlversuche erhöht, wie:

  • 1 = gescheiterter Versuch keine Verzögerung
  • 2 gescheiterten Versuchen = 2 sec Verzögerungs
  • 3 Fehlversuche = 4 sec Verzögerungs
  • 4 Fehlversuchen = 8 sec Verzögerungs
  • 5 gescheiterten Versuchen = 16 sec Verzögerungs
  • etc.

DoS-Angriff auf diese Regelung wäre sehr unpraktisch sein, da die resultierende Sperrzeit etwas größer ist als die Summe der bisherigen Sperrzeiten ist.

Zur Klarstellung: Die Verzögerung ist nicht eine Verzögerung , bevor die Antwort an den Browser zurück. Es ist eher wie ein Timeout oder refraktäre Periode , während der Versuche auf ein bestimmtes Konto anmelden oder von einer bestimmten IP - Adresse wird nicht akzeptiert oder ausgewertet werden. Das heißt, die richtigen Anmeldeinformationen nicht in einer erfolgreichen Anmeldung zurück und falsche Anmeldeinformationen werden keine Verzögerung Anstieg auslösen.

Best practice # 2: Eine mittlere Länge Zeitverzögerung , die in Kraft tritt , nachdem N Versuche schlug fehl, wie:

  • 1-4 Fehlversuche = keine Verzögerung
  • 5 gescheiterten Versuchen = 15-30 min Verzögerungs

DoS-Angriff auf dieses Schema wäre ziemlich unpraktisch, aber sicherlich machbar. Auch könnte es relevant sein, zu beachten, dass eine so lange Verzögerung kann für einen berechtigten Benutzer sehr ärgerlich sein. Vergesslich Nutzer werden Sie nicht mögen.

Best practice # 3: Die Kombination der beiden Ansätze - entweder eine feste, kurze Zeitverzögerung , die in Kraft tritt , nachdem N Versuche schlugen fehl, wie:

  • 1-4 Fehlversuche = keine Verzögerung
  • 5+ Fehlversuche = 20 sec Verzögerungs

Oder eine zunehmende Verzögerung mit einer oberen Grenze befestigt sind, wie:

  • 1 gescheiterten Versuch = 5 sec Verzögerungs
  • 2 gescheiterten Versuchen = 15 sec Verzögerungs
  • 3+ Fehlversuche = 45 sec Verzögerungs

Diese endgültige Regelung wurde von dem OWASP Best Practices Vorschlägen (link 1 von der MUST-READ-Liste) aufgenommen und soll bewährte Verfahren in Betracht gezogen werden, auch wenn es zugegebenermaßen auf der restriktiven Seite.

aber als Faustregel, würde ich sagen: Je stärker Ihr Passwort Politik ist, desto weniger Sie Fehler Benutzer mit Verzögerungen haben. Wenn Sie stark (case-sensitive alphanumerics + erforderlichen Zahlen und Symbole) 9+ Zeichen Passwörter benötigen, können Sie den Benutzer 2-4 nicht verzögerten Kennwortversuche geben, bevor die Drosselung aktivieren.

DoS diese letzte Login Drosselung Schema Angriff wäre sehr unpraktisch. Und als letzten Schliff, erlauben immer persistent (Cookie) Anmeldungen (und / oder ein CAPTCHA-prüft Anmeldeformular) durchlaufen, so berechtigte Benutzer werden nicht einmal verzögert werden , während der Angriff im Gange ist . Auf diese Weise wird der sehr unpraktisch DoS - Angriff ein äußerst unpraktisch Angriff.

Darüber hinaus ist es sinnvoll aggressivere Drosselung auf Admin-Konten zu tun, da diejenigen, die attraktivsten Eingangspunkte sind

TEIL VII: Distributed Brute Force-Angriffe

Nebenbei bemerkt, fortschrittlichere Angreifer werden versuchen Login Drosselung durch ‚die Verbreitung ihrer Aktivitäten‘ zu umgehen:

  • Die Verteilung der Versuche auf einem Botnet IP-Adresse Beflaggung zu verhindern

  • Anstatt ein Benutzer sammeln und versuchen, die 50.000 am häufigsten Passwörter (was sie nicht können, wegen unserer Drosselung), werden sie die häufigste Passwort wählen und gegen 50.000 Benutzer stattdessen versuchen. Auf diese Weise, nicht nur sie um maximal Versuche Maßnahmen wie CAPTCHAs und Login-Drosselung, ihre Erfolgschancen erhöht sich auch erhalten, da die Nummer 1 am häufigsten Passwort weit häufiger als Nummer 49,995 ist

  • Abstand die Anmeldeanforderungen für jedes Benutzerkonto, sagen 30 Sekunden auseinander, unter dem Radar zu schleichen

Hier würde die Best - Practice - Protokollierung der Anzahl fehlgeschlagener Logins, systemweite und mit einem laufenden Durchschnitt von Ihrer Website bad-Login Frequenz als Grundlage für eine obere Grenze , die Sie dann auf alle Benutzer verhängen.

Zu abstrakt? Lassen Sie mich anders formulieren:

Sagen Sie Ihre Website durchschnittlich 120 schlecht Anmeldungen pro Tag in den letzten 3 Monaten gehabt hat. Mit Hilfe dieses (gleitenden Mittelwert), Ihr System könnte das globale Limit bis 3-mal eingestellt, dass - dh. 360 Fehlversuche über einen Zeitraum von 24 Stunden. Dann wird, wenn die Gesamtzahl der Fehlversuche für alle Konten, die Zahl innerhalb eines Tages übersteigt (oder noch besser, überwachen die Geschwindigkeit der Beschleunigung und Trigger für eine berechnete Schwelle), aktiviert es systemweite Anmelde Drosselung - kurze Verzögerungen für alle Benutzer bedeutet (immer noch, mit Ausnahme von Cookie-Logins und / oder Backup-CAPTCHA Logins).

Ich stellte auch eine Frage mit mehr Details und eine wirklich gute Diskussion darüber , wie heikel pitfals zu vermeiden , in verteilten Brute - Force - Angriffe abwehren

VIII TEIL: Zwei-Faktor-Authentifizierung und Authentifizierungsanbieter

Credentials kann beeinträchtigt werden, sei es durch Exploits, Passwörter aufgeschrieben zu werden und verloren, Laptops mit Schlüssel gestohlen wird, oder Benutzer-Logins in Phishing-Seiten eingeben. Logins kann weiter mit Zwei-Faktor-Authentisierung geschützt werden, die out-of-binden Faktoren verwenden, wie beispielsweise Einweg-Codes von einem Telefonanruf empfangen wird, SMS-Nachricht, app oder Dongles. Einige Anbieter bieten Authentifizierungsdienste Zwei-Faktor.

Die Authentifizierung kann vollständig auf einen Single-Sign-On-Dienst übertragen werden, wo ein anderer Anbieter Anmeldeinformationen Griffe zu sammeln. Dies drückt das Problem zu einem vertrauenswürdigen Dritten. Google und Twitter bieten sowohl standardbasierte SSO Dienste, während Facebook eine ähnliche proprietäre Lösung.

MUST-READ LINKS über Web-Authentifizierung

  1. OWASP Guide To Authentication / OWASP - Authentifizierung Spickzettel
  2. Dos und Don'ts der Client-Authentifizierung auf dem Web (sehr gut lesbar MIT Forschungspapier)
  3. Wikipedia: HTTP-Cookie
  4. Persönliche Wissensfragen für Rückfall-Authentifizierung: Sicherheitsfragen im Zeitalter von Facebook (sehr gut lesbar Berkeley Forschungspapier)
Beantwortet am 25/01/2009 um 12:27
quelle vom benutzer

stimmen
382

definitive Artikel

Senden Anmeldeinformationen

Die einzige praktische Möglichkeit , Anmeldeinformationen zu 100% sicher zu senden , ist die Verwendung von SSL . Mit Hilfe von JavaScript , das Passwort Hash ist nicht sicher. Häufige Probleme für die clientseitige Passwort - Hashing:

  • Wenn die Verbindung zwischen dem Client und dem Server verschlüsselt ist, alles , was Sie tun , ist anfällig für Man-in-the-Middle - Angriffe . Ein Angreifer könnte die eingehende Javascript ersetzt die Hashing zu brechen oder alle Anmeldeinformationen , um ihre Server zu senden, sie auf Client - Antworten hören konnten und imitieren die Benutzer perfekt, etc. etc. SSL mit vertrauenswürdigen Zertifizierungsstellen soll MITM - Angriffe zu verhindern.
  • Das Hash - Passwort vom Server empfangen ist weniger sicher , wenn Sie nicht auf dem Server zusätzliche, redundante Arbeit tun.

Es gibt eine andere sichere Methode namens SRP , aber es ist patentiert (obwohl es frei lizenziert ) und es gibt nur wenige gute Implementierungen zur Verfügung.

Das Speichern von Kennwörtern

Nicht immer speichern Passwörter als Klartext in der Datenbank. Nicht einmal , wenn Sie die Sicherheit Ihrer eigenen Website kümmern sich nicht. Es sei angenommen , dass einige Ihrer Benutzer das Passwort ihrer Online - Bankkonto wiederverwenden. So speichern Sie das Hash - Passwort, und wirft das Original entfernt. Und stellen Sie sicher , dass das Passwort nicht zeigen in Zugriffsprotokolle oder Anwendungsprotokolle auf. OWASP empfiehlt die Verwendung von Argon2 als erste Wahl für neue Anwendungen. Wenn diese nicht verfügbar ist, PBKDF2 oder Scrypt sollte stattdessen verwendet werden. Und schließlich , wenn keine der oben verfügbar sind, verwenden bcrypt.

Hashes selbst ist auch unsicher. Zum Beispiel bedeuten identische Passwörter identisch Hashes - diese Hash - Lookup - Tabellen eine wirkungsvolle Möglichkeit, auf einmal viele Passwörter Knacken macht. Stattdessen speichert die gesalzene Hash. Ein Salz ist eine Zeichenfolge , um das Passwort vor dem Hashing beigefügte - ein anderes (random) Salz pro Benutzer verwenden. Das Salz ist ein öffentlicher Wert, so dass Sie sie mit dem Hash in der Datenbank speichern können. Sehen Sie hier für weitere Informationen hierzu.

Das bedeutet, dass Sie nicht die Benutzer ihre vergessene Passwörter senden können (weil Sie nur den Hash). Sie nicht das Kennwort des Benutzers zurückgesetzt, wenn Sie den Benutzer authentifiziert haben (Benutzer müssen nachweisen, dass sie E-Mails lesen, auf die gespeicherten (und validiert) E-Mail-Adresse gesendet werden können.)

Sicherheitsfragen

Sicherheitsfragen sind unsicher - vermeiden sie zu benutzen. Warum? Alles , was eine Sicherheitsfrage tut, tut ein Passwort besser. Lesen TEIL III: Mit Geheimfragen in @Jens Roland beantworten hier in diesem Wiki.

Session-Cookies

Nachdem der Benutzer anmeldet, sendet der Server dem Benutzer eine Session-Cookie. Der Server kann den Benutzernamen oder die ID aus dem Cookie abrufen, aber niemand kann sonst erzeugen so ein Cookie (TODO Mechanismen erklären).

Cookies können missbraucht werden : sie sind nur so sicher wie der Rest der Maschine des Kunden und andere Kommunikation. Sie können von der Festplatte gelesen werden, schnupperte in dem Netzwerkverkehr durch einen Cross-Site - Scripting - Angriff angehoben, von einem vergifteten DNS fischte , damit der Client ihre Cookies auf den falschen Server sendet. Senden Sie keine permanente Cookies. Cookies sollte am Ende der Client - Sitzung (Browser schließen oder ich von Ihrer Domain) auslaufen.

Wenn Sie Ihre Benutzer Autologin möchten, können Sie eine persistente Cookie gesetzt, aber es sollte von einem Voll Session-Cookie unterscheiden. Sie können eine zusätzliche Flag gesetzt, dass der Benutzer in hat auto-angemeldet, und muss für die real für sensible Vorgänge einzuloggen. Dies ist beliebt bei der Shopping-Site, die Sie mit einem nahtlosen, personalisierte Shopping-Erlebnis bieten wollen, aber immer noch Ihre finanziellen Details zu schützen. Zum Beispiel, wenn Sie besuchen Amazon zurückkehren, zeigen sie Ihnen eine Seite, wie Sie angemeldet aussieht, aber wenn Sie eine Bestellung aufgeben gehen (oder Ihre Lieferadresse ändern, Kreditkarte etc.), fragen sie Sie bestätigen Ihr Passwort.

Finanz-Webseiten wie Banken und Kreditkarten, auf der anderen Seite, haben nur sensible Daten und sollten nicht Auto-Login oder eine Low-Sicherheitsmodus ermöglichen.

Liste der externen Ressourcen

Beantwortet am 02/08/2008 um 21:40
quelle vom benutzer

stimmen
146

Zunächst wird eine starke Einschränkung, dass diese Antwort nicht die beste Lösung für diese genaue Frage. Es sollte auf jeden Fall nicht die Top-Antwort sein!

Ich werde gehen Sie vor und erwähnen Mozilla vorgeschlagene BrowserID (oder vielleicht genauer gesagt, die Bestätigte E - Mail - Protokoll ) im Geiste einen Upgrade - Pfad zu einer besseren Ansätze zu finden , in die Zukunft Authentifizierung.

Ich werde es so zusammenfassen:

  1. Mozilla ist ein Non - Profit mit Werten , die gut ausgerichtet mit diesem Problem , gute Lösungen zu finden.
  2. Die Realität heute ist, dass die meisten Websites verwenden formularbasierte Authentifizierung
  3. Formularbasierte Authentifizierung hat einen großen Nachteil, die Gefahr einer erhöhten ist Phishing . Die Benutzer werden gebeten , sensible Informationen in einem Bereich von einem Remote - Einheit gesteuert eingeben, anstatt einen Bereich gesteuert durch ihre User Agent (Browser).
  4. Da Browser implizit vertrauenswürdig ist (die ganze Idee eines User-Agenten ist im Namen des Nutzers zu handeln), können sie helfen, diese Situation zu verbessern.
  5. Die primäre Kraft Fortschritt zurückhalten hier Deployment Deadlock . Es müssen Lösungen werden in einzelne Schritte zerlegt , die auf ihren eigenen einige Zusatznutzen bieten.
  6. Die einfachste dezentralisierte Verfahren zur Expression Identität, die in der Internet-Infrastruktur aufgebaut wird, ist die Domain-Namen.
  7. Als zweite Ebene der Identität ausdrückt, verwaltet jede Domäne einen eigenen Satz von Konten.
  8. Die Form „-Konto @domain“ ist kurz und durch eine Vielzahl von Protokollen und URI - Systemen unterstützt. Eine solche Kennung ist natürlich, allgemeinhin als E - Mail - Adresse erkannt.
  9. E-Mail-Anbieter sind bereits die de-facto primären Identitätsprovider online. Aktuelles Passwort-Reset fließt in der Regel Ihnen die Kontrolle über ein Konto nehmen lassen, wenn Sie, dass Sie im Zusammenhang dieses Kontos E-Mail-Adresse steuern prüfen.
  10. Das verifizierte E-Mail-Protokoll wurde eine sichere Methode, basierend auf Public-Key-Kryptographie, für die Vereinfachung des Verfahrens zu beweisen, zu Domäne B zu versehen, die Sie über ein Konto auf Domäne A haben
  11. Für Browser, die das verifizierte E-Mail-Protokoll (zur Zeit alle von ihnen) nicht unterstützen, bietet Mozilla ein Shim, die das Protokoll in der clientseitige JavaScript-Code implementiert.
  12. Für E-Mail-Dienste, die die Bestätigte E-Mail-Protokoll nicht unterstützen, erlaubt das Protokoll Dritte als vertrauenswürdiger Vermittler zu agieren, zu behaupten, dass sie ein Benutzer Besitz eines Kontos überprüft haben. Es ist nicht wünschenswert, eine große Anzahl solcher Dritten zu haben; Diese Funktion soll nur einen Upgrade-Pfad ermöglichen, und es ist sehr bevorzugt, dass E-Mail-Dienste, diese Behauptungen liefern sich.
  13. Mozilla bietet ihren eigenen Service als eine solche vertrauenswürdige dritte Partei zu handeln. Dienstleister (das heißt, unter Berufung Parteien) das verifizierte E-Mail-Protokolls Implementierung wählt Mozillas Behauptungen oder nicht vertrauen. Mozillas Dienst prüft Benutzerkonto Eigentum mit den herkömmlichen Mitteln der eine E-Mail mit einem Bestätigungslink zu senden.
  14. Dienstleister kann natürlich bietet dieses Protokoll als Option zusätzlich zu jeder anderen Methode (n) die Authentifizierung sie wünschen könnte zu bieten.
  15. Eine große Benutzeroberfläche profitieren hier gesucht wird, ist die „Identität Selektor“. Wenn ein Benutzer eine Website besucht und wählt zu authentifizieren, zeigt ihr Browser sie eine Auswahl an E-Mail-Adressen ( „Personal“, „Arbeit“, „politischen Aktivismus“, etc.) verwenden sie können sich auf der Website zu identifizieren.
  16. Ein weiterer großer Benutzeroberfläche Vorteil gesucht, die als Teil dieser Bemühungen wird wissen , dass der Browser mehr über die Benutzersitzung zu helfen - die sie in , wie sie derzeit angemeldet sind, in erster Linie - so kann es , dass Chrom im Browser angezeigt werden .
  17. Aufgrund der verteilten Natur dieses Systems, sie Lock-in zu großen Websites wie Facebook vermeiden, Twitter, Google usw. Jede Person kann ihre eigene Domain besitzen und daher als eigener Identitätsanbieter handeln.

Dies ist nicht unbedingt „formularbasierte Authentifizierung für Websites“. Aber es ist ein Versuch, aus der aktuellen Norm von formularbasierten Authentifizierung etwas sicherer für den Übergang: Browser-gestützte Authentifizierung.

Beantwortet am 08/08/2011 um 16:32
quelle vom benutzer

stimmen
120

Ich dachte, ich würde diese Lösung teilen, die ich ganz gut zu funktionieren gefunden.

Ich nenne es das Dummy - Feld (obwohl ich das nicht so erfunden habe nicht ich Kredit).

Kurz gesagt: Sie müssen nur das Einfügen in Ihre <form>und prüfen , ob es bei der Validierung leer sein:

<input type="text" name="email" style="display:none" />

Der Trick ist , einen Bot täuschen zu denken , es Daten in ein erforderliches Feld einzufügen hat, deshalb habe ich den Eingang „E - Mail“ genannt. Wenn Sie bereits ein Feld namens E - Mail , die Sie verwenden sollten Sie versuchen , das Dummy - Feld etwas anderes wie „Firma“ zu nennen, „Telefon“ oder „E - Mailadresse“. Wählen Sie einfach etwas , das Sie Sie nicht wissen müssen und was klingt wie etwas , das Menschen normalerweise logisch zu füllen in einem Web - Formular finden würde. Jetzt verstecken das inputFeld mit Hilfe von CSS oder JavaScript / jQuery - was auch immer Sie am besten passt - einfach nicht stellen Sie den Eingang typezu hiddenoder aber der Bot wird nicht darauf hereinfallen.

Wenn Sie die Validierung der Form (entweder Client oder Server-Seite) überprüfen, ob Ihr Dummy-Feld gefüllt wurde, um zu bestimmen, ob es von einem Menschen oder einem Bot senden wurde.

Beispiel:

Im Falle eines Menschen: Der Benutzer wird die Dummy - Feld nicht sehen (in meinem Fall dem Namen „E - Mail“) und wird nicht zu füllen versuchen. So wird der Wert des Dummy - Feld sollte noch leer sein , wenn das Formular senden ist.

Im Falle eines Bot: Der Bot wird ein Feld , dessen Typ sehen textund einen Namen email(oder was auch immer es ist , dass Sie es genannt) und wird versuchen , logisch mit entsprechenden Daten zu füllen. Es kümmert sich nicht darum , ob Sie die Eingabemaske mit einem ausgefallenen CSS, Web-Entwickler gestylt tun es die ganze Zeit. Was auch immer der Wert in dem Dummy - Feld ist, sind wir egal, solange es ist größer als 0Zeichen.

Ich habe diese Methode auf einem Gästebuch in Kombination mit CAPTCHA , und ich habe keine einzige Spam - Post seit gesehen. Ich hatte vor einer CAPTCHA-only Lösung verwendet, aber schließlich es in etwa fünf Spam - Posts führte jede Stunde. Zugabe wird das Dummy - Feld in der Form gestoppt (zumindest bis jetzt) alle Spam erscheinen.

Ich glaube, das kann auch mit einem Login / Authentifizierung Form ganz gut verwendet werden.

Achtung : Natürlich ist diese Methode nicht zu 100% narrensicher ist. Bots können programmiert werden , Eingabefelder mit dem Stil ignorieren display:nonedarauf angewendet. Sie haben auch über die Menschen zu denken , die irgendeine Form von Auto-Vervollständigung verwenden (wie die meisten Browser haben eingebaute!) Zu auto-fill alle Formularfelder für sie. Sie könnten genauso gut wählen Sie ein Dummy - Feld oben.

Sie können dies auch ein wenig, indem man das Blindfeld sichtbar, aber außerhalb der Grenzen des Bildschirms, aber das ist völlig bis zu Ihnen variieren nach oben.

Seien Sie kreativ!

Beantwortet am 22/05/2012 um 13:11
quelle vom benutzer

stimmen
71

Ich glaube nicht, das oben genannte Antwort ist „falsch“, aber es gibt große Bereiche der Authentifizierung, die nicht berührt werden, auf (oder vielmehr die Betonung liegt auf „wie Cookie-Sitzungen zu implementieren“, nicht auf „Welche Optionen stehen zur Verfügung, und was sind die Händel offs“.

Meine vorgeschlagenen Änderungen / Antworten

  • Das Problem liegt mehr in der Kontoeinrichtung als in der Kennwortüberprüfung.
  • Die Verwendung von zwei Faktor authenitication ist viel sicherer als gescheite mittels Passwort-Verschlüsselung
  • Versuchen Sie nicht , Ihr eigenes Login - Formular oder Datenbankspeicherung von Passwörtern zu implementieren, es sei denn , die Daten gespeichert werden , ist wertlos bei der Kontoerstellung und selbsterzeugten (das heißt, Web 2.0 - Stil wie Facebook, Flickr , etc.)

    1. Digest-Authentifizierung ist ein basierter Standard Ansatz in allen gängigen Browsern und Servern unterstützt, die ein Kennwort nicht einmal über einen sicheren Kanal sendet.

Dies vermeidet jede Notwendigkeit „Sitzungen“ oder Cookies als Browser haben, selbst wird die Kommunikation jedes Mal erneut verschlüsseln. Es ist der „leichte“ Entwicklungsansatz.

Allerdings glaube ich nicht empfehlen, außer für den öffentlichen, geringe Wertdienste. Dies ist ein Problem mit einigen der anderen Antworten oben - nicht versuchen, einen neu implementieren serverseitige authetication Mechanismen - dieses Problem gelöst wurde und wird von den meisten gängigen Browsern unterstützt. Verwenden Sie keine Cookies. Speichern Sie nicht alles in der eigenen Hand gerollt Datenbank. Fragen Sie einfach, pro Anfrage, ob die Anforderung autheticated wird. Alles andere sollte von der Konfiguration und von Drittanbietern vertrauenswürdige Software unterstützt werden.

Damit ...

Erstens sind verwirrend wir die erste Erstellung eines Kontos (mit Passwort) mit der erneuten Überprüfung des Passworts anschließend. Wenn ich Flickr bin und Ihre Website zum ersten Mal erstellen, hat der neue Benutzer den Zugriff auf den Wert Null (Leer Webspace). Ich wirklich egal, wenn die Person das Konto erstellt wird über ihren Namen liegen. Wenn ich ein Konto des Krankenhauses Intranet / Extranet erschaffe, liegt der Wert in allen medizinischen Aufzeichnungen, und so habe ich sie über die Identität (*) des Kontos Schöpfer kümmern.

Dies ist das sehr , sehr schwierige Teil. Die einzige anständige Lösung ist ein Web of Trust. Zum Beispiel verbinden Sie das Krankenhaus als Arzt. Sie erstellen eine Webseite irgendwo mit Ihrem Foto gehostet, Ihre Reisepassnummer und einen öffentlichen Schlüssel und Hash sie alle mit dem privaten Schlüssel. Sie besuchen dann das Krankenhaus und der Systemadministrator schaut auf Ihren Reisepass, sieht , wenn das Foto , das Sie übereinstimmt, und dann Hashes die Webseite / Foto Hash mit dem Krankenhaus privaten Schlüssel. Von nun an können wir sicher Schlüssel und Token austauschen. Wie kann jemand, der das Krankenhaus vertraut (es ist das Geheimnis Sauce BTW). Der Systemadministrator kann Sie auch einen geben RSA - Dongle oder andere Zwei-Faktor - Authentifizierung.

Aber das ist eine Menge Ärger, und nicht sehr Web 2.0. Allerdings ist es der einzige sichere Weg , um neue Konten zu erstellen , die den Zugriff auf wertvolle Informationen, die nicht selbst erstellt ist.

  1. Kerberos und SPNEGO - Single Sign - On - Mechanismen mit einem Dritten vertraut - im Grunde der Benutzer überprüft , gegen einen vertrauenswürdigen Dritten. (NB ist dies in keiner Weise die nicht zu trauen OAuth )

  2. SRP - eine Art von cleveren Passwort - Authentifizierung ohne eine vertrauenswürdige dritte Partei. Aber hier sind wir immer in das Reich der „es ist sicherer Zwei - Faktor - Authentifizierung zu verwenden, auch wenn die teurer“

  3. SSL Client - Seite - gibt den Kunden ein öffentliches Schlüssel - Zertifikat (Unterstützung in allen gängigen Browsern - aber wirft Fragen über Client - Computer - Sicherheit).

Am Ende ist es ein Kompromiss - was die Kosten für eine Sicherheitsverletzung ist gegen die Kosten für sicherere Ansätze zu implementieren. Eines Tages können wir eine richtige siehe PKI weithin akzeptierte und so nicht mehr selbst gerollt Authentifizierung Formulare und Datenbanken. Eines Tages...

Beantwortet am 08/08/2011 um 17:29
quelle vom benutzer

stimmen
48

Wenn Hashing, verwenden Sie keine schnellen Hash-Algorithmen wie MD5 (viele Hardware-Implementierungen existieren). Verwenden Sie so etwas wie SHA-512. Für Passwörter, langsamer Hashes sind besser.

Je schneller Sie Hashes erstellen, desto schneller jeder Brute-Force-Checker kann funktionieren. Langsamer Hashes verlangsamt daher nach unten Brute zwingen. Ein langsamer Hashalgorithmus macht brute für längere Passwörter unpraktisch Zwingen (8 Ziffern +)

Beantwortet am 09/08/2011 um 00:07
quelle vom benutzer

stimmen
46

Ein guter Artikel über realistische Passwort Stärke Schätzung:

Dropbox Tech-Blog »Blog Archive» zxcvbn: realistische Passwortstärke Schätzung

Beantwortet am 08/11/2012 um 12:15
quelle vom benutzer

stimmen
41

Mein Liebling Regel in Bezug auf Systeme zur Authentifizierung: Verwenden Sie Passwörter, keine Passwörter. Einfach zu merken, schwer zu knacken. Weitere Informationen: Coding Horror: Passwörter vs. Pass - Sätze

Beantwortet am 24/11/2012 um 22:15
quelle vom benutzer

stimmen
20

Ich möchte einen Vorschlag hinzufügen ich verwendet habe, basierend auf Verteidigung in der Tiefe. Sie brauchen nicht das gleiche Auth & Auth-System für Administratoren als regelmäßige Nutzer haben. Sie können ein separates Login-Formular auf einer separate URL verfügen über separaten Code für Anfragen ausführen, die hohe Privilegien gewährt. Dieser kann Entscheidungen treffen, die insgesamt Schmerzen regelmäßige Nutzer sein würde. Ein so dass ich verwendet habe, ist eigentlich auf die Login-URL für Admin-Zugriff Gerangel und der Admin die neue URL per E-Mail. Stoppen jeden Brute-Force-Angriff sofort als neue URL beliebig schwierig sein kann (sehr lange zufällige Zeichenfolge), aber Ihr Admin-Benutzers nur Unannehmlichkeiten folgen auf einen Link in ihrer E-Mail. Der Angreifer nicht mehr weiß, wo man sogar Post.

Beantwortet am 18/07/2015 um 01:18
quelle vom benutzer

stimmen
12

Ich dont't wissen, ob es am besten, war dies als eine Antwort zu beantworten oder als Kommentar. Ich entschied mich für die erste Option.

In Bezug auf die poing TEIL IV: Passwort vergisst Funktionalität in der ersten Antwort, würde ich einen Punkt über Angriffe Timing.

Im Denken Sie daran , Ihr Passwort Formen könnte ein Angreifer möglicherweise eine vollständige Liste von E - Mail prüfen und erkennen , welche zu dem System registriert werden (siehe Link unten).

das Passwort vergessen Formular in Bezug auf, möchte ich hinzufügen, dass es eine gute Idee ist, mal zwischen erfolgreichen und erfolglosen Anfragen mit einer gewissen Verzögerung Funktion gleich.

https://crypto.stanford.edu/~dabo/papers/webtiming.pdf

Beantwortet am 16/08/2015 um 17:31
quelle vom benutzer

stimmen
10

Ich mag einen sehr wichtigen Kommentar hinzufügen:

  • „In einem Unternehmen, intra- net Einstellung,“ die meisten , wenn nicht alle der vorstehenden Ausführungen gelten möglicherweise nicht!

Viele Unternehmen implementieren „internal use only“ Websites , die sind, effektiv „ Unternehmensanwendungen“ , die über URLs umgesetzt wurden zufällig. Diese URLs können (angeblich ...) nur innerhalb aufgelöst werden „unternehmensinternen Netzwerk.“ (Welche Netzwerk umfasst magische Weise alle VPN-connected ‚Außendienstler.‘)

Wenn ein Benutzer dutifully-ist mit dem oben genannten Netzwerk, ihre Identität ( „Authentifizierung“) ist [bereits ...] „schlüssig bekannt“ , wie ihre Erlaubnis ist ( „Zulassung“) , bestimmte Dinge zu tun ... wie. .. „diese Website zugreifen zu können .“

Diese „Authentifizierung + Autorisierung“ Dienst kann durch mehrere verschiedene Technologien wie LDAP zur Verfügung gestellt werden (Microsoft Open) oder Kerberos.

Von Ihrem Point-of-View, wissen Sie einfach dies: dass jemand , der berechtigterweise windet-up auf Ihrer Website muss „Token“ von begleitet werden [eine Umgebungsvariable auf magische Weise enthält ...] ein ( Dh das Fehlen eines solchen Token für einen unmittelbaren Grund sein 404 Not Found.)

Der Wert des Token macht keinen Sinn für Sie, aber, sollte die Notwendigkeit entstehen, „geeignete Mittel vorhanden sind “ , mit denen Sie Ihre Web-Site kann „[autoritativ] jemanden fragen, der weiß (LDAP ... etc.)“ über jede und jeder ( !) Frage , die Sie haben können. Mit anderen Worten, Sie nicht in Anspruch nehmen , sie von jeder „home-grown - Logik.“ Stattdessen fragen Sie von der Behörde und implizit seinem Urteil vertrauen.

Uh huh ... es ist ganz ein geistig-Schalter von der „Wild und-wolligen Internet.“

Beantwortet am 29/04/2015 um 01:06
quelle vom benutzer

stimmen
5

Verwenden Sie OpenID Connect oder User-Managed Access .

Da nichts ist effizienter, als es überhaupt nicht tun.

Beantwortet am 10/08/2016 um 13:27
quelle vom benutzer

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more