it-swarm.com.de

Gibt es einen Grund, warum ich die HaveIBeenPwned-API nicht verwenden sollte, um Benutzer vor offengelegten Kennwörtern zu warnen?

Es wird viel über den HaveIBeenPwned-Passwortprüfer gesprochen, der Benutzern sicher mitteilen kann, ob ihr Passwort in einem ihrer bekannten Datendumps von Passwörtern angezeigt wird.

Dieses Tool hat eine öffentlich verfügbare API dahinter, welche Websites/Apps/etc kostenlos verwendet werden können, damit ihre Benutzer ihre Passwörter überprüfen können, aber soweit ich sehen kann alle aufgelisteten Anwendungen sind speziell Tools zur E-Mail-/Passwortprüfung.

Ich habe noch nie einen Benutzer gesehen oder gehört, der beim Erstellen eines Kontos ein Passwort in eine Website eingegeben hat. Anschließend wird eine Fehlermeldung angezeigt, in der angegeben wird, dass das von ihm gewählte Passwort in einem bekannten Datenverstoß gefunden wurde.

Wenn ich eine Website erstellen würde, wäre es eine schlechte Idee, die Passwörter meiner Benutzer als zusätzliche Sicherheitsmaßnahme automatisch mit dem Tool von HaveIBeenPwned zu vergleichen und von ihnen zu verlangen, ein Passwort auszuwählen, von dem die Website nichts weiß?

62
Toby Smith

Die neuesten Empfehlungen des NIST (SP 800-63b, Abschnitt 5.1.1.2; siehe hier oder hier für eine Zusammenfassung ) schlagen tatsächlich vor, Benutzerkennwörter anhand von Listen bekannter kompromittierter Kennwörter zu überprüfen Genau das zu tun entspricht den aktuellen Best Practices. Es ist auch viel besser, als Passwörter zu verlangen, um bestimmte "Regeln" zu erfüllen (gegen die das NIST jetzt empfiehlt). HIBP ist nur eine Möglichkeit (und wahrscheinlich die einfachste), dies in der Praxis zu tun. Es müssen nur die ersten 5 Buchstaben des Hash des Passworts gesendet werden, sodass das tatsächliche Risiko für Benutzer praktisch Null ist. Also ja, bitte zögern Sie nicht, dies zu tun, wenn Sie dies wünschen.

Ich bin mir sicher, dass eine bestimmte Organisation dies möglicherweise nicht tut, was von Standort zu Standort sehr unterschiedlich ist, aber ich denke, es ist sicher, dass es sich um die üblichen Verdächtigen handelt:

  1. Sicherheit ist ein Bereich, in dem viele gerne sparen, und die Implementierung eines solchen Systems erfordert zusätzliche Anstrengungen.
  2. Es braucht Zeit, bis neue Best Practices für Institutionen allgemein bekannt werden
  3. Es dauert noch länger, bis sich die Institutionen mit Best Practices vertraut gemacht haben
  4. Jede entwickelte Funktion hat Kosten: Geld in Bezug auf Entwicklungszeit für Entwicklung und Wartung, verlorene Benutzer, die die Regel nicht verstehen oder befolgen möchten ( h/t @Woohoojin ) usw. Organisationen möglicherweise nicht Betrachten Sie die zusätzlichen Vorteile als die Kosten wert.

Um fair zu sein, tut dies noch keines meiner Systeme. Sie können mich also zu # 3 oder # 4 hinzufügen.

Punkt 4 ist etwas erwähnenswerter. Die Kosten für die Implementierung liegen auf der Hand: Entwickler benötigen Zeit, um Funktionen zu erstellen und zu warten. Die Vorteile sind viel schwerer zu quantifizieren. Natürlich machen viele Unternehmen bei Sicherheitsfragen den Fehler, dass die Vorteile gleich Null sind, und sparen daher an Sicherheit (siehe Punkt 1). Dies ist jedoch ein Merkmal, bei dem die Vorteile wahrscheinlich gering sind. Es gibt oft echte Kosten für ein Unternehmen im Zusammenhang mit der Kompromittierung von Benutzerkonten (mehr Kundenunterstützung, möglicherweise Rollback von Transaktionen usw.), aber solange die Kompromittierung auf den eigenen Fehlern des Benutzers beruht (in diesem Fall von Bei der Auswahl kompromittierter Passwörter ist es unwahrscheinlich, dass ein Unternehmen direkt haftet, und es werden daher wahrscheinlich größere Kosten vermieden. Daher lohnt es sich möglicherweise nicht für alle Unternehmen, solche Funktionen zu implementieren. Es liegt immer an jedem Unternehmen, die potenziellen Kosten und Vorteile für sich selbst abzuwägen.

73
Conor Mancone

Weil die Kosten dafür nicht trivial sind:

  • leute, die nicht verstehen, wie HIBP funktioniert, gehen davon aus, dass Sie mit den Passwörtern nicht richtig umgehen ( Beispiel ), und Sie müssen sich mit Beschwerden und fehlgeleiteter Kritik auseinandersetzen.
  • sie müssen den Code regelmäßig aktualisieren, wenn sich die HIBP-API ändert, oder der Dienst wird heruntergefahren und Sie müssen auf einen neuen migrieren.
  • verlangsamungen oder Ausfallzeiten bei HIBP bedeuten, dass Ihre eigene Site langsamer wird. Vor allem, wenn Sie vorhandene Passwörter weiterhin auf neue Verstöße überprüfen möchten.

Zu einem späteren Zeitpunkt wird eine solche Funktion wahrscheinlich von einer Website erwartet, die behauptet, die Sicherheit ernst zu nehmen. Dann wird es von allen implementiert, da die oben genannten Kosten durch den Vorteil einer sicheren Website aufgewogen werden.

Und ja, es gibt sind Unternehmen, die den HIBP-Check bereits implementiert haben.

14

Sie haben kein Country-Tag eingefügt, das beeinflussen kann, was Sie tun können oder nicht. Sie scheinen jedoch aus Großbritannien zu kommen - was in Bezug auf die folgenden Punkte anscheinend entspannter ist.
Außerdem scheinen Sie die Überprüfung zum Zeitpunkt der Anmeldung durchführen zu wollen - das würde meine Kommentare unten weniger nützlich machen.

Am Beispiel Frankreichs oder Deutschlands müssen Sie besonders vorsichtig sein, wenn Sie eine Lösung präsentieren, die die Aktivitäten der Benutzer verfolgt. Sie können die besten Absichten der Welt haben, es gibt einige Leute, die nicht schätzen werden.

Insbesondere wenn Sie Lecks gegen die Benutzer prüfen professionelle E-Mail, geht es Ihnen gut (ich gehe davon aus, dass Sie in der Informationssicherheit für dieses Unternehmen arbeiten). Sie sind verpflichtet, die Interessen Ihres Unternehmens zu schützen. Wenn also eine professionelle E-Mail (und möglicherweise das zugehörige Passwort) missbraucht wird, sind Sie im grünen Bereich.

Seien Sie vorsichtig, wenn Sie diese Prüfung auf nicht professionelle Aktivitäten ausweiten. Vielleicht möchten Sie Leuten vorschlagen, ihre persönlichen E-Mails gegen HIBP zu überprüfen, aber das ist alles.

YMMV - Dies ist eine einvernehmliche Position, die ich nach zig Diskussionen mit Experten für Recht, Datenschutz und Arbeitsrecht eingenommen habe. Jeder von ihnen hatte seine eigene Meinung zu diesem Thema, also trete ich leicht.

4
WoJ