Warum sollten Passwörter verschlüsselt werden, wenn sie in einer sicheren Datenbank gespeichert werden?

78

Ich habe einen Webservice. Im Moment habe ich Passwörter im Klartext in einer MySQL- Tabelle auf meinem Server gespeichert . Ich weiß, dass dies nicht die beste Vorgehensweise ist, und deshalb arbeite ich daran.

Warum sollten Passwörter verschlüsselt werden, wenn sie in einer sicheren Datenbank gespeichert werden? Mir ist klar, dass jemand, der sich in meine Datenbank einhackt, das Passwort aller erhält. Aber ich habe andere Probleme, wenn jemand in meine Datenbank gelangt, zum Beispiel das Löschen von Daten.

Das Szenario, an das ich denken kann, ist, dass Sie gehackt werden. Sie haben vor ein paar Stunden eine Datenbank wiederhergestellt und alles ist in Ordnung. Wenn es sich bei Ihren Passwörtern jedoch um Klartext handelt ... Der Dieb hat alle Passwörter und Sie müssen sie alle zurücksetzen. Ärger mit Ihren Benutzern.

Wenn die Passwörter verschlüsselt wären, könnten Sie einfach die vorherige Datenbank wiederherstellen. Ist das richtig gedacht?

phpmysqlguy
quelle
124
Ich würde noch einen Schritt weiter gehen. Es reicht nicht aus, es zu verschlüsseln. Du würdest es haschen wollen. Auf diese Weise sollten nicht einmal Sie in der Lage sein, die Klartext-Passwörter Ihrer Benutzer zu kennen.
Santa
67
@ Santa Das Hashing des Passworts ist nicht genug. Sie müssen etwas Salz hinzufügen, um das Rezept gut genug zu machen ...
Bakuriu
16
Bitte werfen Sie einen Blick auf diesen relevanten Security.StackExchange-Beitrag: Wie werden Passwörter sicher gehasht?
Adi
10
Verärgerter DBA sagt ... wähle * vom Benutzer aus und verkaufe dann diese Liste für die Abfindung. Nichts ist jemals sicher.
Jon Raynor
auch security.blogoverflow.com/2011/11/…
David J. Liszewski

Antworten:

194

Zunächst sollten Sie mit Leserechten freier sein als mit Lese- und Schreibrechten. Möglicherweise hat ein Hacker Zugriff auf Ihre Daten, kann diese jedoch nicht bearbeiten.

Aber viel wichtiger ist, dass es nicht um Sie geht. Die Tatsache, dass Sie möglicherweise durcheinander sind, wenn jemand vollen Zugriff auf Ihre Datenbank hat, spielt keine Rolle. Viel wichtiger sind die Daten Ihres Benutzers.

Wenn Sie Ihre Datenbank wiederherstellen, hat der Hacker weiterhin Zugriff auf das Konto Ihres Benutzers.

Und wer weiß was noch? Was ist, wenn sie bei Google dasselbe Passwort verwenden? Oder PayPal? Was ist, wenn ein Hacker dadurch Zugriff auf den Mädchennamen seiner Mutter oder die letzten 4 Ziffern seiner Kreditkarte erhält?

Was ist, wenn das sie auf andere Konten bringt? Überholen Sie nicht einen Hacker, um ein Benutzersupport-System zu durchlaufen und weitere Informationen zu erhalten .

Einfach ... einfach nicht. Dies sind die privaten Informationen Ihres Benutzers, und Sie müssen diese nicht sehen können. Es ist auch dein Ruf. Verschlüssle es.

BEARBEITEN: Ein zusätzlicher Kommentar, um jedem zukünftigen Leser das Lesen jeder Antwort und jedes Kommentars zu ersparen ...

Wenn Sie (im strengsten Sinne) verschlüsseln möchten, müssen Sie ein öffentliches / privates Schlüsselpaar verwenden. Dies ist in Ordnung, erschwert jedoch sowohl Ihnen als auch Ihrem Benutzer das Leben ein wenig.

Eine einfachere und ebenso effektive Lösung besteht darin, das Passwort zufällig zu salzen und zu haschen . Hashing allein reicht nicht aus; Wenn Ihr Benutzer ein gemeinsames Kennwort verwendet, wird es in Reverse-Hashing-Tabellen angezeigt, die bei einer einfachen Internetsuche leicht verfügbar sind.

