Wenn es nicht sicher ist, ist Ihre Hash-Funktion reiner Junk, und Sie sollten sie nicht verwenden.

Bei jeder anständigen Sicherheitsanalyse wird davon ausgegangen, dass der Angreifer bereits die gesamte Software kennt, die Sie verwenden verwenden, weil:

• Es gibt nicht so viele Möglichkeiten.
• Aufgrund des Anwendungsverhaltens und der Ausgabe kann viel erraten werden.
• Ein Angreifer Wer einen Blick auf Ihre Datenbank werfen könnte, könnte auch eine Kopie Ihrer PHP-Skripte haben und somit weiß .
• Selbst in Fällen, in denen der Angreifer Ihre Hash-Funktion nicht kennt, ist dies der Fall Es ist sehr schwierig, einen solchen Mangel an Wissen zu quantifizieren: Inwieweit weiß der Angreifer nichts?
• Insbesondere kann sich der Angreifer auch als registrieren Benutzer mit einem von ihm gewählten Kennwort und beobachten dann den resultierenden Hash, sodass er jede potenzielle Hash-Funktion schnell testen kann.

Wenn Sie die verwendete Hash-Funktion explizit angeben, können Sie dies jedoch tun ein Ruf als "kompetenter Websitebesitzer", der Vertrauen schaffen würde an technisch versierte Kunden.

Aus rein technischer Sicht ist es sicher, Ihren Benutzern mitzuteilen, welchen Algorithmus Sie verwenden - solange der Algorithmus gut ist. Dies ist keine geheime Information, und der Versuch, sie zu verbergen, wäre ziemlich dumm.

Wenn Sie jedoch eine große Ankündigung machen, die Sie beispielsweise bcrypt verwenden, kann dies nach hinten losgehen. Ihre Benutzer könnten versucht sein, noch schwächere Passwörter zu wählen, vorausgesetzt, Ihr magischer Hash-Algorithmus schützt sie in beiden Fällen. Tatsächlich gab es auf dieser Website mehrere Fragen, bei denen die Leute tatsächlich glaubten, dass die Verwendung von bcrypt die Kennwortstärke völlig irrelevant macht. Dies ist natürlich nicht der Fall. Sie müssen also sehr vorsichtig sein, um Ihren Benutzern kein falsches Sicherheitsgefühl zu vermitteln.

Lange Rede, kurzer Sinn: Es ist in Ordnung, jedem zu sagen, der interessiert ist und (hoffentlich) versteht, dass er noch ein gutes Passwort benötigt. Aber ich würde keine große Nachricht in das Registrierungsformular einfügen. Menschen können daraus die falschen Schlussfolgerungen ziehen.

Ich würde sagen, dass es sicher ist, solange der von Ihnen verwendete Hashing-Algorithmus sicher ist. Andernfalls kann dies einen Anreiz darstellen, Ihre Datenbank zu durchsuchen.

Als Benutzer muss ich zugeben, dass mir die Transparenz der Websites, auf denen ich mich registriere, hinsichtlich der Speicherung der Anmeldeinformationen nichts ausmacht . Weniger technisch orientierte Benutzer sind jedoch möglicherweise überrascht und / oder verfehlen Ihren Standpunkt. Stellen Sie daher sicher, dass sich Ihre Zielgruppe um diese Informationen kümmert.

In jedem Fall hängt die Stärke Ihres Kennwortschemas nicht davon ab überhaupt geheim - es beruht darauf, dass die Kryptographie einer Peer-Review unterzogen wird. Daher sollte es keine Rolle spielen, anzugeben, welchen Algorithmus Sie verwenden.

Es ist sicher, wenn Ihre Hash- / Key-Stretching-Algorithmen sicher sind, aber es ist nicht notwendig und wahrscheinlich keine gute Idee. Ich würde vorschlagen, den Benutzern vage mitzuteilen, wie Ihre Passwörter gespeichert sind (z. B. "Key Stretching, das mehrere Iterationen einer Einwegfunktion enthält" ), aber das nicht zu erwähnen exakter Algorithmus.

Das Hashing der Hashing-Methode (oder sogar der gesamten Authentifizierungsmethode) ist eine Instanz von Sicherheit durch Dunkelheit , die normalerweise verpönt wird. Meistens ist dieses Stirnrunzeln jedoch auf ein Missverständnis zurückzuführen, ähnlich wie die Leute Hoares Zitat zur vorzeitigen Optimierung häufig als "nicht optimieren" falsch interpretieren.
Sicherheit darf nicht von Dunkelheit allein abhängen. Dunkelheit am richtigen Ort kann jedoch sicherlich zur Sicherheit beitragen.

