Ich bin mir nicht sicher, woher du kommst. Zuallererst ist seine Meinung gegen die von NIST definierte Best Practice der Branche. Außerdem liegt Ihr Manager gefährlich falsch. Je mehr Benutzer, desto wahrscheinlicher ist es, dass mehrere Benutzer dieselben Kennwörter erhalten. Auch die folgenden Unternehmen tun dies und ich bin ziemlich davon überzeugt, dass sie eine größere globale Nutzerbasis als Ihre Website haben:

• Facebook
• Gmail
• Linkedin

Ein weiterer Grund, den Sie aus geschäftlicher Sicht erklären können, ist das Risiko von Image- / Markenschäden, wenn Sie negative Werbung erhalten stark>. Um Ihnen ein Beispiel zu geben: Adobe hat eine schlechte Implementierung für die Kennwortspeicherung verwendet, die zu demselben Problem führte, das Sie jetzt haben: Der Wert, der sich aus dem Hashing ergibt (im Fall von Adobe wurde eher Verschlüsselung als Hashing verwendet), war das Kennwort für mehrere gleich Benutzer, wenn sie dasselbe Kennwort verwendet haben (in ihrem Fall, weil sie während der symmetrischen Verschlüsselung keine IV verwenden, dies ist jedoch nicht relevant). Dies verursachte einen massiven Sturm negativer Publizität, schließlich sollte sich ein Internetunternehmen an etwas so Einfaches wie Passwort-Hashing halten, nein? Die finanziellen Kosten, die sich aus einer solchen negativen Publizität ergeben, können erheblich sein.

Abhängig von dem Land, in dem Sie leben, und den geltenden Gesetzen kann das Management heutzutage persönlich zur Rechenschaft gezogen werden , wenn festgestellt wird, dass es beim Schutz von Daten fahrlässig war Datenschutz (wenn geknackte Passwörter verwendet werden, um beispielsweise persönliche Daten von Benutzern abzurufen). Abhängig von der Art der gespeicherten Informationen, Finanzinformationen, medizinischen Informationen und Kreditkarten können unterschiedliche Regeln gelten, die auch zu anderen Arten von Geldbußen führen können.

Dies ist möglicherweise nicht relevant für das direkte Hashing von Passwörtern, kann sich jedoch als nützlich erweisen, wenn Ihr Manager weitere schlechte Entscheidungen trifft. Stellen Sie daher sicher, dass Sie Kopien von E-Mails erstellen, in denen Sie das Problem klar erläutern, und die Antwort Ihres Managers speichern. (nur um Ihren eigenen Arsch zu bedecken)

Die Tatsache, dass Sie keine Salze verwenden, bedeutet wahrscheinlich auch, dass Sie keinen korrekten Hashing-Algorithmus verwenden, da diese häufig für die Erzeugung von Salzen und die Durchführung einer Reihe von Iterationen sorgen . Die drei akzeptierten Algorithmen sind:

• PBKDF2
• bcrypt
• scrypt

Der Hauptzweck von Salzen besteht darin, zu verhindern, dass ein Angreifer Arbeit spart, indem ein einzelner berechneter Hash mit allen gespeicherten Hashes verglichen wird. Dieses Problem ist unabhängig davon, ob die Kennwörter eindeutig sind oder nicht.

Ohne Salze kann der Angreifer einfach seine Liste möglicher Kennwörter durchgehen, den Hash für jedes Kennwort berechnen und dann prüfen, ob das Ergebnis mit einem der Kennwörter übereinstimmt die gespeicherten Hashes. Daher ist nur eine Berechnung pro Vermutung erforderlich.

Bei Salzen muss der Angreifer seine Liste für jeden Benutzer durchgehen, da er die Ergebnisse nicht wiederverwenden kann. Dies zwingt ihn, eine Berechnung pro Vermutung und pro Benutzer durchzuführen. Dies erhöht die Kosten des Angriffs massiv.

Aber wie Lucas bereits sagte, besteht das eigentliche Problem darin, dass Sie keinen geeigneten Algorithmus verwenden. Salze sind nur ein Aspekt des Passwort-Hashing.

Das "beste" Gegenargument hängt davon ab, was Sie erreichen wollen.

