Frage:
Ist diese Anmeldesicherheit ausreichend?
kzap
2011-06-21 07:53:26 UTC
view on stackexchange narkive permalink

Ich erstelle mein nächstes Anmeldesystem für Administratoren einer E-Commerce-Website, das Folgendes enthält:

  • Das Anmeldeformular ist ein SSL-gesichertes
  • Passwort wird vor der Übertragung in SHA-256 konvertiert (bcrypt ist für JS / Browser-Client noch zu langsam)
  • bcrypt gespeicherte Hashes (Ich möchte nicht, dass meine Datenbank, falls sie jemals gestohlen wurde, leicht beschädigt wird)
  • Das Hash-Passwort wird mit einem privaten Schlüssel verschlüsselt, der als Konstante in der App oder Datei gespeichert ist.
  • Ein Hash aller wichtigen Anmeldedatenbankwerte für diesen Benutzer, sodass der Hash, wenn sie durch Injektion irgendwie geändert werden stimmt nicht überein und das Konto wird gesperrt.
  • wird beim ersten Anmeldefehler erneut erfasst.
  • Anmeldesystem pro Gerät. Wenn der Benutzer also 5 verschiedene Anmeldungen versucht und alle falsch sind , er ist raus - es sind nicht 5 pro Login
  • zweiter Schritt auth. Verwenden von SMS, E-Mail oder AlterEgo - möglicherweise einmal pro Gerät + Standort und zur Verwendung, wenn Sie Ihr Kennwort ändern möchten
  • Wenn Sie sich von einem anderen Ort als dem Verlauf aus anmelden, senden Sie eine SMS oder E-Mail an den Benutzer
  • Wenn sich die Geräte- oder Standortinformationen während der Anmeldung ändern, beenden Sie die Sitzung (um Sitzungsdiebstahl zu verhindern).
  • Ermöglichen das Löschen des Anmeldeverlaufs von alten Geräten (Benutzer können Geräte entfernen, die sie nicht mehr verwenden)
  • haben die Option, Anmeldegerät + Speicherort im Verlauf zu speichern (dh verwenden Sie diese Option nicht, wenn Sie sich in einem Netcafe oder einem öffentlichen Netzwerk usw. befinden), sodass Sie immer nach Ihrem zweiten Schritt gefragt werden

Ist diese Anmeldesicherheit ausreichend? Glaubst du, ich werde übertrieben?

... Sie Ihre Passwort-Hashes nicht salzen?
Überparanoid, sieht aber gut aus für mich ;-)
ah ja bcrypt mit salz natürlich
Das einzige was dir fehlt ist die Quantenverschlüsselung :)
Keine vollständige Antwort, aber "Wenn Sie sich von einem anderen Ort als dem Verlauf anmelden, senden Sie eine SMS / E-Mail an den Benutzer" ist möglicherweise übertrieben. Wenn Sie dies beispielsweise auf Benutzeragenten oder IP-Adressen basieren (beide können sich unerwartet ändern), können Sie den Benutzer mit Spam-E-Mails überlasten. Am besten machen Sie einfach ihre Anmeldung ungültig und zwingen sie, sich erneut anzumelden.
Tut mir leid zu sagen, aber ich denke, diese Frage ist möglicherweise zu thematisch, zu viele Teile für eine einfache Antwort oder zu weit gefasst. So etwas wie Codereview SO ist vielleicht ein besserer Ort ..?
diese gute Idee vielleicht, es dorthin zu bewegen
Die Kette ist so stark wie das schwächste Glied, vergessen Sie das nicht.
Dies ist weniger eine Beschreibung eines Systems als vielmehr eine Liste von Funktionen. Es ist schwer zu sagen, ob eine Liste von Funktionen zu einem sicheren oder zu einem unsicheren System gehört.
"Hash-Passwort wird mit einem privaten Schlüssel verschlüsselt, der in der App / Datei als KONSTANT gespeichert ist" - dies entspricht im Grunde einem Pfeffer. "Login Strike System pro Gerät" - wie werden Sie Geräte unterscheiden? Kann ein Angreifer so tun, als würde er viele verschiedene Geräte verwenden?
Sechs antworten:
#1
+20
Rory Alsop
2011-06-21 16:47:22 UTC
view on stackexchange narkive permalink

Die Schlüsselfaktoren, nach denen ich in einer Projektdefinitionsspezifikation immer suche, fehlen hier:

Was schützen Sie? Vor wem schützen Sie es? Was ist die Auswirkung, wenn es kompromittiert wird?

Wenn Sie Ihre Liste mit Geburtstagen von Freunden schützen, ist dies mit ziemlicher Sicherheit übertrieben. Wenn Sie streng geheimes Material vor internationaler oder Unternehmensspionage schützen, kann dies der Fall sein Seien Sie zu schwach.

Sie müssen über das potenzielle Risiko, die Bedrohungsakteure, die auf Sie abzielen, und andere Faktoren wie die Ausfallsicherheit nachdenken (macht eine fehlgeschlagene Anmeldung an einem Montagmorgen es für a Benutzer erhalten Zugriff, wenn sie es wirklich brauchen)

Hoffentlich haben Sie Antworten auf diese Fragen, aber wenn Sie sie nicht hier veröffentlichen, kann es für andere schwierig sein, Anleitungen zur Sicherheitsarchitektur bereitzustellen.

Nun, * jetzt * sieht dieser letzte Teil unendlich rekursiv aus, denkst du nicht? ;)
@AviD - vielleicht lösche ich den letzten Satz :-)
Es schützt einen Online-E-Commerce-Shop vor. Schutz vor Hackern, Konkurrenten, Phishern und Administratoren, die schwache Passwörter verwenden oder deren Logins kompromittiert sind. Wenn jemand wirklich Zugang haben muss und ausgesperrt ist, lohnt es sich, jemanden anzurufen und aufzuwecken, der etwas dagegen tun kann.
@kzap - basierend auf Ihren Kommentaren würde ich @ThomasPornin's answer: nehmen-)
#2
+14
Thomas Pornin
2011-06-21 18:49:12 UTC
view on stackexchange narkive permalink

Vorsicht vor Overkill, es ist kontraproduktiv. Wenn Ihr Anmeldesystem zu unpraktisch oder ärgerlich ist, werden Benutzer aktiv versuchen, es zu umgehen. "Benutzer" umfasst hier Anwendungsentwickler und Serveradministratoren.

Anmeldeformular ist SSL-gesichert

Dieses Formular ist das wichtigste, aber nicht "allein" ". Theoretisch sollte die gesamte Site mit SSL gesichert werden, nicht nur das Anmeldeformular. SSL bietet Vertraulichkeit in Bezug auf Lauscher. Wenn es jedoch zu einem Cookie kommt, das Sie anschließend löschen, um die Sitzung aufrechtzuerhalten, muss ein Lauscher nur dasselbe Cookie senden, um eine Sitzung zu entführen. Wenn nur das Anmeldeformular SSL-geschützt ist, erhalten Sie hier nur eine Kombination aus einer gründlichen Anti-Phishing-Schulung: Sie erziehen die Benutzer dazu, ihr Passwort nicht an Websites zu senden, die keine haben SSL aktiv, und daher benötigen Sie selbst eine SSL-Site. Aber das ist marginal.

Passwort wird vor der Übertragung in sha256 konvertiert (bcrypt ist für JS / Browser-Client noch zu langsam)

Dieses Passwort ist nutzlos. Dies bedeutet lediglich, dass das SHA-256-Ergebnis das Kennwort ist. Wenn es von einem Angreifer ergriffen werden kann, kann sich der Angreifer damit anmelden, ohne das "wahre" Passwort zu kennen.

Hash-Passwort wird mit einem privaten Schlüssel verschlüsselt, der in der App als CONSTANT gespeichert ist / file

Diese Funktion ist nur dann ein Sicherheitsgewinn, wenn der Angreifer die Hash-Passwörter erhalten kann, nicht jedoch die Anwendungsdateien selbst. Ob dies eine realistische Situation ist, ist umstritten. Auf der anderen Seite ärgert dieser konstante Schlüssel Administratoren, wenn die Anwendung aktualisiert werden soll, und kann zusätzliche Ausfallzeiten verursachen (es ist so leicht, ihn bei der Bereitstellung zu vergessen ...). Dies macht auch die Vertraulichkeit der Anwendungsdateien zu einem wichtigen Ziel, was eher ungewöhnlich ist.

wird beim ersten Anmeldefehler erneut erfasst

Dies ist eher ärgerlich als sicher.

Anmeldesystem pro Gerät. Wenn der Benutzer also 5 verschiedene Anmeldungen versucht und alle falsch sind, ist er aus. Es sind nicht 5 pro Login.

