3-я обычная форма для таблицы учетных записей пользователей, солей и хэшей - PullRequest
Новая
       34

3-я обычная форма для таблицы учетных записей пользователей, солей и хэшей

3 голосов
/ 01 июня 2011

Я понимаю важность солей, хэшей и всего такого хорошего для паролей.Мой вопрос связан с теорией реляционных баз данных.

Мое понимание 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-й нормальной форме?Насколько я понимаю ... "Hash" зависит от player_id и соли.IE: hash -> (имя пользователя, соль).

Я просто не вижу никакой реальной выгоды от разделения этой таблицы.Но я волнуюсь, что возможно обновление аномалии или что-то, что я не вижу.

Ответы [ 3 ]

1 голос
/ 01 июня 2011

Да, это нормально, и не разбивайте свой стол

1 голос
/ 01 июня 2011

"Хеш" зависит от player_id и соли. IE: hash -> (имя пользователя, соль).

Это странно.

Обычно хеш получается из соли и пароля .

В этом случае хэш предоставляет дополнительную и важную информацию о конкретном пользователе, поскольку сам пароль нигде не хранится. Если вы сохранили как хеш, так и пароль, хеш будет функционально зависеть от комбинации пароля и соли (и, возможно, имени пользователя). Таким образом, хранение как хеша, так и пароля нарушит 3NF и всю цель использования хеша.

Должно быть невозможным вычислять хеш из любой другой информации в вашей базе данных без дополнительного ввода пароля (нигде не хранится). В противном случае хэш был бы довольно бесполезен. И поскольку это так, столбец хеша функционально не зависит от каких-либо других данных в БД, и таблица соответствует 3NF.

Если ваш хэш не имеет никакого отношения к паролю, то есть может быть рассчитан из других столбцов, тогда, да, вам не нужно хранить его в БД.

0 голосов
/ 01 июня 2011

Пожалуйста, не разбивайте таблицу.Эта таблица находится в 3-й нормальной форме.Насколько я вижу, все столбцы зависят от player_id, с оговоркой, от которой зависит соль, например, имя пользователя или player_id.

...