Wenn Sie nur wissenschaftlich richtig sein wollen, reicht es zu sagen, dass Salze nicht sind und nie waren. Eine Methode, um mit zwei unterschiedlichen Benutzern umzugehen, die dasselbe Kennwort auswählen. Insbesondere, weil zwei Benutzer, die zufällig dasselbe Kennwort wählen, zunächst kein Problem darstellen und daher nichts zu beheben ist. Salze dienen zur Vermeidung paralleler Angriffe, einschließlich der Verwendung vorberechneter Tabellen. Der Mangel an Salzen war die Hauptsünde von LinkedIn.

Jetzt hat Recht nur Auswirkungen auf Menschen, die bereit sind anzuerkennen, dass sie möglicherweise falsch oder zumindest unvollständig informiert sind. Was Sie von Ihrem Manager zitieren, zeigt in der Regel, dass er in diesem Thema völlig inkompetent ist und auch davon überzeugt ist, dass er es vollständig beherrscht. Wenn Sie diesen Manager davon überzeugen wollen, dass er falsch liegt, dann haben Sie großes Glück. Was die Leute am meisten fürchten, ist zuzugeben, sogar implizit, dass sie etwas Dummes gesagt haben.

Wenn Sie möchten, dass Ihre Organisation tatsächlich zum richtigen Kennwort-Hashing wechselt (lesen Sie dies), können Sie möglicherweise andere Personen überzeugen dass das, was der Manager gerade gesagt hat, reiner Kauderwelsch ist, dass es nicht einmal genug Sinn macht, um tatsächlich falsch zu liegen. Wenn der Manager isoliert wird, kann er die Implementierung eines ordnungsgemäßen Passwort-Hashing ignorieren, ohne dies natürlich jemals zu bestätigen. Auch hier ist das wissenschaftlich korrekte Argument nicht unbedingt das effizienteste. In Nordamerika (insbesondere in von Großbritannien beeinflussten Gebieten wie Neuengland) geht es bei Geschäftstreffen darum, Zusammenstöße zu vermeiden und die Verantwortung zu verwässern. Sie sollten daher einige Ängste, Unsicherheiten und Zweifel verbreiten: Achten Sie darauf, dass Sie Wettbewerber wechseln zu gesalzenen Hashes, und wenn sie dies nicht tun, besteht das Risiko, dass sie Marktanteile verlieren. In Südeuropa sind Treffen rituelle Kämpfe, um Hierarchien zu etablieren. Schreien, knurren, bedrohen und nutzen Sie Sarkasmus, um die Unterstützung der Menge zu gewinnen: Sie gewinnen nicht, indem Sie richtig sind, sondern indem Sie durchsetzungsfähig sind

Eine der effizientesten Arten von Argumenten ist im Allgemeinen die Berufung auf die Autorität. In NIST Special Publication SP800-118 (derzeit im Entwurf) ist Folgendes zu sehen:

Ein weiteres Beispiel für eine Schwäche eines Hash-Algorithmus ist, dass einige Algorithmen kein Salting verwenden.

"Kein Salz" = "Schwäche". NIST sagt das. Wer ist dieser Manager, der glaubt, schlauer als NIST zu sein?

In gewissem Sinne haben Sie das Boot bereits verpasst, wenn Sie über Salz streiten. Der Stand der Technik in Bezug auf die Sicherheit der Kennwortspeicherung geht weit über die Frage "zu salzen oder nicht zu salzen" hinaus und hat sich seitdem dem Zählen von Iterationen zugewandt.

Aber lassen Sie uns Beginnen Sie mit den Grundlagen. Hier ist eine Antwort, die ich vor kurzem geschrieben habe und die überraschend beliebt war. Es erklärt, warum Salz besser ist, und viele Leute haben gesagt, es habe etwas zum Klicken gebracht, wo andere Erklärungen platt fielen. Es ist mehr oder weniger das, was Sie verlangen - zeigen Sie es Ihrem Chef, wenn Sie glauben, dass es etwas Gutes bringt:

Warum sind gesalzene Hashes sicherer?

Aber der wichtige Punkt dort ist der letzte, der dort gemacht wurde. Das heißt, das Speichern eines gesalzenen SHA1-Hashs und das Nennen als gut wird nicht länger als verantwortlich angesehen. Die Rechenleistung hat den Punkt erreicht, an dem Milliarden von Hashes pro Sekunde nicht mehr theoretisch sind. So können Sie den gesamten 32-Bit-Bereich eines Brute-Force-Angriffs schneller durchblasen als nötig, um zu erklären, was Sie tun.