pdr
quelle
89
Oder besser, hash es!
Blorgbeard
29
Diese. Msgstr "Ich habe andere Probleme, wenn jemand in meine Datenbank kommt". Es ist Ihre Datenbank, Sie erwarten Probleme, wenn es gehackt wird. Durch das Speichern von Klartextkennwörtern haben alle Benutzer jedoch möglicherweise Probleme mit allen anderen Konten. Wie viele Personen verwenden Ihrer Meinung nach auf jeder einzelnen Website ein anderes Passwort?
Carson63000
13
Bitte folge dem Rat von Blorgbeard, lies das vielleicht . Das Verschlüsseln von Passwörtern bietet keinen Schutz, wenn Ihr Webserver kompromittiert wurde. Der Schlüssel zum Entschlüsseln der Passwörter muss auf dem Server gespeichert sein. Das Hashing der Passwörter bedeutet, dass selbst für den Fall, dass jemand uneingeschränkten Zugriff auf das Gerät hat, die Passwörter nicht einfach wiederhergestellt werden können.
Aufschnitt
7
Warum müssten Sie jemals Passwörter verschlüsseln, wenn dies für Ihr System keinen Wert darstellt? Zu welchem ​​Zeitpunkt müssen Sie Passwörter entschlüsseln, außer zum Vergleich? @pdr, Sie sollten dem OP nicht sagen, dass er verschlüsseln soll, Sie sollten ihm sagen, dass er salzen und haschen soll.
NobleUplift
4
Sie möchten auch die Antworten auf die Fragen zur Kennwortwiederherstellung kreuzen. Ansonsten können diese verwendet werden, um auch auf andere Websites zuzugreifen, genau wie Passwörter.
Zan Lynx
64

Wenn Sie gehackt werden, können Sie die Site von Backups wiederherstellen und reparieren. Aber der Hacker hat immer noch Passwörter für alle Konten! Es gibt dokumentierte Beispiele aus der Praxis (Sony, Linked-In), bei denen das schnelle Sichern und Wiederherstellen des Dienstes viel einfacher gewesen wäre, wenn die Kennworttabellen ordnungsgemäß gehasht und gesalzt worden wären.

Es ist wahrscheinlich eine gute Idee, vorausgesetzt , dass Sie wird gehackt werden, und gestalten Sie Ihre Backup - Strategie und verschlüsseln alle sensiblen Daten mit dieser Annahme im Auge behalten. Und es sind nicht nur Hacker, vor denen Sie sich schützen müssen. Verärgerte, unehrliche oder ahnungslose Mitarbeiter könnten Klartext-Passwörter preisgeben.

Ohne Hash müssen Sie den Zugriff für alle Benutzer deaktivieren, bis sie ihr Kennwort geändert haben (was, selbst wenn es möglich ist, große Kopfschmerzen für alle Benutzer mit sich bringt). Wenn die Passwörter gehasht und gesalzen worden wären, könnten Sie den Webdienst wiederherstellen, und es wäre für einen Angreifer viel schwieriger, Zugang zu den Konten der Benutzer zu erhalten.

Ein richtig gehashtes und gesalzenes Passwort ist im Grunde eine Einbahnstraße. Sie können das Passwort nicht einfach anhand des Hash-Passworts erraten. Auch Sie, da der Dienstanbieter dies nicht erraten kann, können es nur zurücksetzen.

Versuchen Sie auch nicht, wie Elin sagte, Ihr eigenes Hashing (oder Ihre eigene Verschlüsselung) zu starten. Verwenden Sie eine Standardbibliothek.

david25272
quelle
13
+1 für die Erwähnung verärgerter Mitarbeiter. Es ist leicht zu übersehen, wenn Sie ein Ein-Mann-Geschäft oder ein kleines Unternehmen sind, aber irgendwann arbeiten Menschen mit den Daten, die Sie nicht persönlich überprüft haben.
2
Das foreach zu schreiben, um eine Liste von Benutzern zu durchlaufen und dann ihre Passwörter zu hacken, ist die Arbeit von ein paar Minuten und offen gesagt 4000 ist kaum etwas. php.net/manual/en/function.hash.php
Elin
3
Sie wechseln ständig zwischen den Begriffen "Verschlüsseln" mit "Hash und Salt" @ david25272. Verwechseln Sie nicht die beiden, die völlig unterschiedlich sind. Jetzt sucht das OP nach einem Verschlüsselungsalgorithmus und nicht nach einem Hash-Algorithmus. Es ist auch "Salz und Hasch", nicht "Hasch und Salz". Sie können nicht salzen, nachdem Sie gehackt haben.
NobleUplift
1
Lesen Sie auch meine Antwort unter @phpmysqlguy, um Vorschläge zu Salting- und Hash- Algorithmen zu erhalten.
NobleUplift
36

