1

「ユーザーの資格情報を保存しないで、塩とコショウでハッシュしてください！ 」と考えているかもしれませんが、読み進めてください。

データベースの資格情報 (ログイン/パスワード) についてユーザーに尋ねるプロジェクトに取り組んでいます。これらの資格情報はデータベースに対して試行され、接続が成功した場合は、ユーザーの要求に応じてデータベースで何らかの作業を行うために資格情報を「保持」します (テーブルの作成、行の変更、SELECT の実行など)。

つまり、ユーザーが何かを行うたびに、リクエストを実行する前にデータベースに再接続します => 資格情報は後続のリクエストで役に立たないため、ハッシュできません。必要に応じて、phpMyAdmin のようなものです。

それでいろいろな可能性を思いつきましたが、それぞれに欠点があります。どちらが良いかを判断するための提案を探しています。

  1. ログイン/パスワードが clear のセッション Cookie を使用するだけです。ただし、HTTPS を介した使用のみを許可します。これは、実装する最も簡単な方法です。私が見る唯一の欠点は、クライアント側に XSS がある場合、資格情報を取得できることです。
  2. 同じセッション Cookie ですが、 AES を使用して暗号化されたログイン/パスワードを使用します。それは私が信じているPhpMyAdminによって使用されているものです。HTTPS のみを許可することで、さらに先に進むことができます。
  3. 資格情報をローカル セッション ストレージ(sqlite の session.db) に平文で保存し、指定されたトークン + ブラウザーの詳細を使用して取得されるクライアントのトークンを使用します。欠点 : 攻撃者が session.db ファイルにアクセスすると、ファイルから削除されていないセッションを読み取ることができます。彼が session.db にアクセスできれば、それらを暗号化するために使用される SECRET_KEY にも確実にアクセスできるため、それらを暗号化することは有用ではないと思います。

どう思いますか？あなたならどうしますか？

4

1 に答える 1

2

次の理由から、1. または 2. を使用しないことをお勧めします。

  • クレデンシャルはクライアントにとって役に立たない
  • 要求ごとに (形式に関係なく) ネットワーク経由で資格情報を送信することはお勧めできません。

残るのは、バージョン 3 のバリエーションです。それをセッションに保存します。これには 1 つの重要な特性があります。セッション ストレージが安全でない場合、これはサーバーが安全でないことを意味します。ゲームオーバー。

それにもかかわらず、session.db への攻撃から保護するために、アプリにハードコーディングされたキー ベースを含めることができます。このキー ベースは、セッション トークンでソルト化されてからハッシュされます。その結果は、クライアント資格情報を暗号化および復号化するためのキーとして使用されます。このように、攻撃者は session.db とアプリを侵害する必要があります (キーベースを取得するため)。彼がそれをすることができるなら、あなたを助けるものは何もありません。

于 2012-09-20T09:43:17.650 に答える