ユーザーのパスワードをデータベースに保存してはいけないと言われたのですが、パスワードを保存できない場合、どうすればユーザーを認証できますか? それらを安全に保つには、単に暗号化するだけで十分ですか?
最近、LinkedIn のような注目度の高いサイトが侵害されたというニュースがいくつかありましたが、そのような注目度の高いサイトがプレーンテキストのパスワードを保存するとは思わないので、パスワードは暗号化されていると想定します。
免責事項:私はもともとこれを Quora に投稿しましたが、答えは Stack Overflow に適していると感じました。
実際にパスワードを保持せずにユーザーパスワードを保存およびチェックするために使用される方法は、ユーザー入力を保存されたハッシュと比較することです。
ハッシングとは?
ハッシュとは、ハッシュ値と呼ばれる固定長のセットとして返すアルゴリズムを介して、可変長のデータ (小さなパスワード、大きなパスワード、バイナリ ファイルなど) を渡すプロセスです。ハッシュは一方向にしか機能しません。数 Mb で構成される *.img ファイルは、パスワードとまったく同じようにハッシュできます。(実際には、大きなファイルにハッシュを使用して整合性をチェックするのが一般的な方法です。bittorrent を使用してファイルをダウンロードすると、ソフトウェアはそれをハッシュし、持っているもののハッシュと本来あるべきもののハッシュを比較します。それらが一致する場合、ダウンロードは破損していません)。
ハッシュによる認証はどのように機能しますか?
ユーザーが登録するとき、彼はパスワードを与え、pass123
それが値にハッシュされ(この場合はmd5のsha1、sha256などの利用可能なハッシュアルゴリズムによって)、32250170a0dca92d53ec9624f336ca24
その値がデータベースに保存されます。ログインを試みるたびに、システムはパスワードをリアルタイムでハッシュし、保存されているハッシュと比較し、一致する場合は準備完了です。ここでオンラインの md5 ハッシャーを試すことができます: http://md5-hash-online.waraxe.us/
2 つのハッシュが同じ場合はどうなりますか? ユーザーは別のパスでログインできますか?
彼ができた!それを衝突といいます。架空のハッシュアルゴリズムで、値pass123
がハッシュec9624
を生成し、値pass321
がまったく同じハッシュを生成すると、そのハッシュアルゴリズムは壊れるとします。一般的なアルゴリズム md5 と sha1 (LinkedIn が使用するもの) は両方とも、衝突が見つかったため壊れています。壊れているからといって、必ずしも安全ではないというわけではありません。
衝突をどのように悪用できますか?
ハッシュを生成できる場合、それはユーザー パスワードによって生成されたハッシュと同じであり、そのサイトに対してユーザーとして識別できます。
レインボーテーブルアタック。
クラッカーは、ハッシュ化されたパスワードのテーブルを取得すると、パスワードを 1 つずつ悪用することは現実的ではないことにすぐに気づき、新しい攻撃ベクトルを考案しました。存在するすべてのパスワード (aaa、aab、aac、aad など) を生成し、すべてのハッシュをデータベースに保存します。次に、盗まれたハッシュをデータベース上で順次生成されたすべてのハッシュ (1 秒未満のクエリ) で検索し、それに応じたパスワードを取得するだけで済みます。
救助への塩 (そして、LinkedIn が大失敗した場所!)
セキュリティは、クラッカーがパスワードを解読するのにかかる時間と、パスワードを変更する頻度によって定義されます。レインボー テーブルではセキュリティが急速に低下するため、業界はソルトを考え出しました。すべてのパスワードに独自のねじれがあるとしたら? それは塩です!登録するすべてのユーザーに対して、たとえば 3 文字のランダムな文字列を生成します (業界では 16 文字を推奨しています - https://stackoverflow.com/a/18419.. .)。次に、ユーザーのパスワードをランダムな文字列と連結します。
password - salt - sha1 hash
qwerty - 123 - 5cec175b165e3d5e62c9e13ce848ef6feac81bff
qwerty - 321 - b8b92ab870c50ce5fc59571dc0c77f9a4a90323c
qazwsx - abc - c6aec64efe2a25c6bc35aeea2aafb2e86ac96a0c
qazwsx - cba - 31e42c24f71dc5a453b2635e6ec57eadf03090fd
ご覧のとおり、ソルトの値が異なると、まったく同じパスワードが生成され、まったく異なるハッシュが生成されます。それがソルトの目的であり、LinkedIn が大失敗した理由です。テーブルにはハッシュとソルトのみを保存することに注意してください! パスワードは絶対に!
LinkedIn のハッシュを手に入れた人たちが最初にしたことは、ハッシュを並べ替えて、一致するものがあるかどうかを確認することでした (複数のユーザーが同じパスワードを持っていたため、一致していたのは残念です!) それらのユーザーが最初に削除されました。パス テーブルがソルト化されていたら...そのようなことは起こらなかったでしょうし、すべてのパスワードをクラックするのに膨大な時間 (およびコンピューター リソース) が必要になるでしょう。そうすれば、LinkedIn が新しいパスワード ポリシーを適用するための十分な時間を確保できたはずです。
回答の技術的な側面から、認証がどのように機能するか (または機能する必要があるか) についての洞察が得られることを願っています。