Ich habe aber noch andere Probleme, wenn jemand in meine Datenbank kommt, zB das Löschen von Daten.

Es geht nicht um die Probleme, die Sie haben, es geht um die Probleme, die es für alle Ihre anderen Benutzer verursachen könnte. Es geht darum, die Versuchung (oder noch schlimmer die potenzielle Haftung) für die auf der Website arbeitenden Personen zu beseitigen, dort gespeicherte Daten zu missbrauchen.

Siehe, auch wenn die Menschen sollten unterschiedliche Passwörter auf verschiedenen Systemen verwenden, ist die Realität , die dies nicht tun .

... und da es so einfach ist, Passwörter zu hacken, gibt es keine Entschuldigung dafür, dass Sie die branchenüblichen Best Practices nicht befolgen.

Sean McSomething
quelle
9
Sie machen das, was ich für den wichtigsten Punkt halte : SIE und Ihre Mitarbeiter sollten keinen Zugriff auf das Passwort des Benutzers haben. Wen interessiert der Hacker, die Leute, die die Daten haben, sind es, die die Benutzer betreffen.
Adam Davis
1
+1 für die Tatsache, dass Sie als Entwickler / Administrator keinen Zugriff auf die Passwörter Ihrer Benutzer haben sollten. Das allein ist Grund genug.
Matt
21

Auffällige Angriffe wie das Löschen von Daten sind in der Regel nur für Amateure von Bedeutung und Ihre geringste Sorge. Eines der ersten Dinge, die ein erfahrener Angreifer tun wird, ist der Versuch, legitimen Zugriff zu erlangen. Selbst wenn Sie die ursprüngliche Sicherheitsanfälligkeit, die er verwendet hat, korrigieren, kann er dennoch eingreifen erreicht, was er wünscht. Indem Sie Passwörter offen lassen, haben Sie möglicherweise seine Arbeit viel einfacher gemacht. Sie haben es auch schwieriger gemacht, sein zukünftiges böswilliges Verhalten zu erkennen und zu isolieren.

Nicht alle Kompromisse bieten Ihnen vollständigen Shell-Zugriff. Was passiert, wenn die von einem Angreifer verwendete Sicherheitsanfälligkeit nur eine schreibgeschützte SQL-Injektion in der usersTabelle ist? Wenn er die Passwörter offen ließ, hatte er fast uneingeschränkten Zugriff.

Dies kommt zu den Gründen hinzu, die in anderen Antworten in Bezug auf Ihre Verantwortung zum Schutz der Daten Ihrer Benutzer genannt werden. Mein Punkt ist, dass nicht nur Ihre Benutzer etwas zu verlieren haben.

Karl Bielefeldt
quelle
18

Ich muss hier eine Antwort auf einen Irrtum in der Frage selbst posten. Sie fragen, ob Passwörter verschlüsselt werden sollen. Niemand verschlüsselt Passwörter; Niemand außer Diensten und Programmen wie Firefox Sync und Roboform, deren einziger Zweck die Verschlüsselung von Passwörtern ist.

Werfen wir einen Blick auf die Definitionen:

Bei der Verschlüsselung werden Nachrichten (oder Informationen) so verschlüsselt, dass sie nur von autorisierten Parteien gelesen werden können.

Und Haschisch:

Eine Hash-Funktion ist ein beliebiger Algorithmus, der Daten beliebiger Länge auf Daten fester Länge abbildet.

Mit anderen Worten, Verschlüsselung ist eine bidirektionale Konvertierung, und Hashing ist eine einseitige Konvertierung. Wenn Sie also nicht entschlüsseln, um sie später anzuzeigen, handelt es sich nicht um Verschlüsselung.

