Frage:
Warum ist Passwort-Hashing so wichtig?
ANortonsmith
2013-08-29 05:44:50 UTC
view on stackexchange narkive permalink

Nachdem ich diesen Artikel gelesen habe, kann ich die Vorteile von Passwort-Hashing als zweite Verteidigungsstufe sehen, falls ein Eindringling Zugriff auf eine Passwortdatenbank erhält. Was ich immer noch nicht verstehe, ist Folgendes:

Ist das Hashing von Passwörtern nicht nur wichtig, wenn das System schwach genug ist, um einem Eindringling Zugriff auf die Passwortdatenbank zu gewähren? Wenn ja, warum wird dann ein solcher Schwerpunkt auf den Aufbau sicherer Kennwortdatenbanken gelegt, anstatt auf sichere Systeme, die den unbefugten Zugriff auf wichtige Benutzerinformationen verhindern würden? Wie kommt es, dass gehashte Passwortdatenbanken so oft gestohlen werden?

Hashing ist keine zweite Verteidigungsschicht, sondern eine Versicherungspolice. Implementieren Sie die Technologie unter der Annahme, dass das System letztendlich kompromittiert wird. Wenn Sony, Blizzard, Dropbox oder Apple nicht in der Lage sind, ihre Systeme sicher zu halten, warum glauben Sie dann, dass Sie dies können? Dies ist nichts gegen Sie, aber wenn Unternehmen mit nahezu unbegrenzten Ressourcen, deren Hauptgeschäft von der Sicherung ihres Systems abhängt, ihr System nicht schützen können, haben Sie keine Chance. Implementieren Sie also Technologie, um Schäden zu vermeiden, wenn sie auftreten.
@Ramhound IIRC Sonys Fall Es ging nicht darum, viel Mühe zu investieren, sondern immer noch auszurutschen. aber grobe Fahrlässigkeit, die von niemandem verursacht wird, der die Möglichkeit in Betracht zieht, gehackt zu werden. Als solches bin ich mir nicht sicher, ob sie ein gutes Beispiel sind.
@DanNeely - Die Tatsache, dass sie die Möglichkeit nicht in Betracht gezogen haben, ist genau der Grund, warum ich sie verwendet habe (auch die Tatsache, dass sie leicht zu merken sind). Ich könnte zu Twitter, Linken, der Muttergesellschaft von Gizmodo, wechseln, wenn Sie mehr wollen. Der Punkt der Aussage, nehmen Sie an, dass es passieren wird und tun Sie, was Sie können, um die Familie der Hasen zu verhindern, die getötet werden, nachdem es passiert.
Ein weiterer Punkt: Prozessoren sind heutzutage so schnell und Angriffsmethoden so ausgefeilt, dass es ratsam ist, kein Hashing zum Verschlüsseln von Passwörtern zu verwenden. Warum? Das Berechnen eines Hashs ist von Natur aus eine sehr schnelle Operation, da der ursprüngliche Anwendungsfall darin bestand, die Dateiintegrität zu überprüfen. Zum Verschlüsseln von Passwörtern ist es besser, einen Algorithmus zu verwenden, dessen Berechnung viel länger dauert als ein Hash, der jedoch bei der Überprüfung einzelner Passwörter schnell genug ist. Dies wird Brute-Force-Angriffe verlangsamen. [Bcrypt] (http://goo.gl/T2g0yv) ist ein solcher Algorithmus. [Weitere Informationen finden Sie hier.] (Http://goo.gl/aiyPKQ)
@Andy Tatsächlich wirkt sich das Versalzen eines Passworts nicht wirklich auf die Zeit aus, die für Brute-Force benötigt wird. Das liegt daran, dass jemand, der die Hash-Passwörter hat, wahrscheinlich auch das Salz bekommen könnte.
@ponsfonze Es tut mir leid, aber ich denke, Sie müssen mehr über das Salzen lesen. Ein Salz soll überhaupt kein Geheimnis sein, es wird davon ausgegangen, dass jemand, der die Hashes bekommt, auch die Salze bekommt. http://en.wikipedia.org/wiki/Salt_%28cryptography%29. Der Salzzweck besteht darin, vorberechnete Regenbogentabellen zu besiegen.
@ponsfonze Wenn Sie ein Passwort knacken, sind Sie richtig - es beschleunigt nicht. Im Falle eines massiven Knackens der gesamten Datenbank müssen Sie jedoch jedes Passwort separat knacken. Wenn sie ungesalzen wären, könnten Sie einfach "Affe" hashen und alle Benutzer abrufen, die es als Passwort haben. Da es sich um Salz handelt, müssen Sie "Affen" mit jedem einzelnen Salz hacken. (Angesichts der Tatsache, dass die Datenbank möglicherweise Tausende von Passwörtern enthält, bedeutet dies, dass viel mehr Arbeit erforderlich ist, um diese zu verarbeiten.)
Es ist falsch zu behaupten, dass "alte" Hashing-Algorithmen schnell und "neue" langsam sind. Die meisten Hashing-Algorithmen wurden nie für die Verwendung von Passwörtern entwickelt, und es gibt viele neue, die völlig ungeeignet sind. Es ist kein Thema für diese Frage, aber stellen Sie im Grunde sicher, dass Sie Ihre Hausaufgaben machen und einen Hashing-Algorithmus wählen, der stark und vertrauenswürdig ist, da sonst Ihre Benutzer gefährdet sind.
@Andy tatsächlich neuere Hashes sind in der Regel schneller. [SHA-3] (http://en.wikipedia.org/wiki/SHA-3) wurde speziell ausgewählt * weil * es so schnell ist * (na ja, und weil es so anders ist als SHA-2 ..) *
@BlueRaja-DannyPflughoeft Ja, ich hatte festgestellt, dass ich in diesem Aspekt falsch lag.
@Andy Vielen Dank, dass Sie diesen Link für mich bereitgestellt haben. Ich bin mir nicht sicher, wohin Sie mit dem Zweck eines Salt gehen. In meinem Kommentar geht es um die Auswirkungen der Rechenzeit beim Hashing von Passwörtern mit einem Salt.
@MaciejPiechotka Vielen Dank, dass Sie den Punkt angesprochen haben, an dem im Fall von Bruteforcing-Hashes in einer ganzen ungesalzenen Datenbank die Rechenzeit verkürzt wird, da nicht für jedes Kennwort derselbe Hash neu berechnet werden muss. Beachten Sie jedoch auch, dass 1000 oder mehr zu knackende Passwörter in Zukunft möglicherweise unbedeutend sind, wenn Prozessoren exponentiell schneller werden oder einige dies prognostiziert haben.
@ponsfonze: Trotzdem macht das Salzen es 1000-mal langsamer, unabhängig von der verwendeten Technologie (oder 1000000 für 1000000 Benutzer) - sicher macht es weniger Unterschied zwischen 1s und 20 Minuten als 1 Tag und 3 Jahren, aber das erste Beispiel verwendete ohnehin viel zu einfache Hashs oder Passwörter . Die Verbesserungen von Prozessoren können durch härtere Probleme (speicherharte Algorithmen usw.) bekämpft werden.
Acht antworten:
#1
+35
user10211
2013-08-29 05:50:29 UTC
view on stackexchange narkive permalink

Wenn ja, warum wird dann ein solcher Schwerpunkt auf den Aufbau sicherer Kennwortdatenbanken gelegt, anstatt auf sichere Systeme, die den unbefugten Zugriff auf wichtige Benutzerinformationen verhindern würden?

Weil dies der Fall ist eine wirklich schwierige Sache. Es gibt keine Garantie dafür, dass Ihr System 100% hackfest ist. Wenn Sie einen solchen Anspruch auf Reddit erheben, wird Ihre Website wahrscheinlich innerhalb einer Stunde kompromittiert.

In der Sicherheit wird häufig der Begriff Tiefenverteidigung verwendet. Eine gefährdete Kennwortdatenbank wirkt sich nicht nur auf Ihre Anwendung aus. Die meisten Benutzer verwenden dieselbe Kombination aus Benutzername und Passwort für mehrere Websites. Dies macht es für einen Angreifer, der eine einzelne Kennwortdatenbank kompromittiert hat, trivial, Zugriff auf mehrere Dienste zu erhalten, die ein Benutzer verwendet. Aus diesem Grund werden häufig Empfehlungen von Websites angezeigt, die kompromittiert wurden, damit Benutzer ihre Kennwörter für alle Konten ändern können.

Auch wenn Sie Ihre -Anwendung nur als wichtig erachten, Es gibt viele Dinge, die ein Angreifer tun kann, wenn er die Klartextkennwörter Ihrer Benutzer hat. Für einen Angreifer ist es schwierig, Datenbankwerte ohne Erkennung direkt zu ändern. Mit einem kompromittierten Klartext-Passwort kann er sich jedoch einfach in ein Benutzerkonto einloggen und die Änderungen vornehmen. Dies ist sehr schwer zu erkennen.

Aus dem gleichen Grund habe ich beim Klettern einen Doppelanker. Sicher, ein einzelner Clip kann mit 27 kN bewertet werden (genug, um einen Ford F150 aufzunehmen), aber * wenn * dies fehlschlägt, habe ich mit diesem zweiten Anker immer noch eine Versicherungspolice in meinem Leben.
#2
+32
Abhi Beckert
2013-08-29 08:05:23 UTC
view on stackexchange narkive permalink

Die Erfahrung hat die Community gelehrt, dass es praktisch unmöglich ist, Eindringlinge fernzuhalten. Es ist eine Frage, wann und nicht ob jemand Zugriff auf Ihre Passwortdatenbank erhält.

Es spielt keine Rolle, ob Sie ein zufälliger Blog oder eine Regierungsabteilung im Wert von mehreren Milliarden Dollar sind dass jemand eines Tages Zugang erhält. Und ziemlich oft haben sie genug Zugriff, um die Datenbank zu lesen, aber nicht genug Zugriff, um beispielsweise einen Mann in der Mitte einzufügen, der Klartext-Passwörter abruft, wenn sie zur Authentifizierung einer Person verwendet werden.

Sie hacken beispielsweise möglicherweise nicht Ihren Primärserver, sondern nur einen Server, der Sicherungskopien Ihrer Datenbank enthält.

Außerdem haben die meisten Organisationen viele Mitarbeiter. Ein Mitarbeiter muss Ihr Netzwerk nicht hacken, um die Datenbank anzuzeigen. Möglicherweise hat er bereits uneingeschränkten Zugriff (insbesondere, wenn er Ingenieur oder Systemadministrator ist). Es gibt viele Gründe, warum es für Ihre Mitarbeiter eine schlechte Idee ist, Kundenkennwörter zu kennen.

Auch wenn Ihre Website völlig wertlos ist und es keine Rolle spielt, ob sich jemand darauf einlässt. Der Benutzername und das Kennwort, mit denen Sie sich auf Ihrer Website anmelden, stimmen häufig mit denen überein, mit denen Sie sich bei anderen viel wichtigeren Diensten anmelden.

Beispielsweise könnte jemand einen Bot schreiben, der versucht, sich bei iTunes von Apple anzumelden Speichern Sie mit jedem Benutzernamen / Passwort in Ihrer Datenbank. Wenn dies erfolgreich ist, werden die Dinge über das Geschäft gekauft. Dieser Angriff kann für bis zu 10% der Benutzer in Ihrer Datenbank erfolgreich sein, und viele dieser Benutzer werden nicht einmal bemerken, dass ihnen 4,99 US-Dollar in Rechnung gestellt wurden. Dies ist kein theoretischer Angriff, er findet jeden Tag den ganzen Tag statt und Versuche, ihn zu stoppen, sind nicht immer erfolgreich.

BEARBEITEN: Und in den Kommentaren machte @emory einen weiteren Punkt, den ich vergessen habe: Jemand könnte eine Vorladung einreichen oder ein anderes rechtliches Verfahren anwenden, um Zugriff auf die Datenbank zu erhalten, sodass er Klartext-Passwörter sehen kann, es sei denn, Sie haben einen guten Hash. Beachten Sie, dass dies nicht nur die Strafverfolgung tun kann. Jeder private Anwalt mit einem starken Rechtsstreit gegen Sie kann auf Ihre Datenbank zugreifen.

+1 für die Erwähnung des oft vergessenen Angriffsvektors von Backups.
Und +1 für Insider-Angriffe. Ein Insider, der stillschweigend die Nicht-Zurückweisung kompromittiert, kann katastrophale Langzeiteffekte haben und ist unglaublich schwer zu erkennen!
Der Angreifer könnte technische Mittel umgehen und einfach Ihre Datenbank vorladen.
#3
+18
nsn
2013-08-29 12:19:00 UTC
view on stackexchange narkive permalink

Neben den bereits genannten Gründen gibt es noch einen weiteren:

Ein Passwort soll privat sein!

Wenn Sie es im Klartext haben, bedeutet dies, dass Sie oder einer Ihrer Kollegen oder verwalten Entwickler haben Zugriff auf alle Passwörter und Sie können sich als jeder Benutzer ausgeben. Jetzt denken Sie wahrscheinlich - wir würden das niemals tun, das ist falsch!

Denken Sie an ein Bankensystem: Die Datenbankadministratoren hätten alle Zugriff auf Passwörter. Dies bedeutet, dass sie sich einfach von überall in Ihr Konto einloggen und Geld abheben können. Würden Sie Ihr Geld in eine solche Bank stecken, wenn Sie das wissen? Schlimmer noch ... viele Leute verwenden dasselbe Passwort an mehreren Orten. Sie konnten sich jetzt auf dem Bankkonto anmelden und an vielen anderen Stellen über genügend Informationen verfügen.

Denken Sie daran, dass viele Angriffe innerhalb von Jobs stattfinden - Personen mit privilegierten Informationen. Angreifer kommen nicht alle von außen.

Sehr wichtige Ergänzung, +1!
#4
+6
martinstoeckli
2013-08-29 12:26:22 UTC
view on stackexchange narkive permalink

Es gibt viele Möglichkeiten, wie eine Datenbank mit Kennwörtern in unerwünschte Hände geraten kann. Wenn die Passwörter in diesem Fall nicht sicher gehasht werden, ist der Eigentümer der Website verantwortlich und in großen Schwierigkeiten, da die Benutzer ihre Passwörter häufig auch auf anderen Websites wiederverwenden. Ich möchte Ihnen einige Beispiele geben, wie eine Datenbank auslaufen kann:

  • SQL-Injection ist ein einfacher Angriff auf Ihre Website. Ich habe eine kleine Demo gemacht, um zu zeigen, wie einfach es ist. Klicken Sie einfach auf den nächsten Pfeil, um böswillige Eingaben zu erhalten. SQL-Injection kann durch Schreiben von sauberem Code behandelt werden. Oft verwenden Sie jedoch Bibliotheken von Drittanbietern oder haben den Quellcode nicht alleine entwickelt. In diesem Fall könnte unsicherer Code durchgerutscht sein.
  • Wenn Sie Ihren Code hosten Website mit einem externen Anbieter haben zumindest die Mitarbeiter des Hosting-Unternehmens freien Zugang zur Datenbank. Oft haben auch andere Personen Zugriff: Möglicherweise benötigen Sie einen Entwickler, um ein bestimmtes Problem zu beheben oder Ihre Seite zu erweitern.
  • Backups sind ebenfalls ein Problem. Wenn Backups nicht mit der gleichen Sorgfalt gespeichert werden, mit der der laufende Server gesichert ist, oder wenn sie weggeworfen werden, ohne sie ordnungsgemäß zu löschen, sind die Kennwörter undicht.
  • Wenn ein Server verworfen wird, muss er zuvor bereinigt werden entsorgen. Bei externem Hosting liegt dies nicht unter Ihrer Kontrolle. Die Reinigung kann auf RAID-Systemen sehr schwierig sein.
  • Immer mehr Daten werden in Cloud-Diensten gespeichert. Eine praktische Sache, diese Wolken, aber es ist auch bewölkt, wo Ihre Datenbank landet, und eine ordnungsgemäße Reinigung in einer Wolke kann sogar unmöglich sein.
+1 für die Erwähnung des oft vergessenen Angriffsvektors von Backups.
#5
+3
britlak
2013-08-29 06:00:17 UTC
view on stackexchange narkive permalink

Ein Sicherheitsprinzip ist, dass es keinen einzigen kugelsicheren Mechanismus gibt, sondern dass Sie sich auf mehrere Mechanismen verlassen sollten, um Ihr System / Ihre Daten zu schützen. Mit anderen Worten, Verteidigung in der Tiefe. Entscheiden Sie sich also eher für (a) Sichern der Kennwortdatenbank oder (b) Sichern des Systems, in dem es sich befindet oder verwendet wird.

#6
+2
Tom Leek
2013-08-29 18:37:02 UTC
view on stackexchange narkive permalink

In diesem Blog-Beitrag wird diese Frage behandelt. Die Zusammenfassung ist, dass Sie Passwort-Hashing als zweite Verteidigungslinie benötigen, wenn Angreifer eine teilweise, schreibgeschützte Unterbrechung erreichen. Dies ist eine häufige Folge von SQL-Injection-Angriffen, tritt jedoch auch auf, wenn ein Sicherungsband gestohlen oder eine alte Festplatte verworfen wird. Insbesondere wenn eine Platte ausfällt, kann der Fehler der der elektronischen Karte sein, aber das magnetische Medium enthält immer noch alle Daten. Wenn die Festplatte nicht gestartet wird, kann der Systemadministrator den Inhalt nicht (einfach) löschen. Wenn die Festplatte jedoch einfach in einen Müllcontainer geworfen wird, kann ein fleißiger Angreifer sie abrufen, die elektronische Karte austauschen und alle Daten lesen.

Es ist zwar besser, Angreifer nicht auf die Eingeweide Ihres Servers blicken zu lassen Erstens treten solche Verstöße in der Praxis auf, und Sie sollten sich besser davor schützen. Siehe auch diese detaillierte Antwort, wie das Passwort-Hashing durchgeführt werden sollte. Die zugrunde liegende Idee ist, dass der Server zur Überprüfung des Kennworts eines Benutzers einige kennwortabhängige Daten enthalten MUSS und ein vollständiger Speicherauszug des Serverinhalts ausreicht, um "Kennwörter zu Hause zu testen". Daher ist das Hashing von Passwörtern das Beste, was (theoretisch) durchgeführt werden kann, es sei denn, manipulationssichere Spezialhardware ist im Bild enthalten.

Ich würde eigentlich eine kleine Ausnahme bis zum letzten Punkt machen. Ich verstehe, was Sie meinen, aber alles, was der Serverprozess kann, kann im Prinzip jede Software. Es geht hauptsächlich darum, wie viel Geld und Arbeitskräfte der Angreifer auf das Problem werfen möchte. Manipulationssichere Hardware kann viele Bedrohungen erheblich mindern, sie wird jedoch nicht vollständig beseitigt. (Das heißt, ich habe dir dafür +1 gegeben.)
Ich meine, wenn der Server einen Schlüssel verwendet, um gespeicherte MAC-Werte für Benutzerkennwörter zu überprüfen, und dieser Schlüssel sich in einer dedizierten Hardware (einem HSM, einer Smartcard) befindet, die den Schlüssel verwendet, ihn aber nie preisgibt, dann der Angreifer, der ihn erhält Eine vollständige Kopie der Festplatte verfügt immer noch nicht über den Schlüssel und kann keinen Offline-Wörterbuchangriff ausführen. Solche Hardware ist auch manipulationssicher, aber ich stimme zu, dass in diesem speziellen Fall die Manipulationssicherheit irrelevant ist.
Eine Sache, die hinzugefügt werden muss, ist, dass eine "teilweise, schreibgeschützte" Unterbrechung zu einer "vollständigen" Unterbrechung oder sogar zu einer "Root-Zugriffsunterbrechung" werden kann, wenn der Angreifer das Kennwort eines Benutzers mit Administratorrechten erhalten kann. Wenn der Administrator dieses Kennwort irgendwo wiederverwendet, kann er möglicherweise SSH- oder FTP-Zugriff erhalten, und selbst wenn dies nicht der Fall ist, besteht eine gute Chance, dass er irgendwo in der Benutzeroberfläche der Webanwendung besser Fuß fassen kann (Shell-Upload) , LFI usw.). Die Schwierigkeit, Administratorkennwörter zu ermitteln, wird dadurch erheblich gemindert.
#7
  0
Jack Aidley
2013-08-30 14:43:11 UTC
view on stackexchange narkive permalink

msn erwähnte oben die Notwendigkeit der Privatsphäre im Haus; Aus diesem Grund möchte ich einen weiteren Grund hinzufügen: Sie können nicht jedem, der physischen Zugriff auf Ihre Datenbank hat, vollständig vertrauen. Hashing schützt die Datenbank sowohl vor internen als auch vor externen Kompromissen.

#8
  0
Munim
2013-08-31 11:56:09 UTC
view on stackexchange narkive permalink

Einer der Punkte, die ich nicht glaube, wird in den Antworten hier erwähnt. Ich denke, der Hauptgrund für die Implementierung von Passwort-Hashing besteht nicht darin, eine zusätzliche Ebene für Angriffe von außen hinzuzufügen, sondern sie einfach für diejenigen innerhalb des Netzwerks unlesbar zu machen.
Viele Angriffe kommen aus Ihrem vertrauenswürdigen Netzwerk. Ein verärgerter Entwickler oder Systemadministrator sollte nicht in der Lage sein, die nicht verwaschenen Passwörter des Benutzers zu lesen, selbst wenn er Zugriff auf die Datenbank hat.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...