Zitate für die Unkenntnis eines weltweit eindeutigen Passworts

Ich bin mit jemandem (einem Kunden) nicht einverstanden, was die Benutzeridentifizierung / -authentifizierung für ein System angeht. Das Wichtigste dabei ist, dass jeder Benutzer ein global eindeutiges Kennwort haben soll (dh, dass nicht zwei Benutzer dasselbe Kennwort haben dürfen). Ich habe alle offensichtlichen Argumente dagegen aus dem Weg geräumt (es ist eine Sicherheitslücke, es verwechselt Identifikation mit Authentifizierung, es ist sinnlos usw.), aber sie bestehen darauf, dass an diesem Ansatz nichts falsch ist.

Ich habe verschiedene Google-Suchen durchgeführt, um nach maßgeblichen (oder halb maßgeblichen oder sogar nur unabhängigen) Meinungen zu suchen, kann aber keine finden (hauptsächlich ist es nur ein so offensichtlicher Fauxpas, dass es sich nicht lohnt, davor gewarnt zu werden, wie soweit ich das beurteilen kann). Kann mich bitte jemand auf eine solche unabhängige Meinung hinweisen?

[EDIT]
Vielen Dank für all Ihre Antworten, aber ich verstehe bereits die Probleme mit diesem vorgeschlagenen Ansatz / dieser Anforderung und kann sie dem Kunden sogar erklären, aber der Kunde akzeptiert sie nicht, daher meine Bitte um unabhängige und / oder maßgebliche Quellen .

Ich habe auch den Daily WTF-Artikel gefunden, aber er leidet unter dem Problem, auf das Jon Hopkins hingewiesen hat - dass dies ein so selbstverständlicher WTF ist, dass es scheinbar nicht wert ist, erklärt zu werden, warum .

Und ja, die Passwörter werden gesalzen und gehasht. In diesem Fall könnte es schwierig sein, eine globale Einzigartigkeit zu gewährleisten, aber das löst mein Problem nicht. Es bedeutet lediglich, dass ich eine Anforderung habe, an die sich der Kunde nicht rühren kann. Dies ist nicht nur schlecht beraten, sondern auch schwierig implementieren. Und wenn ich in der Lage wäre zu sagen, dass ich mich nicht auf Salting und Hashing beschränke, dann wäre ich in der Lage zu sagen, dass ich keine global eindeutigen Passwörter implementiere.

Hinweise auf unabhängige und / oder maßgebliche Quellen, warum dies eine schlechte Idee ist, werden immer noch dankbar entgegengenommen ...
[/ EDIT]

Wenn ein Client versucht, ein bereits vorhandenes Kennwort zu erstellen, erhält er die Rückmeldung, dass ein Benutzer dieses Kennwort bereits verwendet, was normalerweise eine Verletzung der Datenschutzvereinbarung darstellt.

Darüber hinaus sind Benutzernamen viel einfacher zu erraten (und wenn es ein Forum gibt, können Sie dort nur eine Menge Benutzernamen finden), und Sie weisen die Benutzer darauf hin, wie sie die Website hacken können.

Irgendwo im Internet sollte es eine Seite geben, die den Teil der Verletzung der Datenschutzbestimmungen beschreibt, ansonsten ist es nur normal: Sie würden im Grunde genommen jemandem einen Schlüssel und eine Liste von Privatadressen geben.

BEARBEITEN: Nicht in der Nähe von Autor, aber vielleicht hilfreich, nachdem Sie erklärt haben, was WTF bedeutet: http://thedailywtf.com/Articles/Really_Unique_Passwords.aspx

Best Practice steht der Erfüllung der Anforderung im Wege:

Sie können dies nicht tun, weil Sie die Kennwörter nicht kennen und sie daher nicht vergleichen können, da Sie nur den Hash des Kennworts und ein Salt (das Sie neben dem gehashten Kennwort speichern können) speichern. Dies ist eine bewährte Methode, und genau das tun Sie. Getan.

Ein anderer Schnitt: Doh! Im Nachhinein ist es einfach - Sie könnten immer noch die Eindeutigkeit überprüfen, da Sie (natürlich) das Salz haben. Erschießen Sie mich jetzt. Natürlich müssen Sie dem Kunden dieses Detail nicht erwähnen.

