it-swarm-eu.dev

Passwortsicherheit in Datenbanken - heute noch Best Practice?

Mögliches Duplikat:
Welche Passwort-Hashing-Methode soll ich verwenden?

Es gibt eine Menge großartiger Beiträge zur Passwortsicherheit in Datenbanken über Stapelüberlauf und auf anderen Websites, und da ich völlig neu darin bin, habe ich in den letzten Tagen einige Stunden damit verbracht, mehr darüber zu erfahren. Es gibt jedoch so viele verschiedene Vorschläge und Best Practices, dass ich immer noch sehr verwirrt war ...

Außerdem gibt es noch viele ältere Beiträge von 2007-2010 usw. Als ich sah, wie schnell sich die Dinge ändern, bin ich mir nicht sicher, ob dies immer noch üblich ist, um es so zu verwenden, wie sie es vorschlagen. Also wollte ich zusammenfassen, was ich in den Beiträgen gefunden habe und dann fragen, ob diese Methode, die ich gefunden habe, eine gute Praxis ist ...

Dies ist also kein Leitfaden, sondern eine Zusammenfassung. Ich weiß, dass es sehr, sehr einfach ist. Wenn es Fehler gibt, korrigieren Sie mich bitte!

  1. Nur um zu erwähnen: Sie sollten niemals Klartext-Passwörter speichern :)
  2. Sie "Einweg" -Hash-Passwörter, sodass niemand den Klartext sehen kann. Wenn der Benutzer das Kennwort eingibt, hashen Sie es auf die gleiche Weise und vergleichen es mit dem Hash-Pass in der Datenbank.
  3. Zusätzlich zum Hash eines Passworts sollten Sie es salzen. Sie fügen das Salz zur einfachen Kennwortzeichenfolge hinzu und hashen die neue Zeichenfolge. Wenn das einfache Passwort schwach ist, wird es durch Hinzufügen des Salzes länger und stärker.
  4. Das Salz sollte außerdem zufällig sein (ich habe gelesen, dass der Begriff "Salz" bedeutet, dass es sowieso zufällig ist, sonst wurde es "Schlüssel" genannt?). Dies dient dazu, Angriffe auf Rainbow-Tabellen zu verhindern, da der Angreifer für jedes Salz eine Tabelle erstellen müsste, was zeitlich viel teurer ist usw. Auch wenn zwei Benutzer dasselbe Kennwort haben, werden Sie es nicht erkennen, wenn Sie zufällige Salze verwenden.
  5. Das Salz ist kein Geheimnis! Es wird in der Datenbank neben dem Hash-Passwort gespeichert. Es ist jedoch möglicherweise nicht die beste Idee, einen Zeitstempel, die E-Mail-Adresse des Benutzers oder irgendetwas anderes, das mit dem Benutzer verbunden ist, als zufälliges Salz zu verwenden. Als Grund ist es z.B. erwähnt, dass Benutzer dazu neigen, auf mehreren Websites/Diensten dieselben Kennwörter zu verwenden. Also, das Salz sollte eine zufällige Zeichenfolge sein, ich habe am besten gelesen, wäre 64-Bit?
  6. Der nächste Schritt besteht darin, dem Hashing-Prozess eine Iteration hinzuzufügen (1000 oder mehr Schleifen), sodass das Salt zum Kennwort hinzugefügt wird und diese dann immer wieder gehasht werden. Dies bedeutet, dass der Benutzer nur einen Bruchteil einer Sekunde warten muss, bis er protokolliert in, aber fasst zusammen, wenn Sie etwas 10.000 Einträge in Ihrer DB haben.
  7. Es kann ein geringfügiger Vorteil sein, wenn Sie einen Site-Schlüssel hinzufügen, der z. als globale Var zusätzlich zum Salz. Sie sollten jedoch immer davon ausgehen, dass Angreifer auch Zugriff auf Ihr Dateisystem haben.
  8. Hashing-Algorithmen: Ich habe festgestellt, dass es nicht mehr sicher ist, MD5, SHA1 und andere schwache Methoden zu verwenden ...

Es gibt also unterschiedliche Meinungen darüber, ob SHA256, SHA512 verwendet werden soll. Sollten Sie hash_hmac verwenden? Einige sagen ja: ( http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/ ) Einige sagen, dass die Verwendung von Bibliotheken die einzige ist sicherer Weg ... und dann ein- oder zweimal in einem Beitrag habe ich gelesen, Bibliotheken nicht als bcrypt oder Bubble Fish zu verwenden?

