それを行うより良い方法はありますか?
はい、SSL/HTTPS と呼ばれます。すでに HTTPS を使用している場合、この暗号化マジックは必要ありません。HTTPS を使用していない場合は、設計上すでに安全ではなく、SSL を再発明する以外に解決策はありません。
トランスポートがセキュア (HTTPS) の場合はどうすればよいでしょうか
- クライアントは、プレーンテキストでユーザー名とパスワードを送信して認証を要求します。
- サーバーは、アカウントに保存されている (うまくいけば) ハッシュ化されたパスワードに対して、ユーザー名とパスワードのペアを検証します。
- サーバーは、静的 AES キーを使用してトークン (暗号化されたアカウント ID、有効期限など) で応答します。
- クライアントは、すべての認証済みリクエストに対してトークンを使用します。
簡単。
あなたにできることは一つ...
安全でないデバイスで使用される資格情報の損失を防ぐには、Google などからページを取得する必要があります。ユーザーに Web サイトのパスワードを入力させるのではなく、Web サーバーにアクセスしてログインさせます。そこから、[デバイスのアクセス トークンを生成] をクリックします。一意のデータ文字列 (20 文字以上) が生成され、アカウントと共に記録されます。この「代替パスワード」は、ユーザーが Web サイトから取り消すことができます。
これをより安全にするにはどうすればよいですか?
これ以上のことはできません。その理由は次のとおりです...
攻撃者があなたの秘密鍵にアクセスしたとします。その後、攻撃者はユーザー名とパスワードを盗みながら、サーバーを置き換えたり、中間者を演じたりすることができます。
これを防ぐには、PKI 交換を工夫して、サーバーから提供された公開鍵で暗号化されたパスワードを送信します。私は中間者として、自分の公開鍵をあなたに渡し、ユーザー名とパスワードにアクセスし、必要に応じてそれを実際のサーバーに転送することができます。
- また -
これを防ぐために、クリア テキストのパスワードの代わりにサーバーに送信されるソルト + パスワード ハッシュを使用します。私は中間者として、ソルトの固定値を提供し、そのソルト値の完全なレインボー テーブルを事前に計算することができます。これで、私は再び全員のパスワード (ほとんどの場合) を平文で取得しました。
- また -
これを防ぐには、PKI を使用して秘密のセッション キーを確立し、すべての通信に署名して暗号化します。ええと... おなじみですね...ウィキペディアの SSL を参照してください。SSLを安全にする唯一のことは、秘密鍵の保護であることを認識してください。秘密鍵が失われると、すべてのセキュリティと信頼が失われます。
最終的な注意事項:
一部の暗号化キーを保護できなければ、安全な通信を構築できません。
また、SSL のソフトウェア実装 (OpenSSL など) には何千時間もの工数が費やされており、実装の脆弱性が常に発見されていることにも注意してください。これを自分で実装し、IIS や OpenSSL と同じくらい安全にするという希望はほとんどありません。それはあなたのDiggではありません、それはただの現実です、私もそれをすることができませんでした。
最後に、私の最後のアドバイスは、「システム内の誰かがそれを漏らして悪用する可能性がある」というあなたの声明についてです。これはあなたの本当の問題です。それを修正すると、他のすべてがはるかに簡単になります。サーバー環境を保護することが最優先事項です。2 番目の優先事項は、1 番目の優先事項に失敗した場合の顧客への影響を最小限に抑えることです。
役立つリンク: