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

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.