Ist es wirklich notwendig, eine Bibliothek zu benutzen oder ist z. eine Methode wie diese genug:

function hash_password($password, $nonce) {

  for ($i = 0; $i < 5000; $i++) {
    $hashed_pass = hash_hmac('sha512', $hashed_pass . $nonce . $password, $site_key);
    }
  return $hashed_pass;
}

Viele Leute sagen, erfinden Sie nicht Ihr eigenes Algo, deshalb habe ich ein bisschen Angst, nur etwas zu verwenden, das selbst erfunden wurde.

Ich kann mir vorstellen, dass es schwer vorherzusagen ist, aber wie lange kann eine Methode, die heute verwendet wurde, als sicher genug angesehen werden?

UPDATE: Vielen Dank für Ihr großartiges Feedback. Wie ich sehe, fehlt ein Hauptpunkt, und viele von Ihnen sagten: Passwortsicherheit, dh ein sicheres Passwort ist die Grundvoraussetzung. Ich glaube ich habe die Nachricht bekommen, nochmals vielen Dank! :) :)

UPDATE 2: Nur zur Vervollständigung habe ich folgenden Code auf http://www.lateralcode.com/creating-a-random-string-with-php/ gefunden, mit dem ich ein zufälliges Salz generiere ::

function Rand_string( $length ) {
    $chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!§$%&/().-:;_#+*[]{}="; 

    $size = strlen( $chars );
    for( $i = 0; $i < $length; $i++ ) {
        $str .= $chars[ Rand( 0, $size - 1 ) ];
    }

    return $str;
}

$random_salt= Rand_string(20);
47
Chris

Allgemeine Informationen :

Schöne Frage, aber alles was ich sagen kann ist, dass es total von der Verwendung abhängt. Wenn Sie es nur für eine kleine Website verwenden, besteht eine hohe Wahrscheinlichkeit, dass nur "Script Kiddies" Sie besuchen. In diesem Fall reicht auch heute ein einfacher SHA1 mit Salz völlig aus. In diesem Fall sind 5-8-10 Jahre oder sogar noch mehr absolut gut. Script-Kiddies werden nicht wirklich einbrechen, wenn sie sehen, dass sie nicht einfach einbrechen können. Wenn Ihre Site aus irgendeinem Grund angegriffen wird - Geld-Site usw. - sollten Sie die neuesten verfügbaren Funktionen verwenden. In diesem Fall würde ich sogar "riskieren", eine nicht offizielle, aber bereits portierte Funktion zu verwenden. Im Moment gibt es einen SHA3-Wettbewerb, für Websties, die viel Geld enthalten, würde ich einen der 5 Konkurrenten dieser verwenden.

Die Punkte, die ich sage, sind wichtig :

1. benutze ein zufälliges Salz, vielleicht sogar 20 Zeichen. Es macht es viel schwieriger, Passwörter zu knacken, und selbst wenn sie zerbrechlich sind, dauert es zu lange, bis sie es wert sind.
2. benutze SHA-1, SHA-2 oder WHIRLPOOL. Mit gutem Salz ist MD5 auch in Ordnung, aber ich schlage diese immer noch vor.
. Sie können jede gute Kryptographie verwenden, wenn die Passwörter der Benutzer trivial sind. Sie müssen sicherstellen, dass sie nicht wörterbuchbezogene, lange Passwörter mit Groß- und Kleinbuchstaben, Zahlen und Symbolen verwenden, da sie sonst leicht mit brutaler Gewalt zerbrochen werden können. Sie könnten in Betracht ziehen, dass sie gezwungen sein könnten, das Passwort jedes Jahr oder so zu ändern.

Zum Code :

Oftes Looping könnte nützlich sein, aber ich denke nicht, dass 5000 erforderlich sind. 3 für normale Sicherheit ist gut oder 100, vielleicht könnten 1000 funktionieren, aber ich denke 5000 ist einfach zu viel. SHA-256 ist gut, aber Sie können einen speziell dafür entwickelten Algorithmus verwenden, siehe Kommentare.

2
axiomer

Sie haben nur eine Kleinigkeit vergessen:

Passwortstärke.

Nur 2 Wörter, die Ihr brillantes Thema übergewichten.

Es gibt in der Tat Hunderte von Themen zu Stackoverflow, die Ihnen sagen, dass Sie diesen oder jenen Hashing-Algorithmus und zufällige Salze verwenden sollen.
Und nur sehr wenige, die erklären, dass mit einem schwachen Passwort alle Ihre acht Elemente Listenschutz, alle extra sicheren Hmac-Chmak-Bumblemak-Hashes mit 2048 Bytes langem Salz in Sekundenschnelle gebrochen werden.

Was die armen Benutzer betrifft, die sich nicht erinnern können $#%H4df84a$%#R Passwörter - lassen Sie sie einfach kein Passwort verwenden, sondern eine Passphrase.

Is it a good day today, Winkie? Verwendet verschiedene Groß- und Kleinschreibung sowie ein Passwort mit empfohlener Komplexität, ist aber viel einfacher zu merken.

Natürlich sollte der Ausdruck nicht so häufig sein wie gängige Passwörter wie "Joe" oder "123".
"Guten Morgen", "Oh mein Gott! Sie haben Kenny getötet!" Sätze sollten vermieden werden.
Aber durch Hinzufügen einer Persönlichkeit wäre es in Ordnung:
Oh My God! They moved Cthulhu! sieht ganz gut aus

Eine andere Sache zu erwähnen ist eine sichere Kommunikation zwischen Server und Browser
Ohne dieses Passwort kann ein einfaches Passwort auf jedem der an der Kommunikation beteiligten Router leicht "abgehört" werden.

SSH oder eine Implementierung von Digest-Autorisierung ist nicht weniger wichtig.

10

Eine Allzweck-Hash-Funktion (MD5, SHA1, SHA256) mit einem guten Hash ist angesichts der aktuellen Rechenleistung möglicherweise für die meisten kleineren Websites sicher genug. Das Gesetz von Moore wird jedoch sicherstellen, dass auch gute Passwörter in naher Zukunft Brute-Force-Angriffen ausgesetzt sind. Das Problem ist, dass Hash-Funktionen viel zu schnell berechnet werden können. Die beste Lösung ist die Verwendung von bcrypt oder PBKDF2 mit einer hohen Anzahl von Iterationen. Bcrypt vs PBKDF2 wurde unter http://security.stackexchange.com besprochen.

Einige Leute denken vielleicht, dass dies für die meisten Websites übertrieben ist, aber denken Sie daran, dass Passwörter ständig wiederverwendet werden und dass das Speichern von Passwörtern normalerweise erst geändert wird, wenn ein Problem auftritt.

Empfehlungen:

  1. Verwenden Sie bcrypt oder PBKDF2. VERWENDEN SIE KEINE SHA3-Kandidaten. Sie können Sicherheitslücken enthalten, die noch nicht entdeckt wurden.
  2. Verwenden Sie ein zufälliges Salz, um sich vor Angriffen auf den Regenbogentisch zu schützen.
  3. Benutzer zwingen, eine Passphrase auszuwählen.

Weitere Informationen

5
tony

Die Funktion hash_hmac() wäre eine gute Wahl, sie kann sogar Probleme eines schwächeren Hash-Algorithmus überwinden. Das einzige Problem ist, dass es auch schnell ist. Das bedeutet, dass bei ausreichender CPU-Leistung (Cloud) die Erstellung verschiedener Rainbow-Tabellen möglich ist. Dies ist der Grund für die Iteration. Wenn Sie diese hohe Sicherheit benötigen, können Sie die Zeit messen, die Ihre Iterationen benötigen, und dann die Anzahl der für eine bestimmte Zeit erforderlichen Iterationen berechnen.

Bearbeiten:

Durch Iterieren kann dieses Problem gelöst werden. Es sollte so erfolgen, dass die Anzahl der Iterationen später erhöht werden kann, ohne dass vorhandene Hashes ungültig werden. Dies ist erforderlich, um sich an neue zukünftige Hardware anzupassen, erfordert jedoch das Speichern der Hashing-Parameter zusammen mit dem Hash.

Der bcrypt-Hash-Algorithmus wurde entwickelt, um diese Anforderungen zu erfüllen. Ich habe ein kleines Beispiel für die Verwendung von bcrypt mit PHP 5. , ich habe versucht, es zu kommentieren, damit man es kann Verstehe, was los ist.

2
martinstoeckli