Für den Anfang haben Sie Ihren eigenen Passwort-Hashing-Algorithmus gerollt. Derzeit gibt es nur drei Kennwort-Hashing-Algorithmen, die als sicher gelten:

• PBKDF2
• scrypt
• bcrypt

Sie iterieren und fügen ein Salz hinzu. Sie scheinen auch den Benutzernamen innerhalb des Algorithmus hinzuzufügen, was keinen Vorteil bringt, da Sie bereits ein Salt verwenden.

Was ich nicht von Ihrem Code abziehen kann und was sehr wichtig ist, ist die Länge Ihres Salzes und wie Sie es erzeugen. Ein Salt sollte niemals fest codiert, sondern sicher zufällig generiert werden, wenn das Passwort gehasht wird. Das Salt sollte innerhalb der Datenbank eindeutig und vorzugsweise global eindeutig sein, um die Identifizierung ähnlicher Passwörter in verschiedenen Datenbanken zu vermeiden (daher wird ein Benutzername nicht als gutes Salt angesehen).

Die Funktionsweise von PBKDF2 (die Ihrer Implementierung am nächsten kommt) besteht auch in der Verwendung eines HMAC, bei dem das zufällig generierte Salt der Schlüssel zur Berechnung des Nachrichtenauszugs ist, anstatt alles zusammenzufügen. PHPs password_hash verwendet den bcrypt-Algorithmus.

Um zusammenzufassen, was Sie durch die Verwendung eines Standardalgorithmus anstelle Ihres eigenen Algorithmus erzielen:

• Sie generieren zufällige Salze
• Sie verwenden einen standardisierten und sicheren Passwort-Hashing-Algorithmus

Unter der Annahme, dass etwas Salz tatsächlich nie wiederholt wird, ist dies eine akzeptable Methode zum Hashing von Passwörtern. Es kombiniert die drei wesentlichen Elemente: keine Wiederherstellung des Hash aus den Passwörtern (dank der Verwendung von SHA-512), intrinsische Langsamkeit (aufgrund der hohen Anzahl von SHA-512-Iterationen) und ein einzigartiges Salz.

Das Salt muss global eindeutig sein: Es darf nicht zum Hashing anderer Kennwörter, zum Hashing des gleichen Kennworts bei einer Kennwortänderung oder in der Kennwortdatenbank eines anderen Benutzers verwendet werden. Die Verletzung der Eindeutigkeit ist nicht unbedingt kritisch, aber je mehr es passiert, desto einfacher wird es für einen Angreifer. Im Extremfall ist das „Salz“ konstant, es ist kein Salz und Ihre Passwort-Hashing-Methode ist schrecklich. Wenn es sich um den Benutzernamen oder die Datensatz-ID handelt, ist dies immer noch schlecht, da mehrere Datenbanken einen kleinen Satz Salze gemeinsam nutzen.

Sie sollten jedoch eine Standard-Hashing-Methode verwenden. Möglicherweise liegt eine Sicherheitslücke in Ihrer Methode vor, die wir übersehen haben, weil sie auf subtilen Details beruhte. Möglicherweise haben Sie bei der Implementierung einen Fehler gemacht. Aus diesem Grund ist eine gut unterstützte Implementierung mit Sicherheitsupdates vorzuziehen. Im Algorithmus kann eine Schwäche entdeckt werden. Auch hier ist es besser, eine gut unterstützte Implementierung zu verwenden, deren Implementierer über Kryptografienachrichten auf dem Laufenden bleibt und den Algorithmus bei Bedarf ändert.

Sie müssen darauf achten, die Anzahl der Iterationen mit der Zeit zu erhöhen vergeht und Computer werden schneller. Ein gutes

Lesen Wie man Passwörter sicher hasht? (ja, alles). Bcrypt ist PBKDF2 etwas überlegen, da es resistenter gegen GPU-basierte Angriffe ist. PBKDF2 folgt denselben Prinzipien wie Ihr benutzerdefinierter Hash. Die Verwendung von PBKDF2 ist derzeit keine große Sicherheitsanfälligkeit, ich würde jedoch empfehlen, auf bcrypt oder scrypt umzusteigen.

Ihr Algorithmus ist meilenweit besser als viele "Homebrew" -Algorithmen. Der Grund, warum ich immer noch zu einem standardisierten wechseln würde, ist, dass Sie von all der Prüfung profitieren, die diese Standards erhalten haben, die Ihre eigene Konstruktion nicht hat.

Gibt es definitiv keinen Fehler in Ihrer Konstruktion, der dies zulässt eine triviale Pause? Wenn nicht, sind Sie sicher, dass Ihr Algorithmus nicht für einen beschleunigten Brute-Force-Angriff mit massiv parallelen GPUs anfällig ist? Könnte es eine optimierte Form des Regenbogentabellenangriffs auf Ihren speziellen Algorithmus geben?

Die Antwort lautet wahrscheinlich nein, nein und nein, aber mehr Leute haben sich mit PBKDF2 befasst als mit Ihrem Algorithmus, sodass es weniger wahrscheinlich ist, dass es etwas gibt böse, dass bisher niemand entdeckt hat. Dies ist ein heuristisches Argument, aber vergessen Sie nicht, auch wenn Ihr Algorithmus gut ist (und für mich sicherlich nicht dumm aussieht), gibt es Hunderte anderer Leute, die ihre eigene Krypto implementiert haben, die sich als schrecklich kaputt herausstellte . Deshalb sagen wir in der Regel, rollen Sie nicht Ihre eigenen.

Es ist der gleiche Grund, warum wir nicht jedem erlauben, elektrische Hochspannungsanschlüsse zu installieren und zu modifizieren: Die Qualifikation eines Elektrikers reicht nicht aus. Es schützt Sie auf magische Weise vor Stromschlägen, aber es bedeutet, dass Sie hoffentlich genug Erfahrung in der Gegend haben. Tun Sie nichts zu Dummes, als einen zufälligen Draht zu ergreifen und zu sehen, ob er unter Spannung steht oder nicht.

Ein Nachteil beim Einfügen des Benutzernamens als Teil des Salt ist, dass Sie einen Benutzer nicht umbenennen können (z. B. administrativ), ohne einen neuen Kennwort-Hash zu generieren (was bedeutet, dass Sie ein neues Kennwort auswählen und dem Benutzer mitteilen müssen, oder Fragen Sie den Benutzer nach seinem aktuellen Passwort.

Ich sehe einige Probleme mit Ihrem Ansatz.

• Sie scheinen einen konstanten Salzwert zu verwenden. Es ist sicherer, für jedes Kennwort ein neues Salt zu generieren.
• Das Einfügen des Benutzernamens in das Salt kann problematisch sein. Wie Andrew betont hat, können Sie einen Benutzer nicht umbenennen. Es mildert das Problem teilweise mit einem konstanten Salz. Das Problem wird dadurch jedoch nicht vollständig gemindert, da sich der Benutzername nicht jedes Mal ändert, wenn sich das Kennwort ändert.
• Sie geben das Kennwort nur in die erste Iteration ein. Es besteht das theoretische Risiko, dass die Entropie aus dem Kennwort beim Iterieren langsam verschwindet.
• Eine hohe Iterationszahl kann Sie für DoS-Angriffe anfällig machen.

Die Iterationszahl ist doppelt so hoch Schwert. Eine hohe Anzahl von Iterationen macht Ihren Server anfällig für DoS-Angriffe. Eine niedrige Iterationszahl macht Ihre Kennwortdatenbank anfällig für Offline-Brute-Force-Angriffe. Die einzige Möglichkeit, sich vor beiden zu schützen, besteht darin, einen Teil der Berechnung auf den Client zu verlagern. Dies erfordert jedoch Code auf dem Client. In einem Webdienst könnte ein solcher Code per Javascript bereitgestellt werden, aber Javascript ist nicht so schnell wie nativer Code, sodass der Angreifer einen Vorteil gegenüber der legitimen Verwendung hätte.

Zunächst einmal haben Sie aus Sicht der Passwortsicherheit einen ziemlich guten Algorithmus.

Ihr Salt ist technisch gesehen kein Salt, da es für jeden Benutzer gleich ist, aber wenn Sie es mit dem kombinieren Benutzername Es ist eine einzigartige Information, so dass Sie die vollständige Sicherheit eines Salzes haben. Wenn Ihre "etwas Salz" -String kryptografisch stark ist (mindestens 64 Bit Entropie), funktioniert sie auch als Pfeffer.

Aus praktischen Gründen würden Sie dies tun Im Allgemeinen möchten Sie vermeiden, den Benutzernamen im Kennwort-Hash-Algorithmus zu verwenden, da dies das Ändern des Benutzernamens erschwert und Sie für den Vorgang das Nur-Text-Kennwort benötigen. Ein dediziertes Salt ist einfacher zu verwalten.

Eine Million Hashing-Iterationen scheinen etwas übertrieben zu sein. Es könnte leicht zum Engpass einer geschäftigen Website werden. Ich würde es auf ein Niveau reduzieren, das Sie tun können Mindestens 1000 Kennwort-Hashes pro Sekunde.

Stellen Sie außerdem sicher, dass Sie über einen Mechanismus zum Drosseln von Anmeldeversuchen verfügen. Wenn ein Angreifer einfach 1000 Anmeldeversuche pro Sekunde brennen kann, kann er schnell viele schwache Kennwortbenutzerkonten stehlen oder er kann das Passwort-Hashing als Denial-of-Service-Waffe verwenden.

Ich glaube, es gibt keine allgemein anerkannten Best Practices für die Drosselung von Anmeldungen, außer dass keine Drosselung die schlechteste Lösung ist .