Ein kryptografischer Algorithmus muss zuverlässig funktionieren, auch wenn der Angreifer alle Details des Algorithmus kennt und davon ausgegangen wird, dass er dies tut. Aus diesem Grund werden kryptografische Algorithmen normalerweise vollständig offengelegt, und niemand wird einem "geheimen" kryptografischen Algorithmus vertrauen.

Ihre Sicherheitsstrategie muss ebenfalls eine vollständige Offenlegung als Worst-Case-Szenario voraussetzen, und Ihr System muss weiterhin zuverlässig funktionieren In diesem Fall.
Dies bedeutet jedoch nicht, dass Sie unbedingt jedes Detail offenlegen müssen.

Sagen Sie Ihren Benutzern auf hoher Ebene vage, wie Ihre Strategie zur Kennwortspeicherung lautet kann dem Benutzer einen guten Eindruck vermitteln, bringt Sie jedoch nicht auf etwas Besonderes ein (einschließlich möglicher Haftungsprobleme, auf die schroeder in einem Kommentar oben hingewiesen hat). Sicherheit kann sowohl eine Möglichkeit sein, einen Angreifer abzuschrecken als auch zu verzögern.

Ein bisschen Unklarheit über den genauen Algorithmus ist beides , wenn Sie einen großen, markanten Türriegel mit einem versteckten, geschützten Schlossschlitz an Ihrer Vordertür anbringen um Ihr Geld in den Safe zu legen, bevor Sie Ihr Hotelzimmer verlassen.
Ein großer Riegel mit einem versteckten, geschützten Schlitz ist wahrscheinlich nicht viel sicherer als ein billiges Schloss, da Sie die Tür einfach mit einem Vorschlaghammer niederschlagen oder trotzdem einen Felsbrocken durch die Gartentür werfen können. Es sagt einem potenziellen Einbrecher jedoch, dass Sie vorsichtig sind und dass andere Sicherheitsmaßnahmen , von denen er nichts weiß , wahrscheinlich sind und es wahrscheinlich weniger schwierig ist, in ein anderes Haus einzubrechen. Unter diesem geschützten Schloss befindet sich möglicherweise nicht einmal ein Riegel, und es dient weiterhin seinem Zweck.
Ein Hotelsafe nimmt normalerweise 4 Nummern an (und gelegentlich hat der Hotelmanager vergessen, den Notfallcode von 0000 code zu ändern > auch). Fingerabdrücke ermöglichen es einem Dieb trivial, den Safe in weniger als 3 Minuten zu öffnen. Das ist also in der Tat nicht sehr sicher. 3 Minuten sind jedoch eine Ewigkeit für einen Einbrecher eines Hotelzimmers. Jede weitere Minute birgt das Risiko, erwischt zu werden. Sie bleiben selten länger als insgesamt 3 Minuten in einem Zimmer. Dies bedeutet, dass der unsichere Safe im wahrsten Sinne des Wortes sicher ist, verglichen mit Ihrem Geld und Ihrer Rolex auf dem Tisch, einfach weil die Objekte etwas verdeckt und zurückgehalten sind.

Ähnlich verhält es sich mit einem Online-Angreifer. Obwohl es unwahrscheinlich ist, dass Sie das Eindringen während des Vorgangs entdecken, steht dem Eindringling dennoch weniger Zeit zur Verfügung, da er nicht nur die Kennwortdatenbank herunterladen, sondern auch den "geheimen" Hashing-Algorithmus und die Salze herausfinden muss . Es mag nicht viel Zeit sein, aber es kostet dich nichts. Warum verschenken?

Wenn Sie einem Angreifer mitteilen, dass Sie MD5 zum Hashing Ihrer Kennwörter verwenden, weiß er sofort, dass er Ihre gesamte Benutzerdatenbank in weniger als 2 Sekunden knacken kann, und Sie sind höchstwahrscheinlich nicht sehr auf dem neuesten Stand der Sicherheit Insgesamt bedeutet dies, dass Sie ein sehr attraktives Ziel sind. Wenn Sie einem Angreifer mitteilen, dass Sie ein "Key-Stretching-System mit vielen Iterationen" verwenden, kann er sich vorstellen, dass es wahrscheinlich ein erheblicher Arbeitsaufwand ist, auch nur ein einziges Kennwort zu knacken. Außerdem ist es zusätzliche Arbeit, herauszufinden, welchen Algorithmus Sie genau verwenden.
Wenn Ihre Site nur eines auf einer Liste von 20 interessanten Angriffszielen ist, ist sie gerade an den unteren Rand der Liste gerückt.

Wenn der Hash sicher ist und, was noch wichtiger ist, die Verwendung in der Site / Anwendung sicher ist, sollten Sie in der Lage sein, den gesamten Code, auf dem die Site / App ausgeführt wird, als Open Source zu verwenden, und Sie sollten nicht weniger sicher sein.

Ja, WENN die Implementierung sicher ist, ist die Offenlegung sicher. Das ist eine große WENN .