Blockieren Sie keine Konten, sondern fügen Sie nur Verzögerungen hinzu (z. B. eine Minute). Andernfalls kann jeder das Konto von jedem sperren, was ein Problem darstellt. Das Zählen von Versuchen pro Gerät ist gut, aber subtil und kann nach hinten losgehen: Es gibt einige Netzwerke (einschließlich ISP) mit massivem NAT oder Proxy, die aus Serversicht zu Tausenden von Anmeldeanforderungen aus derselben Quelle führen IP.

2-stufige Authentifizierung per SMS, E-Mail? oder AlterEgo - möglicherweise einmal pro Gerät + Standort und zur Verwendung, wenn Sie Ihr Kennwort ändern möchten

Wenn Sie sich von einem anderen Ort als dem Verlauf anmelden, senden Sie eine SMS / E-Mail an den Benutzer

SMS können Benutzer stören: Sie funktionieren nicht gut für internationale Benutzer, sie benötigen ein funktionsfähiges Mobiltelefon vor Ort und einige Personen zahlen eine Gebühr für die SMS, die sie erhalten (dies hängt vom Land und dem Mobilfunkanbieter ab). . E-Mail ist geringfügig besser (aber natürlich nicht , wenn die Anwendung, die Sie schützen möchten, eine Webmail ist ...).

haben die Option, das Anmeldegerät zu speichern + Ort in der Historie (dh verwenden Sie diese Option nicht, wenn Sie sich in einem Netcafe oder einem öffentlichen Netzwerk usw. befinden), sodass Sie immer nach Ihrem 2-stufigen

gefragt werden sinken. Ein Key Logger ist einfach zu unsichtbar. Sie können nicht viel dagegen tun.

Denken Sie also, ich werde übertrieben?

Ja. Noch wichtiger ist jedoch, dass Ihnen auch die wichtige Funktion fehlt, nämlich Site-weites SSL.