FWIW, es ist nicht ganz so dumm, wie Sie denken - das Ziel ist es, zu verhindern, dass Gruppen von Benutzern dasselbe Passwort vereinbaren und teilen, was die Leute in der Überzeugung tun , dass es ihr Leben leichter machen wird.

Wird angewendet mit der Anforderung, das Passwort regelmäßig zu ändern, und einer Einschränkung, die verhindert, dass Personen ein aktuelles oder zuvor verwendetes Passwort (überhaupt) und vernünftige Anforderungen an die "Stärke" (oder zumindest ein vorinstalliertes Wörterbuch von "gesperrt") erneut verwenden "Passwörter") Sie werden ziemlich schnell zu einem Punkt kommen, an dem die Chancen sowieso nicht für den Hacker sprechen.

Ok, meine Antwort begann ursprünglich mit:

Mit ein paar Vorbehalten kann man eigentlich nichts falsch machen - die meisten davon sind, dass ich dick bin ...

Anscheinend unangemessener Humor - Punkt war, dass wenn Sie nicht die weltweit einzigartige Einschränkung haben, Sie verschiedene Gelegenheiten schaffen, vielleicht weniger gefährlich - ich weiß es nicht.

Durch das Erzwingen unwiederholbarer Kennwörter gehen Informationen verloren

Wie? Da jedes Mal, wenn ein Cracker versucht, einen neuen Benutzer mit einem einfachen Passwort zu erstellen, antwortet Ihr System mit "Nein, kann dieses Passwort nicht haben", sagt der Cracker "Goody, das ist eines für die Liste".

Es ist im Allgemeinen eine schlechte Sache, Informationen über Ihre Sicherheit zu verlieren. OK, Dritte, die wissen, dass der Algorithmus in Ordnung ist (Peer Review ist erforderlich), einem dedizierten Cracker jedoch erlauben, Schlüssel abzuleiten - schlecht, wirklich, wirklich schlecht.

Ressourcen, die Richtlinien für die Verwaltung von guten und schlechten Passwörtern beschreiben

In diesem Artikel des Sicherheitsexperten Bruce Schneier erfahren Sie mehr über die Kennwortsicherheit.

Lesen Sie dieses PDF von den Sicherheitsforschern Philip Inglesant & M. Angela Sasse, um eine eingehende Diskussion über "Die wahren Kosten nicht verwendbarer Kennwortrichtlinien" zu erhalten. Um aus dem Fazit zu zitieren:

Gegen die Weltanschauung, dass „wenn nur [Benutzer] die Gefahren verstanden, würden sie sich anders verhalten“ [12], argumentieren wir, dass „wenn nur Sicherheitsmanager die wahren Kosten für Benutzer und Organisation verstehen würden, würden sie Richtlinien anders festlegen“.

Falsches Sicherheitsgefühl

Der Client meldet sich daher mit der Frage: "Wenn niemand dasselbe Passwort hat, ist nur eine Person betroffen, wenn einer geknackt ist." Nein. Jeder ist betroffen, weil der Cracker nachgewiesen hat, dass Ihr Kennwortsystem grundlegend fehlerhaft ist: Es ist anfällig für einen Wörterbuchangriff in einem Online-System. Es hätte für einen Cracker nicht möglich sein dürfen, mehrere Versuche zu unternehmen, ein Passwort zu erraten.

Für den Online-Zugriff reichen 6 Zeichen

Ich ging vom Thema ab, aber ich dachte, es wäre für interessierte Leser erwähnenswert. In Bezug auf die Sicherheit ist ein Online-System eines, das über ein aktives Sicherheitsmanagement verfügt, das den Zugriff auf die Daten überwacht und steuert. Bei einem Offline-System ist dies nicht der Fall (z. B. wenn Daten auf einer gestohlenen Festplatte verschlüsselt wurden).

Wenn Sie ein Kennwortsystem haben, das online ist, benötigen Sie keine Kennwörter mit hoher Sicherheit. Die Passwörter müssen nur so komplex sein, dass das Erraten innerhalb von 20 Versuchen verhindert wird (ein einfacher Angriff mit dem Namen "Ehepartner / Kind / Haustier" schlägt fehl). Betrachten Sie den folgenden Algorithmus:

1. Cracker errät das Kennwort mit dem Ansatz "Root plus Suffix", um Vermutungen zu minimieren
2. Anmeldeinformationen abgelehnt und weitere Anmeldeversuche für N * 10 Sekunden verhindert
3. Wenn N> 20, Konto sperren und Administrator informieren
4. N = N + 1
5. Benutzer informieren, dass die nächste Anmeldung zum Zeitpunkt T erfolgen kann (oben berechnet)
6. Springe zu Schritt 1

Bei einem einfachen 6-stelligen Passwort verhindert der obige Algorithmus Wörterbuchangriffe und ermöglicht es sogar dem unfähigsten Benutzer auf einer mobilen Tastatur, irgendwann durchzukommen. Nichts wird den sogenannten "Gummischlauch-Angriff" verhindern, bei dem Sie den Inhaber des Passworts mit einem Gummischlauch schlagen, bis er es Ihnen sagt.

Für ein Offline-System, bei dem verschlüsselte Daten auf einem Flash-Laufwerk herumliegen und es dem Cracker freigestellt ist, irgendetwas dagegen zu versuchen, ist der stabilste Schlüssel gefragt, den Sie finden können. Aber das Problem ist bereits gelöst .

Wenn Sie sie von dieser Vorgehensweise abgeraten und begründet haben, würde ich sie beim Wort nehmen und das System nur so implementieren, wie sie es vorschlagen. Es mag nicht befriedigend sein, aber Sie haben Ihren Job gemacht, und sie zahlen die Rechnung, also sollten sie bekommen, was sie wollen.

Es gibt eine Ausnahme. Wenn die negativen Konsequenzen einer Systemverletzung schwerwiegend sind (z. B. wenn sehr private Informationen durch eine Sicherheitsverletzung gefährdet werden), müssen Sie möglicherweise professionell das gewünschte System nicht implementieren. Erwarten Sie nicht, dass es Sie populär macht, wenn Sie sich weigern, aber lassen Sie sich nicht davon leiten.

Ich möchte nur Murphs Antwort bekräftigen. Ja, es ist ein Sicherheitsproblem und es gibt Schwachstellen in Bezug auf die Offenlegung von Informationen bei der Implementierung. Aber aus Sicht des Kunden scheint er sich darüber keine allzu großen Sorgen zu machen.

Was Sie beachten sollten, ist, dass es physikalisch unmöglich ist , eine "eindeutige Passwort" -Prüfung durchzuführen. Wenn Sie ein Salting- und Hashing-Kennwort verwenden und es nicht als Klartext speichern, müssen Sie die Eindeutigkeitsprüfung nur mit O (n) (teuren) Vorgängen durchführen.

Können Sie sich vorstellen, dass Sie 10.000 Benutzer haben und es 30 Sekunden dauert, bis jedes Benutzerpasswort auf Eindeutigkeit überprüft wird, wenn sich jemand neu anmeldet oder sein Passwort ändert?

Ich denke, das ist die Antwort, die Sie Ihrem Kunden geben müssen.

Der Abschnitt zur IT-Sicherheit von Stack Exchange ist ein nützlicher Punkt für Sie, wenn Sie nur über den richtigen Ort nachdenken, um die Frage zu stellen. Versuchen Sie es mit /security/tagged/passwords - eine Reihe von Personen, die sich mit IT-Sicherheit befassen, sollten in der Lage sein, spezifische Antworten zu geben.

Er würde wahrscheinlich RSA-Zwei-Faktor-Verschlüsselung mögen. Wenn Sie Active Directory oder eine ASP.NET-Mitgliedschaft verwenden, ist dies ein Kinderspiel.

Das Hardware- oder Software-Token generiert ein zeitabhängiges eindeutiges Kennwort, auf das ein PIN-Code folgt. Zusammen ergibt dies ein eindeutiges Passwort für jeden Benutzer.