0

主キーを持つ単純なユーザー テーブルを設計し、次にテーブルへの外部キーとしてuserid使用する別のテーブルを設計しようとしています。ここで正しい考えがありますか？ useridusers

CREATE TABLE `users` (
    `userid` INT(6) NOT NULL,
    `username` VARCHAR(50) NOT NULL,
    `password` VARCHAR(50) NOT NULL,
    `date_join` DATE NOT NULL,       <- should I just make this CURDATE instead?
    `user_handle` VARCHAR(50) NOT NULL,
    `date_modified` DATE NOT NULL,
    PRIMARY KEY (`userid`)
)

1) ユーザー ID を自動インクリメントするにはどうすればよいですか?

2) パスワードを MD5 ハッシュとしてどのように保存しますか? また、brcrypt を強く推奨しているさまざまなコーダーを読みましたが、どう思いますか?

3)シンボルuser_handleの前の電子メールの最初の部分にデフォルトを設定するにはどうすればよいですか? @そのようなものjohn@smith.comは、のユーザーハンドルを生成しますjohn。

4) ユーザーデータベースを設計する際に取るべき追加のセキュリティ対策はありますか?

5) ユーザーに関連付けられた他のテーブルの外部キーには、ユーザーを指す外部キーが必要useridですか?

質問が多すぎないことを願っています。

4

2 に答える 2

3

  1. ユーザー ID を自動インクリメントするにはどうすればよいですか?

    列のAUTO_INCREMENT属性を指定します。userid

    CREATE TABLE `users` (
    `userid` INT(6) NOT NULL AUTO_INCREMENT,
    -- etc.

  2. パスワードを MD5 ハッシュとして保存するにはどうすればよいですか? また、brcrypt を強く推奨しているさまざまなコーダーを読みましたが、どう思いますか?

    パスワードのハッシュに MD5 よりも bcrypt を推奨する主な理由は、bcrypt がその目的のために設計されたのに対し、MD5 はメッセージの整合性を検証するように設計されているためです。したがって、bcrypt は意図的に遅く、MD5 は意図的に高速です。これは、攻撃者が bcrypt ハッシュと MD5 ハッシュを総当たり攻撃するには、かなり多くの作業が必要であることを意味します。

    どちらの関数も固定サイズのバイナリ出力 (MD5 の場合は 16 バイト、bcrypt の場合は 56 バイト) を生成するため、適切な列の型はMD5 とbcrypt の場合BINARYです。BINARY(16)BINARY(56)

    どちらの場合でも、必ずハッシュをソルトする必要があります。ソルトは、(最終) ハッシュが計算される前にユーザーのパスワードと連結されるランダムな文字列です。使用されるソルトは、ユーザー レコードと共にデータベースに保存されますが、ユーザーごとに異なります。これにより、データベースが危険にさらされた場合にユーザーのパスワードを回復するためのレインボー テーブル攻撃が無効になります。

    これらのアクションの実行に関連する実際のコードは、アプリケーションの開発に使用する言語、ライブラリ、および/またはフレームワークによって異なります。

  3. シンボルuser_handleの前の電子メールの最初の部分にデフォルトを設定するにはどうすればよいですか? @そのようなものjohn@smith.comは、のユーザーハンドルを生成しますjohn。

    このようなロジックはおそらくアプリケーション コードに最も適していますが、MySQL の関数INSERTを使用して SQL ステートメントで実行することもできます。SUBSTRING_INDEX()

    INSERT INTO users VALUES (
  -- [ deletia ]
  SUBSTRING_INDEX('john@smith.com', '@', 1),
  -- [ deletia ]
);

  4. ユーザー データベースを設計する際に必要な追加のセキュリティ対策はありますか?

    関連するセキュリティの概念の完全な説明については、この優れた投稿を読むことを強くお勧めします。

  5. ユーザーに関連付けられた他のテーブルの外部キーには、ユーザーを指す外部キーが必要useridですか?

    はい。外部キーは、その目的のために使用されるという理由で存在します。MySQL で外部キー制約を強制する (つまり、参照されるレコードが外部テーブルに存在することを保証する) 場合は、ローカル テーブルと外部テーブルの両方に InnoDB ストレージ エンジンを使用する必要があります。さらに、キーのローカル コピーと外部コピーの両方にインデックスが存在する必要があります。制約は、次のような句を使用して参照テーブルで定義されます。

    FOREIGN KEY (userid) REFERENCES users (userid)
于 2012-08-27T01:12:12.257 に答える
2

  1. CREATE TABLEステートメントを変更できると仮定すると、次のようにすることができます。

    CREATE TABLE `users` (
    `userid` INT(6) NOT NULL AUTO_INCREMENT,
    ...
)

  2. 通常、データベース上で実行するサーバーは、(登録時およびログイン時に) パスワード ハッシュ自体を生成し、ハッシュを文字列としてデータベースに渡します。したがって、データベースの観点からは、スキーマはこれで問題ありません。または、パスワード ハッシュの最終的な長さによっては、ほぼ問題ありません。

  3. 繰り返しますが、これは通常、データベース自体ではなく、サーバー コード (または JavaScript) で処理するものです。単純な文字列split()またはsubstring()仕事をするでしょう。データベースでこれを本当に実行したい場合は、トリガーを使用して挿入イベントを検出し、目的のデフォルト値を設定できます。

  4. はい。 パスワードをソルトします。

  5. はい、他のテーブルにはuserid「ユーザー」のフィールドを参照するキーがあります。何かのようなもの：

    CONSTRAINT `FK3FD7C193F39FADA` FOREIGN KEY (`owner_id`) REFERENCES `users` (`userid`)
于 2012-08-27T01:01:13.823 に答える