10

サイトのユーザー管理システムを作成したい ,

セキュリティとパフォーマンスのどちらが優れているか。

タイプ 1 :

table_user : user_id , user_name , user_email , user_password . user_phone ...

また

タイプ 2 :

table_user : user_id , user_name , user_email ...
table_pass : user_id , user_password .
table_phone: user_id , user_phone .

どちらの方がよいですか ？

4

4 に答える 4

22

理想的には：

  • パスワードをまったく保存しないでください (暗号化されていても)。パスワードから派生したハッシュを保存します。
  • レインボー アタックを防ぐためにパスワードをソルトします。
  • 独自のファイアウォールと明確に定義された独自の API 1の背後にある別のデータベース サーバーにハッシュを配置します。この API は、次の 3 つのことだけを行う必要があります。
    1. 指定されたユーザー名について、対応するパスワード ハッシュを取得します。
    2. 特定のユーザー名に対して、新しいハッシュを設定します (パスワードのリセットをサポートするため)。
    3. 指定されたユーザー名とそのハッシュを削除します (ユーザーの登録解除をサポートするため)。
  • ソルトについても同じことを行います。ソルトを独自のサーバーに配置し、独自のファイアウォールと API の内側に配置します。この API は、次の 3 つのことだけを行う必要があります。
    1. 指定されたユーザー名について、対応するソルトを取得します。
    2. 特定のユーザー名に対して、新しいソルトをランダムな値に設定します (パスワードのリセットをサポートするため)。
    3. 指定されたユーザー名とそのソルトを削除します (ユーザーの登録解除をサポートするため)。
  • ハッシュ サーバーとソルト サーバーはどちらも、世界から (および相互に) 遮断され、Web アプリケーションを実行するサーバー (つまり、PHP や ASP.NET など) からのみアクセスできる必要があります。

ユーザーがユーザー名とパスワードを入力してログオンしようとすると、次のようになります。

  • 入力したデータが安全にサーバーに到達するように、これが HTTPS 経由で行われていることを確認してください。
  • ユーザー名のパスワード ハッシュを取得する API を呼び出します。
  • ユーザー名のソルトを取得する API を呼び出します。
  • ユーザーが入力したパスワードをソルトおよびハッシュし、取得したハッシュと比較します。
  • それらが一致する場合、ユーザーはアクセスを許可されます。

その性質上、ハッシュは元に戻すことができません。ユーザー以外の誰も、あなたでさえ、正確なパスワードを知りません。ユーザーがパスワードを忘れた場合、パスワードを送信することはできませんが、追加の検証に合格した場合 (つまり、特定の電子メール アドレスにアクセスしたり、シークレットに答えたりする場合)、パスワードをリセットできるようにすることができます。質問）。

ところで、ログオンは比較的まれな操作であるため、適切なインデックス作成を完全に無視しない限り、パフォーマンスのボトルネックになることはほとんどありません。

1たとえば、Web サービスを実装し、その Web サービスに必要なポートのみを開き、他には何も開きません。

于 2012-11-10T21:21:51.137 に答える
4

オプション1で行きます。

何十万人ものユーザーがいると思います。したがって、ユーザー データを取得するには、1 つのテーブルではなく n 個のテーブルを処理する必要があります。これにより、明らかにサーバーに負荷がかかり、最終的にパフォーマンスが低下します。

したがって、私はオプション 1 を使用します。

電話の場合。番号、landline_number、mobile_number、alternate_number としてフィールドを追加します。テーブルにフィールドを追加しても、フィールドにテーブルを追加してもそれほど違いはありません。

はい、Steve のコメントによると、安全なハッシュ メカニズムを使用してパスワードを保存します。

では、あなたはどの選択肢を選びますか？

于 2012-11-10T14:46:17.437 に答える
2

まず、@Steve がコメントしているように、安全なハッシュ メカニズムを使用してパスワードを保存する必要があります。プレーン テキストのパスワードを保存するのは無責任です。つまり、システムにハッキングできる人は誰でも、他のサイトで再利用した可能性のあるユーザー パスワードを知っているということです。

第二に、どちらの設計にも固有のセキュリティやパフォーマンスの利点はありません。セキュリティの観点からは、データベースにアクセスできる攻撃者がクエリを実行できると想定する必要があり、両方でデータを取得するのは自明のことです。スキーム。パフォーマンスの観点からは、オプション 2 の結合のコストは、プライマリ/外部キー インデックスがある場合は問題になりません。

一定期間後にパスワードを再設定する必要があり、パスワードの再利用を防ぐためにパスワード履歴を保存する必要がある場合 (これは、たとえば Windows がサポートする機能です)、「UserPassword」テーブルを用意する必要があります。 、valid_from および valid_until 列。

于 2012-11-10T14:38:05.950 に答える
1

場合によります。パスワード履歴を保持したい場合、およびユーザーが多くの電話番号を持つことができる場合は、パスワードと電話用の追加のテーブルを作成します。それ以外の場合は、1つのテーブルで十分です。

于 2012-11-10T14:25:27.943 に答える