Ich werde die SSL-Sitzung nicht außerhalb des sicheren Verzeichnisses bringen. Das Cookie ist nur SSL, sodass die Sitzung in der Nicht-SSL-Umgebung nicht bestehen bleibt
Wenn er das System durch einen Fingerabdruck des Benutzeragenten oder etwas anderes identifiziert, ist er in einer besseren Verfassung als wenn er die Quell-IP verwendet. Sollte aber trotzdem nicht blockieren; und Captchaing nach einem Fehler ist zu viel - eine Online-Brute-Force wird so viel mehr als das brauchen ...
Gut zusammengefasst. Siehe auch den ["endgültigen Leitfaden" unter stackoverflow] (http://stackoverflow.com/a/477578/219187), der diese und einige weitere Themen behandelt.
#3
+5
symcbean
2011-06-21 17:48:43 UTC
view on stackexchange narkive permalink

Sie verwenden hier viele Sicherheits-Schlagworte - aber das Endergebnis ist nicht so sicher wie es sein sollte, und wie Lucanos sagt, gibt es viel Redundanz.

Lesen Sie diesen Thread.

Passwort wird vor der Übertragung in sha256 konvertiert (bcrypt ist für JS / Browser-Client noch zu langsam) bcrypt gespeicherte Hashes

Tut das Bedeutet das, dass Sie einen bcrypt-Hash des sha256-Hash des Passworts generieren? Ohne Salt trägt das sha256-Passwort nicht zur Sicherheit bei, und die Verwendung einer zweiten Hashing-Runde hilft auch nicht.

Das Hash-Passwort wird mit einem privaten Schlüssel verschlüsselt, der in der App / Datei als CONSTANT gespeichert ist

Was? Warum? Möchten Sie jemals den Hash des Hash des Passworts wiederherstellen? Selbst wenn Sie dies tun, besteht die Möglichkeit darin, mit einem öffentlichen Schlüssel zu verschlüsseln.

wird beim ersten Anmeldefehler erneut erfasst.

Fügt kein hinzu viel Wert.

Wenn sich die Geräte- / Standortinformationen während der Anmeldung ändern, beenden Sie die Sitzung

Wir sprechen also sowohl von der Sitzungsverwaltung als auch von der Authentifizierung. In diesem Fall haben Sie noch viel zu tun.

Ich möchte den Hash nicht wirklich wiederherstellen, vielleicht nur, um ihn später noch einmal zu verschlüsseln. Heutzutage werden mit GPUs viele Hashes gebrochen.
Das Speichern mit bcrypt ist viel sicherer als das Speichern eines sha256-Hashs. aber das erste Hashing ist überflüssig, ja. kzap, wenn Sie sich Sorgen um GPUs machen, verwenden Sie scrypt anstelle von bcrypt. Dadurch werden GPUs und FPGAs mit speicherintensiven Funktionen überflüssig.
#4
+4
bethlakshmi
2011-06-21 18:48:11 UTC
view on stackexchange narkive permalink

Es gibt ein paar Dinge, die ich hier nicht verstehe, und wahrscheinlich ein oder zwei Dinge, die es wert sind, hinzugefügt zu werden:

  • Das Hash-Passwort wird mit einem privaten Schlüssel verschlüsselt, der als CONSTANT inapp / file
  • Als "KONSTANTE" - was bedeutet das? Ist es hart codiert? Wie ist es geschützt? Ich stimme anderen Posts zu, dass ein Salt ein guter Plan ist - wenn Sie die Passwörter salzen und hashen, sehe ich keine Notwendigkeit für die Verschlüsselung darüber. Und - wenn der private Schlüssel für Ihre Verschlüsselung in einer flachen Datei gespeichert oder in der App fest codiert ist, haben Sie dort eine Schwachstelle. Empfehlen Sie, einen Weg zu finden, um diesen Schlüssel besser zu schützen.

    • "pro Gerät"

    An einer Reihe von Stellen erwähnen Sie, dass Sie das Verhalten verfolgen "per Gerät "- was bedeutet das? Wie bestimmen Sie, was das Gerät ist? Sie implizieren hier eine Art Geräteauthentifizierung, und nach dem geringen Wissen, das ich über diesen Bereich weiß, sind die meisten Methoden immens fälschbar, und die Methoden, bei denen keine Geräte von einem vertrauenswürdigen Punkt aus ausgestellt werden müssen, können Ihr Betriebsmodell erheblich verändern

    An Stellen, an denen Sie "pro Gerät" sagen, müssen Sie überlegen, was es bedeutet, wenn das Gerät Ihr System vortäuscht. Wenn Sie sich für "IP-Adresse" = "Gerät" entschieden haben, müssen Sie möglicherweise zahlreiche Situationen berücksichtigen, in denen sich die IP-Adresse des Benutzers ohne Verschulden des Benutzers ändert.

    • Anmeldung zulassen Geschichte, die von alten Geräten gesäubert werden soll

    Sind Sie darauf vorbereitet? Das Scrubben eines Cookies ist ziemlich einfach, aber meinst du alle Teile des Gedächtnisses? Wenn ich dieses Versprechen machen würde, würde ich es irgendwie so binden, dass wenn Anmeldeinformationen vom Betriebssystem an einen seltsamen Ort gebracht würden, dies nicht gegen das verstößt, was mein System den Benutzern versprochen hat.

    Ich sehe auch einige Probleme:

    • Wie kann ein Benutzer ein verlorenes / vergessenes Passwort wiederherstellen?

    Ich sehe, dass Sie einen ziemlich komplizierten Prozess für die Kennwortänderung zitieren. Wenn dies ein gelegentliches Web-System ist, würde ich wetten, dass dies Ihre am wenigsten genutzte Funktion ist. Stattdessen entfernen sich Benutzer vom System, kehren nur zurück und benötigen ihre Passwörter und haben sie vollständig vergessen (oder sie haben sie auf eine Haftnotiz auf ihren Bildschirmen geschrieben ... das ist noch schlimmer).

    Sie Sie benötigen eine Möglichkeit zum Wiederherstellen / Zurücksetzen von Passwörtern, die zu Ihrem Hochschutzmodell passt. Ist es von einer Person besetzt? Haben sie Backup-Fragen zu beantworten? Erhalten sie ein Reset-Passwort per E-Mail außerhalb des Bandes? Jeder Wiederherstellungsmechanismus birgt ein Risiko und im Allgemeinen ein geringeres Risiko = höhere Kosten. Beispielsweise ist die ultimative Identitätsprüfung meines Kreditkartenunternehmens für solche Probleme eine schmerzhafte Q&A mit einer lebenden Person über meine Kaufhistorie. Sehr gut, aber teuer in Bezug auf das Gehalt dieser Person.

    • Einfache Möglichkeit für Benutzer, das System zu überprüfen.

    Der vom Server in SSL vorgelegte Berechtigungsnachweis sollte gut genug sein, aber nur sehr wenige Benutzer sind PKI-versiert genug dafür. Ich weiß, dass große Finanzinstitute begonnen haben, Wörter und Bilder zu verwenden, die von den Benutzern ausgewählt wurden und die Benutzer beim Anmelden überprüfen sollen. Das ganze Ziel hier ist es, eine Situation zu vermeiden, in der ein Phisher Ihrem Benutzer eine E-Mail senden könnte, in der er an "paypa1.com" (eine Nummer 1, keine Nummer 1) weitergeleitet wird, und seine Passwörter erhält. Da Sie über Funktionen verfügen, die die Remote-Anmeldung ermöglichen, kann Ihr Angreifer von jedem System aus ein legitimes Benutzerkonto verwenden.

    • Sonstiges Social Engineering

    Diese beiden Probleme sind wahrscheinlich nicht die einzigen menschenorientierten Prozesse, über die Sie nachdenken müssen. Protokollieren Sie Zugriffe? Haben Sie vor, die Anmeldeüberwachung von den Administratorrechten zu trennen? Wie viel Zugriff haben Administratoren und wie ist das System vor ihnen geschützt? Gibt es andere Social-Engineering-Angriffe, die möglicherweise funktionieren?

    Was Sie bisher skizzieren, ist technisch und menschlich - Sie sprechen von einigen Mechanismen, die sich auf die Benutzerfreundlichkeit auswirken können und dazu führen können, dass Benutzer das System nicht verwenden oder dass Benutzer Schritte zum Hacken unternehmen das System, um die Verwendung zu vereinfachen, und ich mache mir Sorgen, dass Sie nicht über die Angriffsmethoden eines Social Engineers nachgedacht haben. Wie Wasser finden Hacker den Riss oder Spalt, der am einfachsten zu verwenden ist.

    Ich treffe Sie hier mit dem schweren Zeug, weil ich der Meinung bin, dass Sie versuchen, etwas High-End für etwas zu entwerfen das ist vermutlich ein hohes risiko. Wenn Sie dies entwerfen möchten, müssen Sie das gesamte System sichern und anzeigen - Ihre Benutzergemeinschaft, die Geburt von Konten, das Verhalten innerhalb des Systems und die Risiken von schlechtem Verhalten.

Entschuldigung, ich habe es nicht klargestellt, es ist eher für eine E-Commerce-Site-Administration und nicht für die breite Öffentlichkeit. Das Zurücksetzen des Passworts würde wahrscheinlich einen Anruf beim Systemadministrator bedeuten und es lohnt sich. Vielen Dank für die Tipps zur Überprüfung des Systems und zum Social Engineering. Ich denke, ein guter 2-Schritt würde Social Engineering verhindern. vor allem, wenn es ein Gerät / Schlüssel / Handy zur Hand ist
Wenn Sie glauben, dass ein tragbares Gerät die Sicherheit verbessern wird, denken Sie noch einmal darüber nach. Die meisten Benutzer aktivieren ihre Smartphones, Pads oder anderen tragbaren Computer mit so vielen Standard- / automatischen Anmeldungen, dass die meisten, wenn nicht alle sekundären Kanäle weit geöffnet sind, wenn das Gerät verloren geht oder gestohlen wird. Wenn dies eine Arbeitssache ist, können Sie sich vorstellen, dass einer der beiden Schritte eine arbeitsbasierte Voicemail ist, die sich in einem Postfachsystem befindet, in dem der Kennwortschutz erzwungen wird.
#5
+3
Lucanos
2011-06-21 08:06:43 UTC
view on stackexchange narkive permalink

Ich werde nur ein paar Fragen stellen, um zu versuchen, 1) mich weiterzubilden und 2) Ihnen eine andere Perspektive auf das System zu geben:

Das Passwort wird vor der Übertragung in sha256 konvertiert (bcrypt ist für JS / Browser-Client immer noch zu langsam)

Wenn Sie zunächst eine SSL-Verbindung verwenden, müssen Sie dies tun? Wie ist das sicherer, selbst wenn jemand das Hash-Passwort abfangen konnte, als das Klartext-Passwort abzufangen? Wenn ich in der Lage war, die Anmeldung zu fälschen und dieselbe Hash-Nutzlast zu senden, wie unterscheidet sich das?

ein Hash aller wichtigen Anmeldedatenbankwerte für diesen Benutzer, damit sie geändert werden Durch Injection stimmt der Hash nicht überein und das Konto wird gesperrt.

Wenn der Benutzer seine E-Mail-Adresse oder sein Passwort aktualisiert, ändert sich der Hash und die Sitzung wird beendet. Oder haben Sie Sicherheitsvorkehrungen getroffen, damit diese legitimen Änderungen behandelt werden können?

Wenn sich die Geräte- / Standortinformationen während der Anmeldung ändern, beenden Sie die Sitzung (um Sitzungsdiebstahl zu verhindern)

Nicht 100% sicher, aber könnte dies bedeuten, dass ein Mobiltelefon aus einer (legitimen) Sitzung ausgeschlossen wird, wenn es von WiFi zu GSM / Cell, GSM / Cell zu WiFi oder möglicherweise innerhalb von GSM / wechselt? Mobilfunknetz (wenn es die vom Gerät angegebene öffentliche IP-Adresse ändert)?