Jetzt liegt der Fokus darauf, den Angreifer zu zwingen, das Problem tausende oder hunderttausende Male zu lösen, nur um eine Vermutung anzustellen. Dort taucht PBKDF2 auf (in Anzug und Krawatte von NIST) sowie scrypt und Freunde (die ungepflegt, aber mächtig aussehen).

Welchen Algorithmus Sie wählen, ist nicht wirklich der Schlüssel. Sie alle lösen ungefähr das gleiche Problem, nur auf unterschiedliche Weise mit unterschiedlichen Schwerpunkten. Sie müssen jedoch etwas verwenden - einen Algorithmus, der es schwierig macht, auch nur ein einziges Passwort brutal zu erzwingen. Der Grund ist einfach: Es ist der Industriestandard, messbar und nachweislich sicherer und es entstehen keine nennenswerten Kosten für die Verwendung. Wenn Sie diese Faktoren zusammenfassen, wird schnell klar, dass Sie im Falle eines Verstoßes als fahrlässig angesehen werden können, wenn Sie dies nicht tun.

Das beste Argument ist, eine Liste der am häufigsten verwendeten Passwörter herauszuholen und zu zeigen, dass etwa 1% Ihrer Benutzer "123456" auswählen. Am zweitbesten wäre es, eine Kennwortleckanalyse für eine große Site durchzuführen und zu zeigen, dass nur etwa die Hälfte Ihrer Benutzer ein eindeutiges Kennwort erstellen kann.

Sie sollten zwei Punkte hervorheben:

• Die Verwendung eines Salt reduziert den Wert einer gestohlenen Datei, die Hash-Passwörter enthält. Dies gilt unabhängig davon, welche Sprache (n) von den Benutzern des Systems gesprochen wird (werden), da ein Angreifer, der eine Regenbogentabelle für Ihren Hashing-Algorithmus hat, damit das Hash-Passwort umkehren kann, unabhängig von der Muttersprache der Person, die dies gewählt hat Passwort.

• Die Verwendung eines Salzes ist fast kostenlos. Sie erhalten fast nichts, um es auszuschließen, und selbst nach der aktuellen Einschätzung Ihres Managers ist es nur "wahrscheinlich", dass es kein ernstes Sicherheitsproblem verursacht. Verwenden Sie es daher.

Es gibt einen Einwand, den Ihr Manager möglicherweise gegen den ersten Punkt erhebt, aber ich hoffe nicht: "Wir verwenden also unseren eigenen benutzerdefinierten Hashing-Algorithmus Es besteht keine Gefahr, dass ein Regenbogentisch dafür existiert. " In diesem Fall müssen Sie auch die Verwendung eines Standard-Passwort-Hashing-Algorithmus begründen.

Ich finde auch:

[die Benutzer ] haben alle unterschiedliche Muttersprachen

, um eine bizarre Annahme über ein System zu sein. Wenn Sie sich bei Ihrer Sicherheitsanalyse auf eine Annahme verlassen, wird Ihr System unsicher (oder jedenfalls nicht auf Sicherheit geprüft), sobald die Annahme gebrochen wird. Nachdem Sie sich aus Sicherheitsgründen auf diese Annahme verlassen haben, müssen Sie sicherstellen, dass keine zwei Benutzer des Produkts dieselbe Muttersprache haben. Warum um alles in der Welt sollte jemand sein System auf diese Weise einschränken wollen, und insbesondere, wie wird die Durchsetzung dieser Beschränkung einfacher sein als die Verwendung eines Salzes?

In diesem Fall führt diese Annahme jedoch nicht einmal dazu zu dem Schluss, dass Ihr Manager Salz für unnötig hält (aus dem oben genannten Grund). Die Frage, ob die Annahme beibehalten werden kann, ist angesichts der Tatsache, dass sie nicht hilft, ziemlich irrelevant!

Schließlich gibt es einen bestimmten Grund, warum mein erster Punkt oben der Analyse Ihres Managers widerspricht:

verwendet wahrscheinlich nicht dasselbe Passwort

ist eine fehlerhafte Analyse der Schwachstelle, die Salt behebt. Für den Angreifer spielt es keine Rolle, ob zwei Benutzer des Systems dasselbe Kennwort haben oder nicht, es sei denn, der Angreifer ist zufällig einer dieser beiden Benutzer und kennt daher das Kennwort, das sie gemeinsam nutzen. Salze verteidigen nicht nur gegen diesen Angriff, sondern auch gegen Regenbogentischangriffe. Selbst wenn dieser ungewöhnliche Angriff eines Ihrer Benutzer mit demselben Kennwort auf Ihrem System nicht möglich wäre, würden Sie dennoch Salze benötigen.

Ich denke, dies ist eher ein Menschenproblem als ein technisches Problem. Daher müssen Sie eher mit Soft Skills als mit technischen Erklärungen antworten. Wenn Ihr Manager positiv auf technische Erklärungen reagiert, wählen Sie vorher eine der Antworten aus.

Wenn Sie sich für Soft Skills entscheiden möchten, können Sie einige Dinge ausprobieren:

• Das Wichtigste, an das Sie sich erinnern sollten: Ihr Chef ist Ihr Chef. Sei nicht böse auf ihn, sonst wirst du Pech haben.
• Versuchen Sie, ihm keine Fragen zu stellen, die er nicht beantworten kann. Stellen Sie stattdessen indirekte Fragen in Form einfacher Sätze.
• Versuchen Sie, seinen Standpunkt und seine Argumente zu verstehen.
• Wenden Sie Paraphrasierung an.
• Lachen Sie niemals.
• Sei niemals unhöflich.
• Lies Dale Carnegies Buch "Wie man Freunde gewinnt und Menschen beeinflusst".

Ein Beispieldialog könnte so aussehen (sei dir bewusst, dass ich ' Ich bin kein englischer Muttersprachler):

Chef: "Wir brauchen keine Salze."
Sie: "Wir brauchen diesen zusätzlichen Schutz nicht."
Boss: "Ja, unsere Benutzer verwenden nicht dasselbe Passwort."
Sie: "Starkes Passwort ist bereits sicher."
Boss: "Das stimmt."
Sie: "Okay, ich verstehe. Unsere Benutzer machen das Passwort sicher und wir leben einfach ohne Salz."
Boss: "Ja, vielleicht nicht alle Benutzer ..."
Sie: smile

Oder so:

Boss: "Wir brauchen keine Salze."
Sie: "Der Nutzen der Verwendung von Salzen ist die Mühe nicht wert."
Boss: "Das ist richtig."
Sie: "Also löschen wir das Salz aus der Aufgabenliste und fahren mit dem Rest fort."
Boss: "Richtig, wir sind bereits hinter dem Zeitplan zurück."
Sie: "Wenn wir den Zeitplan auf andere Weise einhalten würden, könnten wir das Salz umsetzen."
Boss: "Nein, ich verstehe dieses Salzkonzept nicht."
Sie: "Dieses kryptografische Zeug ist immer schwer zu verstehen."
Boss: "Selbst als ich einen Artikel las, bekam ich keine Ahnung."
Sie: "Was Sie denken lässt, dass es eine Menge Aufwand ist."
Boss: "Ja, wir werden ungefähr zwei Tage verlieren."
Sie: "Mit Hilfe eines Frameworks kann ich es in 2 Stunden tun."
Boss: "Wirklich?"
Sie: smile

Beachten Sie, dass es überhaupt keine Fragezeichen gibt. Der Chef steht nie unter dem Druck, Fragen zu beantworten, auf die er möglicherweise keine Antwort kennt.

Leider ist es ziemlich schwierig, solche Techniken anzuwenden, wenn Sie dies noch nie zuvor getan haben.

Wenn dieser Ansatz funktioniert auch nicht gut, es gibt noch eine Option:

Implementieren Sie sie einfach. Es sollte nicht zu viel Aufwand sein und Ihr Chef wird es wahrscheinlich nicht bemerken, außer er führt eine Codeüberprüfung durch oder schaut sich Datenbanktabellen an.

Wirf einfach ein paar Hashs (vielleicht sein eigenes Passwort) in Google. Höchstwahrscheinlich wird das Passwort zurückgegeben. Sein schwaches Hashing ist wie gar kein Hashing.

https://www.google.de/search?q=a94a8fe5ccb19ba61c4c0873d391e987982fbbd3

Wenn dies nicht der Fall ist überzeugen Sie ihn, einen neuen Job zu suchen ...