web-dev-qa-db-ja.com

クライアント側のハッシュのためのPBKDF2強力なソルト

ログイン前にソルトを使用できない場合、PBKDF2ハッシュのセキュア/強力なソルトとして何を使用する必要がありますか？それは、PBKDF2でユーザー+パスをハッシュするクライアント側のJavaScriptになるためです。 pbkdf2のソルトとしてsha（user + pass）を使用します。

ランダムに生成されたソルトを使用する場合、DBに保存する必要がありますが、ユーザーがログインしたい場合、ユーザーはソルトを使用してパスワードをソルトで暗号化してから、検証のためにサーバーに送信します。

それで、ここで良い/安全な/安全なソリューションは何ですか？追伸「知識ゼロ」のプロトコルを達成しようとしています。また、SSLをすでに使用しています。

encryptionauthenticationcryptographyhash
6
JustACPPFan

まず、最後の段落に特に注意を払いながら、 「クライアント側のパスワードのハッシュ化」に対するこの回答 を必ず読んでください。

また、クライアント側のjavascriptは、優れたサーバー側のコードと比較してPBKDF2で非常に遅くなることに注意してください。少なくとも、HMAC-SHA-512をベースとして使用するPBKDF2実装を見つけてください。

とはいえ、ユーザーに安心を与えたい場合は問題ありません。以下をせよ：

  • 既知の「高い」反復回数に対するクライアント側のPBKDF2ハッシュ。
    • ユーザーが反復回数を自分で選択できる場合は、2倍のボーナスポイント！
    • 特に安価なモバイルデバイスでは、十分な数のユーザーベースを受け入れることができる時間内に数千または数十万回の反復を実行するのに十分な速度でJavaScriptコードが実行されるとは思えないので、引用符を高くしました。
    • ユーザー名とパスワードをソルトとして適切にハッシュ化するのは良いことではありませんが、コードでユーザー名を可能な限り長い長さにして最初に配置する方がよいでしょう。
      • このように、「user1」と「password」は「user」と「1password」と同じソルトを作成しません！
      • もちろん、バックエンドソフトウェアによるものを除いて、パスワードに最大長はありません。たとえば、SQL Serverは、「非効率的な」文字列処理で最大8000バイトです。
  • そのハッシュをサーバーに送信します
    • 次に、暗号的にランダムな12-16バイトのソルトを生成します
    • そして、渡されたハッシュをハッシュするために、はるかに高い反復カウントでPBKDF2を使用します
      • ここでも、64ビット操作用のHMAC-SHA-512がオフラインGPU攻撃の比例する利点を減らすことを願っています。
      • そのため、漏洩したパスワードデータベースを入手したユーザーは、盗んだクライアントが生成したハッシュを送信してそのまま受け入れるのではなく、パスワードハッシュ関数に対する攻撃の作業を実行してログインする必要があるためです。

特にPBKDF2パスワードハッシュでは、ネイティブベースハッシュの出力サイズより大きい出力サイズを要求しないでください。ストレージについて本当に心配しているのであれば、小さい方でも大丈夫です。たとえば、32バイトのPBKDF2-HMAC-SHA-512のネイティブ64バイト出力のみを要求します。

  • SHA-1の場合は20バイト
  • SHA-256の場合は32バイト
  • SHA-512の場合は64バイト
7
Anti-weakpasswords