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.

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.

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.

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.

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.

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.