Facebookがパスワードをハッシュする方法

Question

私はこれを発見しました presentation Facebookが顧客のパスワードをどのように保存し、どのように認証を行うか。

このスライドは、パスワードをハッシュする方法を示しています。

生のパスワードを使用してこのような操作を行うことは良い考えですか？「あいまいさによるセキュリティ」ではないでしょうか。このような操作をPBKDF2を使用して行うのは理にかなっていますか？

Future Security · Answer

あなたが書いたコメントの一つで：

2018年に、このようなことが理にかなっているかどうかを尋ねています。8バイトのソルトでPBKDF2 HMAC-SHA-256を使用し、ハッシュスキーマの使用方法について説明します。

その答えはノーです。 FaceBookソリューションから複製する必要がある唯一の部分は、メモリハード機能と暗号化サービスペパーリングを使用することです。 MD5およびHMACパーツはセキュリティを向上させません。（ただし、それらはかなり無害です。）

PBKDF2は使用しないでください。あなたが好むはずですために：

Argon2 の公式のネイティブ最適化実装へのバインディングの使用
- パラメータの選択方法については、 Argon2仕様の「推奨パラメータ」セクションを参照してください。
- Argon2d、Argon2i、およびArgon2idの選択は、議論の余地があるかもしれません。現在の公式の推奨は、どれを選択すべきかわからない人のためのArgon2iです。
あなたが選択できるようにソフトウェアを更新してください1
パスワードを使用して暗号化されたデータを保護し、Argon2を使用できませんか？ネイティブの最適化されたscrypt実装へのバインディングを使用します。 RAM=と時間を多く使用するのに十分な高さの単一コストパラメータを設定します。時間を短縮しても安全と思われる場合は、scryptの実行を再検討します。これにより、RAMベースのコストも削減されます。
いくつかのパスワードを保護し、Argon2を使用できず、遅い応答を許容できますか？ 4と同じコストパラメータでscryptを使用します。管理者アカウントを保護しようとしている場合は、非常に強力なパスワードと暗号化を最初に使用することを優先します。
多くのユーザーのアカウントパスワードを保護し、Argon2を使用できませんか？ネイティブに最適化されたbcryptへのバインディングを使用するライブラリを使用します。ライブラリが元のbcryptアルゴリズムの癖のすべてを正しく処理することを確認してください。（パスワードが長すぎるか、ヌル文字が含まれている場合、パスワードは切り捨てられます。）
ネイティブ最適化PBKDF2へのバインディングを使用します。基になるハッシュ関数の出力長よりも大きい派生キーの長さを使用しないでください。
独自のパスワードハッシュ関数を実装しないでください。そして、特にそれがはるかに遅くなるインタプリタでその実装を実行しないでください。更新！

FaceBookメソッドが無名によるセキュリティかどうかも。いいえ。しかし、HMACパーツとおそらくMD5パーツは冗長です。 cryptoserviceパーツはおそらくHSMを使用しています。これにより、パスワードハッシュデータベースを盗むタイプのハッカーに暗号化キーを公開することなく、パスワードハッシュを暗号化/復号化できるようになります。秘密鍵で主流の暗号化アルゴリズムを使用することは、不明瞭とは見なされません。キーが漏洩した場合に備えて、パスワードをハッシュ化する必要があります。それがscryptの目的ですが、今はArgon2が推奨されます。

編集：コメントを参照してください。スライドに示すように、パスワードは暗号化されません。 HMACは、ハッシュと同様に1つの方法です。ハッシュ後の暗号化の代替手段は、キーを置き換えることができるため便利です。このFaceBookセットアップでキーを変更する場合、saltまたはscryptパラメータに加えて、ユーザーはパスワードを入力する必要があります。ハッシュを暗号化すると、ユーザーがパスワードを入力しなくても、ハッシュを復号化して再暗号化できます。（キーが漏えいした場合...しかし、元のキーがないとパスワードを再ハッシュすることはできません。）

また、20バイトのソルトを使用します。または少なくとも16。

eckes · Answer

この「タマネギ」構造は危険な場合があり、十分なレビュアーがいる場合にのみ実行する必要がありますが、単純なハッシュと比較して複数の好ましいプロパティが追加されます。

最初の無塩MD5は、クライアントまたはフロントエンドサーバーで実行できます。文字セットと長さを正規化し、CPUに負荷をかけすぎずに初期の段階でパスワードを難読化します。

ソルトはユーザーデータベースから読み取られるため、クライアントには存在しません。これが最初のHMAC追加です。

暗号化サービス（またはより優れたHSM）は、ブルートフォースから保護します（秘密鍵が不明であるため）。実際、これは、これを正確に行うためのNIST推奨よりも古いものです。複雑なシステムセットアップ（HSMまたはプロセスの分離）を必要とするため、このペパリングはあまり行われません。

ペッパーステップは内部関係者によって危険にさらされる可能性があるため、データはscryptに渡されます。これは、パスワードのブルートフォーステストをより高価にするために設計された機能です。

最後のステップは必要ないかもしれません、または多分それはいくつかの多様化を追加するために使用されます（SHA1の代わりにSHA2）。

ヘビオイルのやり過ぎに少し似ていますが、手順は合理的に説明できます。（はるかに弱い）glibc-SHA2 Voodooと比較すると、本当にきれいです。

ところで、覚えやすいオーセンティケーターは一般的に悪いことです。そのようなスキームはそれらを処理するリスクを減らすことができるだけです。

BTW2：SHA1の衝突の弱点はHMACコンストラクトには適用されず、短いMD5ハッシュサイズはここではあまり問題になりません（パスワードのエントロピーはほとんど常に低いため）。鍵の導出にはリスクが高くなりますが、それは現在の課題ではありません。