Хеширование и соление - проверка логина и файлов cookie

Question

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

У меня есть таблица пользователей с полями пароль, соль, токен (очевидно,Есть и другие, но это самое главное).При регистрации он генерирует случайную соль и случайный токен и помещает в поле пароля следующее:

hash("sha256", $theirpostpassword.$randomgeneratedsalt);

что случайно сгенерированные соль и токен хранятся в соответствующих полях в этой строке пользователя в таблице..

Поэтому при входе в систему я выбираю соль ТОЛЬКО из строки пользователей с указанным им именем пользователя.Затем я делаю запрос на подсчет количества строк, для которых их почтовый пароль объединен с их конкретной солью, и затем я регистрирую их. Я уверен, что эта часть у меня отключена.

Теперь я думал проверить их нана каждой странице у меня была функция, запускаемая на каждой странице, которая проверяет их cookie, чтобы увидеть, соответствует ли формат id-username-token строке в базе данных.Это означает, что при каждом входе в систему он устанавливает свой cookie с этими учетными данными.

Теперь единственное, что я могу придумать, чтобы сделать его лучше, это изменить токен при каждом действительном входе?

Спасибо за понимание, ребята.

Answer 1

Да, вы обязательно должны менять токены при каждом входе в систему.В противном случае украденный один раз токен считается украденным навсегда.Пользователи ожидают, что выход из системы защищает их сеанс от атак путем аннулирования их файлов cookie или других данных.

Вместо того, чтобы токен был случайным, его можно использовать в качестве подписи, генерируя его из хэша идентификатора пользователя.время истечения сеанса и все, что вы хотите в куки, плюс соль (как в системе входа в систему).Эта соль не должна поступать из базы данных, но она может.Это может быть жестко закодированная строка (иногда я думаю, что она называется «перец»).Не забудьте считать cookie недействительным, если срок его действия истек.Вот почему токен должен быть подписью, чтобы они не подделывали эти данные.

Answer 2

Звучит довольно хорошо для меня, но вы должны знать пару вещей:

Чтобы сделать вашу базу паролей устойчивой к атакам методом перебора, вы можете повторить хэш:

$hash = $password;
for ($i = 0; $i < 1000; ++$i) {
    $hash = hash("sha256", $hash . $salt);
}

Во-вторых, убедитесь, что вы используете SSL все время. Без этого злоумышленник может украсть cookie-файл для входа в систему. См. Firesheep для хорошего примера, как это тривиально.

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

Вы также можете выбрать соль и хеш из базы данных и выполнить сравнение на стороне сервера (вместо базы данных) для сравнения хешей.

Я бы предложил, чтобы токен был совершенно случайным. Вы хотите, чтобы это было неубедительно, и лучший способ сделать это - случайный. Вы можете связать токен и с определенным IP-адресом, но это должно быть в дополнение к случайному токену, а не замене.

Это все, что приходит на ум. Хорошо, что вы просите совета, а не просто вводите MD5 пароль и сохраняете его в базе данных!

Answer 3

проверяет их cookie, чтобы определить, соответствует ли формат id-username-token строке в базе данных

Вы можете, но это довольно дорого, и вы не решаете проблемууправления сеансом - установка срока действия файлов cookie в прошлом не всегда приводит к удалению файлов cookie.Обязательно рассмотрите это для функции типа «помни меня» (но используйте путь смещения, чтобы избежать представления куки каждый раз).

Вы не получаете ничего по сравнению с сохранением аутентифицированного имени пользователя в сеансе.Но измените идентификатор сеанса, когда вы аутентифицируете пользователя и используете SSL для передачи токенов аутентификации.