3

ソルト、ハッシュ、およびパスワードに関するすべての優れた機能の重要性を理解しています。私の質問は、リレーショナル データベース理論に関するものです。

第 3 正規形についての私の理解では、すべての要素がキー、キー全体、およびキー以外の何ものについての事実を提供する必要があるということです (Codd を助けてください。ウィキペディアに感謝します)。そこで、いくつかのテーブルを見直していたところ、これに出会いました。

-- Users
CREATE TABLE accounts(
    player_id mediumint NOT NULL AUTO_INCREMENT, -- Surrogate Key
    username VARCHAR(32) UNIQUE NOT NULL, -- True primary key
    salt char(29), -- Passwords are stored in bcrypt hash
    hash char(60), -- Salt + Hash stored
    created DATETIME,
    lastlogin DATETIME,
    PRIMARY KEY (player_id)
  ) ENGINE = InnoDB;

質問: この表は第 3 正規形ですか? 私の理解では...「ハッシュ」はplayer_idとソルトに依存しています。IE: ハッシュ -> (ユーザー名、ソルト)。

このテーブルを分割することの本当の利点はわかりません。でも、更新異常とか見えないのでは？と心配です。

4

3 に答える 3

1

「ハッシュ」は player_id とソルトに依存します。IE: ハッシュ -> (ユーザー名、ソルト)。

それは変だ。

通常、ハッシュはソルトとパスワードから導出されます。

その場合、パスワード自体はどこにも保存されないため、ハッシュは特定のユーザーに関する追加の重要な情報を提供します。ハッシュとパスワードの両方を保存した場合、ハッシュはパスワードとソルト (および場合によってはユーザー名) の組み合わせに機能的に依存します。したがって、ハッシュとパスワードの両方を保存すると、3NF に違反し、ハッシュを使用する目的全体に違反します。

パスワードを追加入力しないと、データベース内の他の情報からハッシュを計算することは不可能でなければなりません (どこにも保存されません)。そうしないと、ハッシュはまったく役に立たなくなります。そのため、ハッシュ列は DB 内の他のデータに機能的に依存しておらず、テーブルは 3NF に準拠しています。

ハッシュがパスワードと関係がない場合、つまり他の列から計算できる場合は、はい、DB に保存する必要はありません。

于 2011-06-01T04:29:49.670 に答える
1

はい、それは正常です。テーブルを分割しないでください

于 2011-06-01T04:41:22.103 に答える
0

テーブルを分割しないでください。この表は第 3 正規形です。私が見る限り、すべての列は player_id に依存していますが、ユーザー名や player_id などにソルトが依存しているという警告があります。

于 2011-06-01T04:31:53.323 に答える