Blowfishの代わりにWeb認証用のSha1-Hashing

Question

Blowfishの動作PHP/JavaScriptの実装を見つけることができないので、SHA1ハッシュを使用してWebベースの認証を実装することを検討していますが、この特定の分野に知識が不足しているため、選択した方法が十分に安全かどうかはわかりません。

計画されたロードマップ：

1. ユーザーのパスワードは、サーバーにMD5ハッシュとして保存されます。
2. サーバーは公開キーを発行します（現在の時間のMD5ハッシュはミリ秒単位で）
3. クライアントJavaScript関数はユーザーパスワードを入力として取得し、そのMD5ハッシュを計算します
4. その後、クライアントは上から公開キーとパスワードのハッシュを連結し、結果の文字列のSHA1を計算します
5. クライアントはSHA1ハッシュをサーバーに送信します。ここでは、公開キーとユーザーのパスワードMD5ハッシュで同様の計算が実行されます。
6. サーバーはハッシュを比較し、一致は認証が成功することを示します。
7. 不一致は認証障害を示し、サーバーは新しい公開キーを発行し、既に使用されているものを事実上有効にします。

さて、問題のある部分は、SHA1の前に2つのキーを連結することですが、それは何らかの統計的または他の攻撃に起因する可能性がありますか？

全体的な品質を向上させるためにキーを連結する必要がある特定の順序はありますか（つまり、暗号化の信頼性により高いビットがより重要です）？

前もって感謝します。

Answer 1

「公開鍵」のみを使用している場合（実際には公開鍵ではありませんが、 nonce, 、そして本当にランダムでなければなりません、あなたが本当にそれを特定の時間枠で使用できるようにしたいのでない限り、その場合、あなたが必ず使用してください hmac それを生成するための秘密の鍵があるので、敵はできません Nonceを予測します）防止する リプレイ攻撃, 、そしてそれは固定サイズであり、連結は問題ではないかもしれません。

とはいえ、私はあなたがよく考えられているセキュリティモデルを持っていないかもしれないことを少し心配しています。とにかく、これはどのような攻撃を防止しようとしていますか？ユーザーのパスワードハッシュは塩分がないため、パスワードデータベースのブレークはとにかく簡単にプレーンテキストパスワードを明らかにします。とりあえず。そういえば、タイムスタンプベースのシステムの代わりに、セッションキーをノンセとして使用するだけではありませんか？

しかし、本当に、なぜSSLを使用しないのですか？暗号化はです とても大変 正しく、そしてあなたや私よりもはるかに賢い人々は、それを正しくするためにSSLのセキュリティをレビューするために何十年も費やしてきました。

編集: ：MITM攻撃が心配な場合は、SSL以外の攻撃が救われることはありません。限目。 Malloryは、Super-Secureログインフォームを、Plantextのパスワードを彼に送信するものに置き換えることができます。 ゲームオーバー。 そして、受動的な攻撃者でさえ、すべてがワイヤーを越えているのを見ることができます - セッションクッキーを含む. 。イブがセッションクッキーを持っていると、彼女はそれをブラウザに注入するだけで、すでにログインしています。 ゲームオーバー。

SSLを使用できないと言う場合は、保護しようとしているものと、どのような種類の攻撃を軽減するかを正確に確認する必要があります。おそらく、暗号化を行うために何らかの種類のデスクトップアプリケーションを実装する必要があるでしょう - MITMが回っている場合、HTMLまたはJavaScriptを信頼することはできません。Malloryは自由に置き換えることができます。もちろん、デスクトップアプリは、データストリームにキー交換、暗号化、認証を実装する必要があります。 まさにSSLが行うこと. 。そして、あなたがそれを正しく行うなら、おそらくSSLとほぼ同じアルゴリズムを使用するでしょう。

MITMSが範囲にないと判断したが、パッシブ攻撃から保護したい場合は、おそらくJavaScriptに深刻な暗号化を実装する必要があります - diffie-hellman セッションキーを生成するために交換します それはワイヤー全体に送られることはありません (HTML5 Webストレージ, など）、キーなどを保護するためのJavaScriptのAESなど、この時点でSSLの半分をJavaScriptに実装しましたが、その中にはより多くのバグがある可能性があります。 JavaScriptで安全な乱数を取得します。

基本的に、次のいずれかを選択できます。

1. 実際の暗号化セキュリティを実装していません（これらすべての複雑な認証プロトコルを実装しているため、明らかに選択肢ではありません）
2. SSLのようにひどく見えるものを実装することはおそらくそれほど良くありません
3. SSLを使用します。

要するに - セキュリティが重要な場合、 SSLを使用します. 。 SSLをお持ちでない場合は、 インストールしてください. 。私が知っているすべてのプラットフォームがJSを実行できることもSSLを処理できるため、言い訳はありません。

Answer 2

Bdonlanは絶対に正しいです。指摘したように、敵はJavaScriptフォームを邪悪なコードに置き換えるだけで、HTTPよりも些細なことです。その後、ゲームオーバーです。

また、適切な暗号乱数ジェネレーターを使用して生成された塩でパスワードをSHA-2に移動することを検討することをお勧めします（つまり、サーバーのクロックを使用してシードされていません）。また、ハッシュを複数回実行します。見る http://www.jasypt.org/howtoencryptuserpasswords.html セクション2および3。

MD5が壊れています。 MD5を使用しないでください。

安全なスキームは、次のように同様である必要があります。

1. すべてがSSLで発生します。 SSLがすべてのハードワークを行うため、認証フォーム、フォーム、画像などを検証するサーバー側のスクリプト、画像などを検証するスクリプト。 SSLがすべてを暗号化するため、「Plantext」でユーザー名/パスワードを提出する単純なHTMLフォームだけが本当に必要なものです。

2. ユーザーは新しいパスワードを作成します。ランダム塩を生成します（サーバー時間に基づいていませんが、良好な暗号ランダムソースから）。塩 +新しいパスワードを何度もハッシュし、データベースに塩と結果のハッシュを保存します。

3. パスワードを確認する：スクリプトはユーザーの塩を検索し、塩 +を何度も入力しました。データベースで一致を確認してください。

データベースに保存する唯一のものは、塩とハッシュ/ダイジェストです。

サポートする必要があるMD5ハッシュのデータベースがあると仮定すると、ソリューションは新しいSHA-2ハッシュと塩のデータベース列を追加することです。ユーザーがログインすると、行っているようにMD5ハッシュに対してチェックします。動作する場合は、「ユーザーが新しいパスワードを作成する」の手順に従ってSHA-2＆SALTに変換し、古いMD5ハッシュを削除します。ユーザーは何が起こったのかわかりません。

これから本当に逸脱しているものは、おそらくいくつかのセキュリティの欠陥があるでしょう。