5

OK、これは奇妙な質問に聞こえるかもしれません。私に飛びつく前によく読んでください。;-)

次の状況を想像してください。

  1. サーバーとクライアントがあります。
  2. それらは SSL を使用して接続します。
  3. クライアントはパスワードを使用してサーバー上にアカウントを作成します。
  4. しかし、彼が実際にネットワーク経由でサーバーに渡すのは、パスワードのハッシュ (+salt) です (パスワードではありません)。
  5. サーバーは、この受信したパスワードのハッシュをDBに保存します（ソルトで再度ハッシュされます）
  6. ログオン時に、認証のために、ユーザーはパスワードのハッシュを再送信します (パスワードではありません!)。

わかりました、はい、これは奇妙に聞こえると思います。はい、会話全体が SSL で行われるため、パスワードのプレーンテキストを送信するだけでかまいません。はい、プレーンテキストのパスワードをハッシュ形式で安全に保存できることはわかっています。

私が推進しているポイントは次のとおりです。「あなたのパスワードを知ることはありません」と正直に言うことは、私たちのビジネスにとって有益です。

「パスワードをプレーンテキストで保存しない」と言っているわけではありませんが、実際には、決して、決してそれを知りません。あなたはそれを私たちに決して与えません。

(これが必要な理由は関係ありません。ユーザーのパスワードは、ファイルの暗号化などの他のものに使用されていると言えます)。

はい、これを行う通常の方法では、「ハッシュを行っている間、パスワードはメモリ内のプレーンテキストで5ミリ秒しか保持されない」と言うかもしれませんが、これは否定可能性に関するものです。つまり、100% パスワードを受け取っていないと言えます。

では、質問は次のとおりです。

  • この種のことを以前に行ったり聞いたりしたことのある人はいますか?

  • これを行うことの安全性への影響は何ですか？

マイナス面が見えず困っています。例えば：

  • リプレイ攻撃なし (会話は SSL を使用して暗号化されているため、攻撃者はハッシュを見ることができません)
  • ハッシュ自体がハッシュ化されているため、DB を参照できません。

OK、あなたは今私に飛び乗ってもいいです:)

感想、コメント大歓迎です。

ありがとう、

ジョン

更新: 明確にしたかっただけです: これが認証プロセスのセキュリティの何らかの形での改善であるとは提案していません。ただし、代わりに、サーバーからでも、ユーザーの「実際の」パスワードを秘密のままにすることができます。したがって、たとえばファイルの暗号化に実際のパスワードが使用されている場合、サーバーはそれにアクセスできません。

これが必要な理由には完全に満足しています。問題は、それが認証プロセスのセキュリティを妨げるかどうかです。

4

5 に答える 5

4

いくつかのことを考慮してください。

  1. クライアント側の何かがソルトとハッシュを決定する必要があります。
  2. (1) でハッシュを作成するものは、攻撃者にとって簡単に発見できる可能性があります。
  3. そのソルトとハッシュは一貫している必要があります。ソルトが変更されると、ハッシュも変更され、サーバーはそれをハッシュして元の状態に戻すことができなくなります。
  4. そのソルト + ハッシュは、基本的にユーザーの新しいパスワードになります。
  5. 元のパスワードがソルト + ハッシュよりも長い場合は、パスワードのセキュリティを低下させた可能性があります (適切なパスワードを想定し、ハッシュの衝突を無視します)。
  6. ただし、パスワードが貧弱な場合は、パスワードの品質を向上させただけかもしれません (ハッシュの衝突と上記の 1 と 2 を無視します)。

最終的に、salt + パスワードが新しいパスワードになります。全体として、私はほとんどの人に同意します。これを行うメリットはほとんどありません。

于 2010-01-27T17:18:34.720 に答える
3

このスキームには、言及されていない利点が 1 つあるように思われます (見逃した可能性があります)。確かに、ハッシュ + ソルトが実際のパスワードになると主張できます。ただし、パスワードを再利用するユーザーのセキュリティという点では、付加価値があります。私があなたのサイトで「asdfasdf」のパスワードを使用していて、誰かがあなたのサーバーを侵害した場合、彼らは私が dubdubdub.superfinance.com で使用している私のパスワードを抽出できなくなります。

于 2010-01-27T21:01:09.560 に答える
2

これは、パスワード ハッシャーが Web ブラウザーに対して行うこととまったく同じです。

あなたのアイデアに関して誰もが抱えている問題は、それが悪いアイデアだということではありません。あなたはクライアントとサーバーの両方の開発者であるため、サーバーではなくクライアントのコンピューターを信頼しても、実際の利益は得られません (結局のところ、クライアントはキーロガーなどを持っている可能性があります)。だからあなたの質問に答えるために：それはあなたにとって邪魔に過ぎません.

于 2010-01-27T20:54:20.513 に答える
1

上記の問題に加えて、別の問題があります。受け取った値を再度ハッシュしてソルトしない限り、基本的にすべてのパスワードを平文で保存していることになります。データベースへの読み取りアクセス権を取得した攻撃者は、すべてのユーザーとして簡単に認証できます。

于 2010-01-28T09:11:01.007 に答える
0

したがって、この時点では、実際にはまったく役に立ちません。どういうわけかあなたのSSLが危険にさらされていると仮定しましょう。彼らはハッシュされた+塩漬けのパスワードを盗聴します。次に、サーバーがハッシュ+ソルトパスワードをパスワードとして受け入れているので、それを送信できます。あなたがしているのは、複雑さの単一の層を追加することです（パスワードボックスにパスワードを入力することはできません）。その場合、彼らは手動でそれをサーバーにPOSTすることができます。

クライアント側で行われた場合は言うまでもなく、ハッシュアルゴリズムだけでなく、ソルトとそれをどのように組み合わせたかをクライアント側に渡します。

要約：私の心には大きなメリットはありませんが、間違っている可能性があります。

私は個人的にハッシュ+ソルティングサーバー側を実装し、ログインページにSSLv3/TLSv1を強制します。

于 2010-01-27T17:10:27.157 に答える