Anmeldesystem pro Gerät. Wenn der Benutzer also 5 verschiedene Anmeldungen versucht und alle falsch sind, ist er aus. Es sind nicht 5 pro Login.

Wie verfolgen Sie "pro Gerät"? Durch die IP-Adresse? Es kann geteilt werden. Durch einen Keks? Es kann gespült werden. Durch eine User-Agent-Zeichenfolge? Es kann auch geändert werden.

Abgesehen davon klingen einige der anderen Ideen gut.

* Das Passwort wird vor der Übertragung in sha256 konvertiert. Ja, es ist nicht sicherer. Ich ziehe es nur dem Senden von Klartext vor, falls ich das Skript jemals auf einer NonSSL-Seite verwende. * Ein Hash aller wichtigen Anmeldedatenbankwerte für diesen Benutzer. Ja Wenn Werte wie Passwort, E-Mail, Handy, 2-Schritt-Geräte-ID geändert werden, wird der Hash mit dem neuen Hash aktualisiert. Vielleicht sollte ich den Hash auch nur zum Spaß verschlüsseln * Login-Strike-System pro Gerät - Ich mag es, pro Gerät mit etwas wie evercookie oder einer Reihe von Dingen wie IP + Useragent + Location zu verfolgen. kombiniere sys Werte und hashe es :)
@kzap "nur zum Spaß" ist ein schrecklicher Grund, Dinge in Sicherheit zu tun, insbesondere für Krypto. Wenn Sie keinen wirklichen Grund dafür haben, werden Sie es wahrscheinlich nur schwächer machen. In diesem Fall hilft das Verschlüsseln des Hash-Passworts nicht viel, da Sie ohnehin über SSL verfügen sollten. Wenn Sie es clientseitig verschlüsseln, bedeutet dies, dass der Schlüssel allen anderen Benutzern zugänglich ist. Um das zu beheben, versuchen Sie vielleicht ... aufhören, tun Sie das nicht, Sie werden nur versuchen, SSL neu zu erfinden. Auf diesem Weg liegen Wahnsinn (und Unsicherheit).
@Avid * notiert ...
#6
+1
kzap
2011-06-25 10:15:16 UTC
view on stackexchange narkive permalink

OK, das habe ich aus den Antworten aller gelernt.

  • Verwenden Sie SSL. Sie müssen die Passwort-Clientseite nicht als sinnlos hashen. SSL ist der richtige Weg, um vor Schnüffeln zu schützen.
  • Verwenden Sie BCrypt (mit Salt), um den Kennwort-Hash zu speichern, SCrypt, wenn ich eine PHP-Implementierung finden kann.
  • Sperren Sie die Anmeldung nicht für fehlgeschlagenes Kennwort, sondern verwenden Sie einfach eine zunehmende Frist, um DOS zu verhindern. Natürlich protokollieren Sie die fehlgeschlagenen Versuche und alarmieren Sie Administratoren, wenn sie ungewöhnlich hoch werden.
  • Das Verschlüsseln und Aufbereiten der Kennwörter ist sinnlos.
  • Überlegen Sie, wie Sie das System überprüfen und Social Engineering verhindern können
  • erzwingt lange und harte Passwörter für Benutzer, wie z. B. passwdqc, um zu überprüfen und Benutzer wissen zu lassen, welche Passwörter von ihnen erwartet werden.
  • Das Sperren aufgrund von Geräte- / Standortänderungen kann auf Mobiltelefonen problematisch sein Bei drahtlosen oder einigen ISPs sollten Sie sich möglicherweise nur von der Sitzung abmelden.
  • Die Sitzungsverwaltung muss ordnungsgemäß implementiert werden.
  • Die Administrationssitzung sollte im SSL-Bereich bleiben.


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...