Auch nicht nur Hasch, Salz ! Lesen Sie diese gesamte Seite, bevor Sie Ihre Passwörter hacken.

Bezüglich der Hashing-Algorithmen, die das OP derzeit untersucht, würde ich eine der High-End-SHA-2-Varianten vorschlagen, wie z. B. SHA-384 oder SHA-512.

Und achten Sie darauf, Runden von Hashing zu verwenden . Hasch nicht einmal, sondern mehrmals.

Lesen Sie diese Seite , um Ihren Anmeldevorgang noch sicherer zu machen.

Zweitens kann Ihre Datenbank niemals sicher genug sein. Es wird immer Sicherheitslücken und sich ständig weiterentwickelnde Risiken geben. Sie sollten Murphys Gesetz befolgen und sich immer auf das Schlimmste vorbereiten.

Die anderen Punkte, die pdr hervorhebt, sind genau das, was ich sonst sagen würde: Leute, die für jede Website dasselbe Passwort verwenden, Hacker, die Social Engineering einsetzen, um mehr Informationen zu erhalten, usw. usw.

NobleUplift
quelle
+1 für Hash plus Salz. Das Knacken von Hashes ohne Salze ist sooo einfach.
Code Maverick
3
Wissen Sie, was sich auf der anderen Seite eines Regenbogentisches befindet? @CodeMaverick? Ein Topf voll Gold.
NobleUplift
Im Zusammenhang mit Kennwort-Hashing sind in MD5 keine Sicherheitslücken bekannt, die nicht nur schnell sind. Dies gilt auch für SHA-2. Die Verwendung einer langsamen, iterierten Konstruktion ist weitaus wichtiger als die Auswahl von SHA-2 gegenüber MD5.
CodesInChaos
4
"Lesen Sie die gesamte Seite, bevor Sie Ihre Passwörter haschen" - auf dieser Seite wird erwähnt, dass Sie keine Hash-Runden verwenden sollten , sondern eine Hash-Methode, die speziell so langsam wie nötig entwickelt wurde, wie z. B. PBKDF2.
JHOMINAL
2
Verwenden Sie SCrypt oder PBKDF2, die beide für eine sehr kostenintensive Arbeitsspeicher- oder CPU-Leistung ausgelegt sind. Verwenden Sie ein zufällig generiertes Salt, das Sie im Benutzerdatensatz speichern. Führen Sie nicht mehrere Runden Hashing durch, da dies nur zu Kollisionsproblemen führt.
tom.dietrich
14

Hier geht es um ein wichtiges Prinzip. Es gibt nur eine Person, die ein Unternehmen hat, das ein Benutzerpasswort kennt. Das ist der Benutzer. Nicht ihre Frau / ihr Ehemann, ihr Arzt oder auch nur ihr Priester.

Der Programmierer, Datenbankadministrator oder Systemtechniker, der für den von ihm verwendeten Dienst verantwortlich ist, ist definitiv nicht dabei. Dies stellt eine Herausforderung dar, da der Programmierer den Nachweis erbringen muss, dass der Benutzer das Kennwort tatsächlich kennt. Dies ist ein nicht triviales Problem, das auf reine Weise zu lösen ist.

Die reine Lösung besteht darin, einen Mechanismus zu haben, bei dem der Benutzer mit einigen neuen und unvorhersehbaren Daten herausgefordert wird und dann eine Antwort zurückgeben muss, die auf diesen Daten und ihrem Kennwort basiert. Eine Implementierung davon wäre, den Benutzer zu bitten, einige neu generierte Daten mit ihrer digitalen Signatur digital zu signieren, und wir könnten mathematisch nachweisen, dass sie dasselbe kryptografische Schlüsselpaar verwendeten, das sie ursprünglich zum Erstellen des Kontos verwendet haben.

In der Praxis erfordern die reinen Lösungen eine umfangreiche clientseitige Infrastruktur und Verarbeitung, und für viele Websites ist dies häufig nicht angemessen für die zu schützenden Daten.

Eine häufigere Lösung wäre:

An dem Punkt, an dem ein Kennwort zum ersten Mal in der Anwendung empfangen wird, wird das Kennwort zusammen mit dem zufälligen Salt-Wert der Anwendung an die Hash-Funktion übergeben.

