ユーザーのコンピュータにアクセスすると、ハッカーが保存されたパスワードでログインできるように、ハッシュパスワードをCookieに保存するセキュリティリスクについては、多くの議論があります。ハッカーがユーザーのコンピュータにアクセスできる場合、ブラウザはパスワードをローカルに保存する（もちろん暗号化されている）ので、パスワードをキャッチすることもできます。クッキーに設定されたパスワードとブラウザによって保存されたパスワードの違いは何ですか？ハッシュされたパスワードをCookieに保存するのは本当に危険ですか？
明白な理由から、パスワードの代わりに一時的なGUIDを送信する必要があります。いずれにせよ、私は、ログに記録されたIPへのアクセスを制限することで、攻撃者がローカルに保存されたGUIDを使用する可能性があると考えています。もちろん、IPは通常動的で定期的に変化するため、ログに記録される期間の長さを制限します。私はそれがその顕著なセキュリティの価値があると思います。何か案が？
ハッシュされたパスワードをクッキーに保存する理由は、「Remember me」クッキーを作成することだと思います。だから秘密であるクッキーの価値が必要なので、誰かがそれを簡単に推測することはできません。この値にアクセスできる人は誰でもこのユーザーとしてログインできるので、実際は「余分なパスワード」です。
ここに関与する2つのリスクがあります。
最も重要なのは、パスワードを露光するリスクです。これはあなたのサイトを危険にさらすだけでなく、潜在的に他のサイトにもつながります。ほとんどのユーザーはすべてのパスワードを再利用するため、パスワードは侵入者にユーザーの電子メールアカウントとネットバンクの両方にアクセスする可能性があります。ハッシュ値にアクセスできる人は、ブルートフォースまたはレインボーテーブルを使用して元のパスワードを検出することができます（レインボーテーブルは、事前に計算されたハッシュの長いリストです）。レインボーテーブルは8文字以上のパスワードで簡単に利用できます。ハッシュを作成する前に（つまり、クッキーに塩を保存することを忘れないように）パスワードが20文字以上になるようにパスワードを設定することで、これを避けることができます。安全なハッシュアルゴリズムで計算された適切にソルトされたパスワードハッシュは、非常に安全でなければなりません。
ハッシュされたパスワード文字列を無効にするには、ユーザーが元のパスワードを変更する必要があります。ユーザーがこの機能をオンにすると、実際にこの機能をオフにすることは不可能です。クッキーを削除するときは、「私を覚えてください」ボタンのチェックを外しますが、クッキーが既に侵害されている場合は無効になります。彼のコンピュータが盗まれているとどうなりますか？ユーザーがあるコンピュータでこのボタンをチェックした場合、この機能を無効にするには、そのコンピュータにアクセスする必要があります。あなたは自分のパスワードを再入力するようユーザーに依頼する必要があり
ユーザーのコンピュータにアクセスすると、ハッカーは パスワードを使用してログインできます。ハッカーがユーザーのコンピュータにアクセスできる場合、ブラウザはパスワードをローカルに保存するため（パスワード ）、パスワードをキャッチすると のパスワードをキャッチできます。
ここに何を意味するのかわかりません。 IEにサイトのパスワードを覚えておいて、誰かがあなたのコンピュータへのパスワードを持っていてIEを使うことができたら、パスワードを使ってログインできます。しかし、これはハッシングやクッキーなどとは関係ありません。
まず、ハッシュされたパスワードは取得できません。だから誰かがあなたのパスワードのハッシュを持っているなら、彼はあなたのパスワードを知らない。
パスワードを要求するサイトにログインするときは、暗号化されたパスワードを入力します。標準的な方法は、ユーザーのパスワードをパスワード自体ではなくハッシュとして保存することです。パスワードを入力すると、受信側のサーバーは保存されているハッシュとハッシュを比較します。
これは、Cookie内でハッシュされたパスワードを送信する際のご質問に関連しており、これはセッション管理に関連しています。私。ユーザーがすでに正常にログインしているかどうかを判断します。
IMHOは、プレーンHTTPを使用しているときにユーザーが既にログインしているかどうかを判断する方法としてハッシュパスワードを使用するのは良い考えではありません。
しかし、これはあなたが求めるものなら、別の話題です。
I.
はい、クッキーにハッシュされたパスワードを使用することはあまり安全ではありません。 はです。ブラウザに保存して、それを有線経由で送信するのと異なります。常にSSLを使用している場合を除き、攻撃者は要求からクッキーを読み取るためにマシンにアクセスする必要はありません。
ランダムな値を送信する方が安全です。ユーザーの実際のパスワードとは関係ありません。ユーザーにパスワードを変更させることなく、ランダムな値を忘れてセッションを終了することができます。また、攻撃者がクッキーからハッシュ値を取得した場合、送信されたものであれば、実際のパスワードを回復することも可能です。
それからパスワードを回復することはできませんハッシュ関数は一方通行の関数です。それが本当に悪い関数であり、攻撃者が何らかの辞書攻撃を行った場合、同じハッシュ値を生成する文字列を見つけることができます。しかし、あなたの答えに入れる方法あなたの最後の声明が何を意味するのか明確ではありません – Cratylus
一般的に良いハッシュ関数である関数は、速度を考慮して設計されているので、パスワードをハッシュするには不正な関数になります。たとえば、MD5でハッシュ化された低品質のパスワードを攻撃することが現実的になっています。だから私は私の "可能かもしれない"と立っていますが、私は私ができるほど明確ではなかったことを認めます。 –
私はあなたが '良いハッシュ関数によって何を意味するかを得ることを確認していない彼らはあなたがパスワードに使用されることを意味している機能は、高速であることをexpecedされていることを意味speed'.oのために設計されているように、パスワードをハッシュに悪いの関数を作ります？ – Cratylus
タイムズ：
ハッシュされたパスワードを保存すると、この効果が低下します。余談として
、あなたはすでにXSS攻撃から保護するために（ジャバスクリプトを経由してアクセスすることはできません）HttpOnlyの、（HTTP経由で送信しません）安全であるクッキーを使用する必要があります。もちろん、人のマシンを完全にハックすると、キーロガーがインストールされます。
ハッシュパスワードを安全にする唯一のことは、サーバー上でハッシングが発生することです。 –
私はあなたが何を意味するのか知っています。ここでハッシュされたパスワードまたはGUIDの目的は長期間を行うことです。試行錯誤攻撃の場合は変更できません。 – Googlebot
** [セッショントークンとしてGUIDを使用しないでください。]（http://stackoverflow.com/questions/7732540/unpredictable-unique-identifier/7733025#7733025）** – Brian