クライアント側のsha1でn * x回またはsha512でn回ハッシュする方が良いですか？
ユーザーのパスワードをサーバーに送信する前に、sha512またはsha1のn * xでn回ハッシュすることをすでに知っています。サーバーに到着したら、bcryptセットを使用して〜1/100を使用します次に進む前に、sha1の代わりにsha512を使用する理由について説明します。まず、クライアント側のセキュリティは冗談であることを知っています。次に、Man-中間の攻撃により、ページのJavaScriptのハッシュ関数が剥奪される可能性があります最後に、これは、JavaScriptが有効になっていないと人々がログインできないことを意味します。
私は現在、ie8 [2]で〜1sを使用するように設定されたsha512を使用していますが、そのように設定されています。
- ユーザーのパスワードとユーザー名を取得します。
- Static-nonceを追加します（本当に長くするために、それ以外は何もしません）。
- ハッシュ関数でハッシュします。この場合はsha512です。
- そのハッシュを取り、現在のループ番号を1バイトにパックして、sha512でハッシュします。
- 手順4をn回繰り返します。
- 完了したら、その値を取得して、パスワードフィールドに入力します。
- 最後に、システムにPOST=サーバーへのアクセスを許可します。
それでは、sha1のn * xハッシュをn回のsha512に対して実行する利点は何でしょうか。このシステムを使用する背後にある重要な点は、データベースリークが発生した場合、攻撃者はパスワードの検索に費やす時間をz時間だけ増やす必要があることです。また、サーバーに到達する前に（TLSを使用して）ハッシュすることでハッシュが作成されるため、奇妙なバグが発生した場合に、パスワードがプレーンテキストとして表示されることはありません。
Sha512はすでに壊れたsha1が存在するため、より安全な選択であると私は信じています。 sha512 [1] []で見つけた最速のjavascriptライブラリはネイティブコードよりも50倍遅いですが、私が見つけた最速のsha1ライブラリはネイティブコードよりわずか17倍遅いだけです。
したがって、問題のあるのは、壊れたsha1が全体的なセキュリティの大きな損失を引き起こし、sha512の反復を減らすよりも攻撃者の速度を低下させるかどうかです。現時点では、sha2ファミリはリモートで壊れていません。他の誰かが以前にこの問題に対処したことがありますか？
[1]：ファジングにより、c実装/ phpと同じハッシュが生成されるため、最大300の入力に対して同じハッシュが生成されます。
[2]：ie10がリリースされてから1年後、ハッシュの数をより妥当なものに上げることができるように、ie8のサポートを終了したいと思います。
これは少し引き延ばされたように思えますが、逆効果かもしれません。 「パスワード」は実際にはプレーンテキストで表示されます。これは、パスワードが実際のパスワードの代わりに最終的に送信する文字列だからです。正確に何を達成しようとしていますか？
いずれにしても、「実際の」パスワードを「クリアテキストで表示されない」ようにしようとしている（そしてsslを信頼しない）場合は、チャレンジ/レスポンスプロトコルの実装を検討する必要があります。これは通常、パスワードが平文で転送されることを望まない場合（またはあなたの場合のようにパスワードに似ている場合）に行われる方法です。
計画を続行したいが、クライアント側で説明したトリックを実行したい場合は、SHA-1で十分です。 MD5でも問題なく、かなり高速です。これらの機能が安全でないことについての「通りの話」は衝突についてです-衝突はおそらく実装では気にしません。 http://www.jcryption.org/ もご覧ください。これは、htmlフォームの非対称暗号化を行うjqueryライブラリです。
しかし、繰り返しになりますが、この実装全体に対しては強くお勧めしません。
クライアント側のハッシュによって追加される保護は非常にわずかです。サーバーから見ると、ハッシュの結果isはパスワードです。サーバーは、実際のパスワードを要求せずに、そのハッシュ値を表示できる人にアクセス権を付与するためです。特に、「奇妙なバグ」の結果、ハッシュ値が攻撃者に明らかになる場合、あなたは負けました：攻撃者は、Javascriptを実行せずに、ハッシュ値を表示するだけでサーバーに接続できます（平均的なユーザーは、問題を回避できない可能性があります）少しJavascriptですが、攻撃者がもう少し能力がないと仮定するのは安全ではありません）。
保護が残っているのはifハッシュのみが表示され、攻撃者は（まだ）「実際のパスワード」を推測しておらず、同じパスワードを使用する他のサーバーでそのパスワードを（すぐに）試すことができないユーザーはアカウントも持っています。これはyourサーバーのセキュリティに何も変更を加えませんが、「コミュニティサービス」と見なすことができます。
複数のハッシュによって引き起こされる追加の攻撃コストに関しては、アイデアは確かですが、Javascriptを使用することはそうではありません。 Javascriptは、Cまたはアセンブリよりもはるかに低速です。 JavaScriptのIE8では1秒かかりますが、攻撃者にJavaScriptでの攻撃を強制するものはありません。彼はC、Assembly、おそらくGPUを使用するかもしれません。辞書攻撃を困難にしたい場合は、ハッシュを遅くする必要があります攻撃者にとって。クライアント上でJavascriptを使用することにより、適切なセキュリティを実現するために必要な回数だけ繰り返しを行うことができなくなります。これを確認する1つの方法は次のとおりです。攻撃者にとって、各「推測」が遅くなるようにします。残念ながら、「正直なシステム」でも遅くしない限り、攻撃者にとって遅くすることはできません。したがって、正直なシステム（クライアントまたはサーバー、あるいはその両方）のパフォーマンスは、注入できる遅延の量を制限します。クライアントで次善の言語でそれを行うことにより、我々は人為的にスローネスの負担をはるかに大きくします正直なシステムの場合であり、攻撃者のためではありません。
実際には、攻撃コストはbcryptのコストになります。ハッシュは比較すると無視できます。これは特に64ビット整数演算を使用するSHA-512に当てはまります。64ビット整数演算がないため、Javascriptでの実装が非常に遅くなります。したがって、あなたの質問に対する正確な答えは、SHA-1（またはSHA-256）を使用することは、目標が辞書攻撃の遅延を誘発することである場合、SHA-512よりも「優れている」ことです。しかし、それでも、サーバー側のbcryptが何をするかに関しては、引き起こされた速度低下は無視できるので、質問は一種の無意味です。一方、1秒の余分な遅延は、忍耐力がないことが知られている通常のユーザーを苛立たせます。