Die ursprüngliche Zeichenfolge wird dann im Speicher überschrieben, und ab diesem Zeitpunkt wird der gesalzene Hash in der Datenbank gespeichert oder mit dem Datenbankdatensatz verglichen.

Die wichtigsten Aspekte, die hier für Sicherheit sorgen, sind:

  1. Die Kenntnis des Hash liefert keine direkte Authentifizierung.
  2. Die umgekehrte Berechnung des Passworts aus dem Hash ist nicht praktikabel.
  3. Die Verwendung von Regenbogentabellen (lange Listen mit Passwörtern und deren berechneten Hashes) wird erschwert, da der resultierende Hash sowohl vom Benutzernamen als auch vom Passwort abhängig ist.
Michael Shaw
quelle
6
Im Allgemeinen wird es bevorzugt, ein zufälliges Salt anstelle des Benutzernamens zu verwenden.
CodesInChaos
Wow, toller Fang @CodesInChaos. Ich habe das beim ersten Durchlesen der Frage nicht bemerkt. Ja, dein Salz sollte zufällig generiert werden. Es muss kein verrückter Blob sein, der in MySQL gespeichert ist (und das wäre schlecht, weil es dann nicht portierbar wäre). Andernfalls +1, um zu sagen, dass nur der Benutzer das Kennwort des Benutzers kennen sollte.
NobleUplift
Okay, aktualisierte Antwort, um vorzuschlagen, dass die Anwendung einen eigenen zufälligen Salzwert hat.
Michael Shaw
4
Nein, die Anwendung nicht ein Salz Wert entweder. Es sollte für jeden gespeicherten Hash einen anderen, stark zufälligen Salzwert geben. (Sie bewahren das Salz neben diesem Hash auf.) Das schützt vor statistischen Angriffen. Wenn Sie denselben Hash für die gesamte Anwendung verwendet haben, wird derselbe Klartext auf denselben Wert gehasht. Das ist weitaus schlimmer, als den Benutzernamen als Hash zu verwenden.
Ben Voigt
Es ist kein Webdienst, aber die SSH-Schlüsselpaarauthentifizierung verwendet die "reine" Lösung, bei der der Server einen öffentlichen Schlüssel speichert und der Benutzer sich mit einem privaten Schlüssel authentifiziert.
Schlussbericht vom
10

Sie müssen die Passwörter als zweite Sicherheitsebene "verschlüsseln" (eigentlich "Hash"), um eine Eskalation der Datenbank zu verhindern das in Lese- und Schreibzugriff und genau beginnen, die Daten zu ändern. In der realen Welt kommt es zu Teilbrüchen mit Lesezugriff, z. B. durch einen SQL-Injection-Angriff von einem Konto mit Lesezugriff aus oder durch Abrufen einer ausrangierten Festplatte oder eines alten Sicherungsbands von einem Papierkorb. Ich habe ausführlich über dieses Thema geschrieben dort .

Die richtigen Methoden zum Hashing von Passwörtern finden Sie in dieser Antwort . Dies beinhaltet Salze, Iterationen, und vor allem nicht Ihre eigenen Algorithmen (hausgemachte Kryptographie ist ein sicheres Rezept für eine Katastrophe) zu erfinden.

Thomas Pornin
quelle
+1 für das Erkennen des Unterschieds zwischen Verschlüsselung und Hashing.
NobleUplift
8

Ich werde nicht wiederholen, was andere Leute gesagt haben, aber wenn Sie PHP 5.3.8 oder besser haben, sollten Sie das native PHP verwenden bcrypt, um Ihre Passwörter zu speichern. Dies ist in PHP integriert. Wenn Sie PHP 5.5 haben, können Sie die beste verfügbare Passwortkonstante verwenden. Sie können auch eine Bibliothek verwenden, damit sich 5.3.8 oder besser wie 5.5 verhält.

Stack Overflow Frage Wie benutzt man bcrypt zum Hashing von Passwörtern in PHP? erklärt es, und die anderen Antworten erklären mehr. Bitte versuchen Sie nicht, dies selbst zu tun.

