サイトがパスワードを保存する方法はいくつかあり、その中には他の方法よりもかなり安全なものもあります。ここでは、最も一般的な方法の簡単な概要と、それらがデータのセキュリティにとって何を意味するかを示します。
方法 1: プレーン テキストのパスワード 仕組み: サイトがパスワードを保存する最も簡単な方法は、プレーン テキストです。つまり、彼らのサーバーのどこかに、ユーザー名とパスワードが人間が読める形式で格納されたデータベースが存在することを意味します (つまり、パスワードが testing123 の場合、データベースには testing123 として保存されます)。サイトで資格情報を入力すると、データベースと照合して一致するかどうかが確認されます。これはセキュリティの観点から考えられる最悪の方法であり、評判の良い Web サイトのほとんどはパスワードをプレーン テキストで保存していません。誰かがこのデータベースをハッキングすると、全員のパスワードがすぐに侵害されます。
強力なパスワードは重要ですか? とんでもない。パスワードの長さや強度に関係なく、パスワードがプレーン テキストで保存されていて、サイトがハッキングされた場合、パスワードは誰でも簡単にアクセスでき、作業は必要ありません。たとえば、友人や簡単に推測できる人からパスワードを隠すという点では依然として重要ですが、サイトがハッキングされた場合は何の違いもありません.
方法 2: 基本的なパスワード暗号化 仕組み: プレーン テキストよりもパスワードの保護を強化するために、ほとんどのサイトではパスワードをサーバーに保存する前に暗号化しています。ご存じない方のために説明すると、暗号化は特別なキーを使用してパスワードをランダムな文字列に変換します。ハッカーがこのランダムなテキスト文字列を手に入れたとしても、暗号化解除に使用できるキーも持っていない限り、アカウントにログインすることはできません。
問題は、多くの場合、キーがパスワードとまったく同じサーバーに保存されているため、サーバーがハッキングされた場合、ハッカーはすべてのパスワードを解読するために多くの作業を行う必要がないことです。つまり、この方法は依然として非常に安全ではありません. .
強力なパスワードは重要ですか? いいえ。パスワード データベースはキーで簡単に復号化できるため、ここでも強力なパスワードを使用しても違いはありません。繰り返しますが、これはサイトがハッキングされるという点です。せんさく好きな友人や家族があなたのものを応援している場合、強力なパスワードを使用すると、彼らが推測するのを防ぐことができます.
方法 3: ハッシュ化されたパスワード 仕組み: ハッシュ化は、パスワードを文字と数字の長い文字列に変換して隠しておくという意味で、暗号化に似ています。ただし、暗号化とは異なり、ハッシュは一方通行です。ハッシュがある場合、アルゴリズムを逆方向に実行して元のパスワードを取得することはできません。これは、ハッカーがハッシュを取得し、さまざまなパスワードの組み合わせを試して、どれが機能するかを確認する必要があることを意味します.
ただし、この方法には欠点があります。ハッカーはハッシュをデコードして元のパスワードに戻すことはできませんが、所有しているハッシュと一致するまで、さまざまなパスワードを試すことができます。コンピュータはこれを非常に高速に行うことができ、レインボー テーブルと呼ばれるもの (本質的に何兆もの異なるハッシュとそれに一致するパスワードのリスト) の助けを借りて、ハッシュを調べて、それが既に発見されているかどうかを確認することができます。Google に e38ad214943daad1d64c102faec29de4afe9da3d と入力してみてください。「password1」の SHA-1 ハッシュであることがすぐにわかります。レインボー テーブルのしくみの詳細については、コーディングの第一人者 Jeff Atwood によるこの記事を参照してください。
強力なパスワードは重要ですか? この場合、はい。レインボー テーブルは、ハッシュに対してテスト済みのパスワードで構成されているため、非常に脆弱なパスワードはすぐに解読されてしまいます。ただし、最大の弱点は複雑さではなく、長さです。短くて複雑なパスワード (kj$fsDl# など) よりも、非常に長いパスワード (XKCD の有名な「正しい馬のバッテリー ステープル」など) を使用することをお勧めします。
方法 4: ハッシュ化されたパスワードに塩を少し加えたもの 仕組み: ハッシュのソルト化とは、パスワードをハッシュ化する前に、パスワードの先頭または末尾にランダムな文字列 (「ソルト」と呼ばれる) を追加することを意味します。パスワードごとに異なるソルトを使用し、ソルトが同じサーバーに保存されていても、それぞれが長く、複雑で、一意であるため、レインボー テーブルでソルトされたハッシュを見つけるのが非常に困難になります。LinkedIn はソルト付きハッシュを使用していないことで有名であり、最近のハッキングの後、多くの監視下に置かれました。ソルトを使用していれば、ユーザーはより安全だったでしょう。
上記の記事を読んで、私は次の質問を念頭に置いています
1 .パスワードを持っていなくても、メッセージダイジェストを傍受できます...パスワードさえ必要ありません...私は単に応答攻撃を開始します（つまり、傍受後に認証のためにメッセージダイジェスト自体を送信しますそれ！！）
上記の問題の解決策は、次の方法で解決できます。 a. サーバーがランダムな文字列 (通常はチャレンジとして知られている) をユーザーに生成し、パスワードで暗号化するように要求します ..... b. ユーザーがパスワードを入力し、メッセージ ダイジェストパスワードのランダムな文字列が作成され、このメッセージ ダイジェストによって暗号化されます。この暗号化された文字列はサーバーに送信されます。d.server はまた、ランダムな文字列をユーザーのメッセージ ダイジェストで暗号化し、ユーザーから受信した暗号化された文字列でチェックし、両方が一致する場合、彼は有効なユーザーです..!
2 .私の質問は、ハッカーがデータベースにアクセスできる場合、メッセージダイジェストにアクセスできます/データベースにアクセスできなくても、ユーザーが最初にDBに登録するときに通信リンクを傍受しながらメッセージダイジェストを取得できます.. ....どうすればこれを防ぐことができますか??