Elin
quelle
2
Leider verwende ich PHP 5.3.3, sodass Ihre Vorschläge nicht zutreffen
phpmysqlguy
4
ist 5.3.3 auf 5.3.8 ein großes Upgrade?
gbjbaanb
Gibt es eine Chance, dass Sie Red Hat nutzen? Weil sie das Update auf bcrypt zurückportiert haben. Wenn nicht, verwenden Sie SHA256 anstelle von brcypt.
Elin
1
Verschlüsselung und Hashing sind verschiedene Dinge. Hash-Passwörter, verschlüsseln Sie sie nicht. Sie müssen sie nie kennen. Der Benutzer muss nur in der Lage sein, das Kennwort zu verwenden, um zu beweisen, wer er ist. Hashing (mit Salz) erlaubt dies. Verschlüsselung, insb. Die symmetrische Verschlüsselung ist falsch, da Kennwörter wiederhergestellt werden können.
Paul de Vrieze
Die eine Sache, die ich hinzufügen möchte, ist, dass das Gute an der Funktion password_hash () in PHP 5.5+ ist, dass sie standardmäßig das Salting und so weiter erledigt. Zuvor müssen Sie so etwas wie die Bibliothek von ircmaxell verwenden, die diese zurückportiert (er hat die 5.5-Implementierung geschrieben). Gehen Sie nicht davon aus, dass Sie selbst ein zufälliges Salz erzeugen können. Es ist sehr sehr schwer und am besten Experten überlassen; Es ist wirklich einfach, zufällige, aber nicht einheitliche Ergebnisse zu erhalten, die ausgenutzt werden können.
Elin
7

Ich stimme der Antwort von pdr aus den in dieser Antwort angegebenen Gründen zu.

Ich möchte Folgendes hinzufügen: Sie sollten es tun, weil es einfach zu bewerkstelligen ist und allgemein als Best Practice für jede Anwendung akzeptiert wird. Insbesondere sollten Kennwörter immer gesalzen und gehasht werden, bevor sie in einen dauerhaften Speicher geschrieben werden. Hier finden Sie eine gute Referenz zur Bedeutung des Saltings und der Auswahl eines guten kryptografischen Hashs (der auch kostenlosen Quellcode in mehreren gängigen Sprachen bereitstellt): https://crackstation.net/hashing-security.htm

Die geringe zusätzliche Entwicklungszeit ist den Schutz wert, den sie Ihren Benutzern und Ihrem Ruf als Entwickler bietet.

AngCaruso
quelle
+1 für beide Versalzung zu erwähnen, und Hashing sowie nicht zu erwähnen , Verschlüsselung, die nicht einmal in dieser Frage gehört.
NobleUplift
2

Das Szenario, an das ich denken kann, ist, dass Sie gehackt werden.

Ein weiteres Szenario, an das Sie denken müssen: Jemand hat Ihrem Datenbankadministrator (oder jedem, der bestimmte Abfragen für Ihre Datenbank ausführen kann) 100 US-Dollar ausgezahlt, um ihm die Kennwörter der Benutzer zu geben. Oder Sozialingenieure, die Praktikanten sind.

Dann melden sie sich mit diesen Passwörtern bei Google Mail oder der Commerce-Website des Nutzers an (weil die Leute ... weniger als schlau sind - und auf allen Websites dasselbe Passwort verwenden).

Dann verklagt der zornige Benutzer Ihr Unternehmen, weil es sein Passwort offengelegt hat.


NIEMAND (einschließlich Personen in Ihrem Unternehmen) sollte das Klartext-Passwort lesen können. Je. Dafür gibt es keine legitimen geschäftlichen oder technischen Gründe.

DVK
quelle
2

Zum einen sollten selbst Datenbankadministratoren die Kennwörter der Benutzer nicht sehen. Durch das Hashing wird dies verhindert, falls der Administrator ein Kennwort überprüft und sich bei seinem Benutzerkonto anmeldet.

Rolen Koh
quelle
1
dies fügt nichts hinzu würdig zu dem, was bereits in früheren Antworten gepostet
gnat
3
+1. Er sagte tatsächlich "Hashing", anstatt Verschlüsselung wie viele andere. Außerdem widersprach er direkt dem OP, der sagte, er wolle, dass sich die Passwörter im Klartext in die Konten anderer Benutzer einloggen.
NobleUplift
0

Nun, es ist überraschend, dass dies noch niemand erwähnt hat, aber wie steht es mit der physischen Sicherheit Ihrer Datenbank?

Möglicherweise haben Sie die weltweit beste IT-Sicherheit eingerichtet, aber das hindert niemanden daran, physischen Zugriff auf Ihre Speichermedien zu erhalten. Was passiert, wenn Ihr Team heute Nachmittag den Superbowl gewinnt und ein kleiner Aufruhr in der Innenstadt Ihrer Stadt ausbricht, in der sich Ihr Büro- / Hosting-Anbieter befindet? (Angesichts der Tatsache, dass es sich um Seattle gegen Denver handelt, zwei große IT-Bereiche in den USA, halte ich das nicht für unvernünftig.) Der Mob dringt in Ihr Gebäude ein und während die Behörden überfordert sind, schnappt sich jemand einen Teil Ihrer Hardware mit einer Datenbank, die Klartext-Passwörter enthält.

Was passiert, wenn die Feds auftauchen und Ihre Ausrüstung beschlagnahmen, weil ein hochrangiger Manager seine Position im Unternehmen dazu nutzte, illegale Aktiengeschäfte durchzuführen? Dann verwenden die Feds diese Passwörter, um Ihre Kunden zu untersuchen, obwohl sie nichts falsch gemacht haben. Dann merken sie, dass SIE sie verwundbar gemacht haben.

Was passiert, wenn Ihre IT-Abteilung vergisst, die alten RAID-Laufwerke, auf denen sich Ihre Datenbank befindet, zu löschen, wenn sie geplante Ersetzungen vornehmen, bevor sie die alten Laufwerke an Praktikanten "verteilen". verkaufen "es und haben es nie zu ihnen zurückverfolgt?

Was passiert, wenn Ihr DB Server ein Motherboard kaputt macht, die IT ein Image auf Ihrem neuen Server wiederherstellt und die "Karkasse" des alten Servers in den Recycling-Haufen geworfen wird? Diese Laufwerke sind immer noch gut und diese Daten sind immer noch da.

Jeder anständige Architekt weiß, dass Sicherheit nicht etwas ist, das Sie später mit Firewalls und Betriebsrichtlinien "verankern". Sicherheit muss von Anfang an ein wesentlicher Bestandteil des Designs sein. Das bedeutet, dass Passwörter in eine Richtung gehasht, NIEMALS unverschlüsselt übertragen (selbst in Ihren eigenen Rechenzentren) und niemals wiederherstellbar sind. Alles, was abgerufen werden kann, kann kompromittiert werden.

Wesley Long
quelle
-1

Abgesehen von dem Fall, dass Ihre Datenbank gehackt wird: Als Kunde möchte ich nicht, dass SIE mein Passwort kennen. Ich weiß, dass Sie das Passwort leicht abfangen können, wenn es auf Anfrage eingeht, aber ich habe ein besseres Gefühl, wenn Sie es nicht zur Verfügung haben, um es jederzeit abzufragen.

piet.t
quelle
1
Wenn das OP einen Schritt weiterginge und in JavaScript verschlüsselt wäre, würde der Hash über die Leitung gesendet und niemals in der Anforderung angezeigt.
NobleUplift
1
In diesem Fall müsste ein Angreifer den Hash auch nur über die Leitung senden. Der Hash würde nur als ausgefallenes, aber unverschlüsseltes Passwort funktionieren, nicht wahr? (Edit: nicht, wenn es jedes Mal mit einem anderen Salz gesalzen werden musste und das Salz vom Server kam. Ich denke)
RemcoGerlich
1
@RemcoGerlich Das Schlüsselkonzept ist als Nonce bekannt, mit dem ein Replay-Angriff vermieden wird .
-1

Wenn die Passwörter im Klartext gespeichert werden, bedeutet dies, dass sie dem Benutzer bekannt sind und wer auch immer Zugriff auf diese Tabelle hat. Die gesamte Idee beim Implementieren von Benutzern und Kennwörtern besteht darin, sicherzustellen, dass eine bestimmte Sitzung in Ihrem System sowohl aus Datenschutz- als auch aus Sicherheitsgründen dieser Person gehört.

Wenn eine Gruppe von Personen einen Benutzernamen / ein Kennwort kennt, ist es nicht mehr sinnvoll , eine Person eindeutig zu identifizieren. Dadurch entstehen viele mögliche Szenarien für Identitätsdiebstahl, Betrug ...

Aus diesem Grund werden Passwörter mit asymetrischen Verschlüsselungsprotokollen gespeichert, um sicherzustellen, dass Sie sie validieren können, ohne sie lesen zu können.

Alpha1983
quelle
2
Wer speichert Passwörter mit asymmetrischer Verschlüsselung? Das ist Public-Key-Kryptografie. Das bedeutet, dass mein Kennwort auch nach dem Verschlüsseln entschlüsselt und gelesen werden kann, wenn jemand meinen privaten Schlüssel erhält. Beim Hashing kenne ich und nur ich mein Passwort (es sei denn, ich schreibe es auf oder schreibe es in einen Passwort-Manager, in dem es sich tatsächlich um eine asymmetrische Verschlüsselung handelt).
NobleUplift
Bitte überprüfen Sie die Wikipedia-Seite für Public-Key-Kryptographie: en.wikipedia.org/wiki/Public-key_cryptography "Public-Key-Kryptographie, auch als asymmetrische Kryptographie bekannt,"
Alpha1983
2
... ja, das habe ich gesagt using asymmetric encryption? That's public-key cryptography. Worum geht es dir?
NobleUplift
-1

Ich denke, dass die Frage einen fundamentalen Fehler aufweist. Fakt ist, es gibt keine "sichere Datenbank". Es sollte vorausgesetzt werden, dass es irgendwo Fehler in Ihrem System gibt, die böswilligen Benutzern den Zugriff auf beliebige Daten auf Ihren Servern ermöglichen könnten. Heartbleed ist ein exzellentes Beispiel dafür, ein Exploit, der über zwei Jahre lang in der Natur war, bevor er von Forschern bemerkt wurde. Möglicherweise haben Sie alles getan, was Sie wissen, um die Daten zu schützen, aber Sie können nicht alle anderen Softwareteile, die Sie auf Ihren Servern verwenden, und die komplizierten Interaktionsweisen erklären.

Wenn jemand ein Interesse an Ihnen nimmt, Sie werden zerhackt erhalten. Es ist wichtig, dass Sie Ihr Bestes tun, um zu verhindern, dass Sie in erster Linie gehackt werden, aber auch, um den Schaden zu verringern, der dadurch entsteht, dass Sie so viele Hürden wie möglich überwinden. Hash deine Passwörter. Es ist nicht so schwer einzurichten, und Sie tun Ihren Benutzern einen schlechten Dienst, indem Sie ihre Privatsphäre nicht ernst nehmen. Es ist Hybris zu glauben, dass Sie besser gegen böswillige Angriffe geschützt sind als Unternehmen wie Yahoo , Sony oder Target , die alle gehackt wurden.

Lobati
quelle
1
Dies scheint nichts Wesentliches zu bieten über 14 vorherige Antworten
Mücke
Ich bin anderer Meinung, sonst hätte ich es nicht gepostet. Ich bin mir nicht sicher, wie Ihre negativen Kommentare zu dem Gespräch beitragen, abgesehen davon, dass Sie die Leute davon abhalten, daran teilzunehmen.
Lobati
Nun, ich weiß nicht, ob Sie andere Antworten gelesen haben, bevor Sie Ihre veröffentlichen, aber laut meiner Lektüre wurden alle Punkte hier bereits an anderer Stelle gemacht (und laut meiner Lektüre besser dargestellt). ZB wurde in dieser und dieser Antwort vor mehr als 2 Monaten auf einen Fehler in der Frage hingewiesen. Hinweis zum Hashing von Passwörtern wurde mindestens in 7 anderen Antworten gemacht. Der Punkt, wie man Backups erstellt und mögliche Probleme in anderen Teilen des Systems berücksichtigt, wurde ebenfalls vor langer Zeit angesprochen. Usw.
Mücke
Der damit verbundene Irrtum unterschied sich von meinem. Sie stellten den Unterschied in der Bedeutung zwischen Hashing und Verschlüsselung fest, während ich sagte, es sei ein Trugschluss zu glauben, dass eine Datenbank als "sicher" angesehen werden könne. Ich sehe immer noch keine anderen Antworten, in denen andere Softwareteile und ihre Interaktionen als unsicher erörtert werden, und ich habe keine Anmerkungen zu Sicherungen gemacht.
Lobati
„nehme an, Sie werden gehackt werden“ - das ist , wie es in einer Antwort geschrieben wurde vor mehr als 2 Monate zuvor
gnat