Хеширование и соление - проверка входа в систему с помощью файлов cookie

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

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

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

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

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

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

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

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


authentication php cookies hash salt
person Dan LaManna    schedule 04.01.2011    source источник
comment
Я бы хотел, чтобы токен зависел от IP-адреса удаленного пользователя, но проверка этого файла cookie с этой информацией по каждому запросу, похоже, работает нормально.   -  person ncuesta    schedule 05.01.2011
comment
Спасибо за быстрый ответ, я был полностью против проверки IP, так как знаю, что есть некоторые динамические IP-адреса, которые меняются довольно часто.   -  person Dan LaManna    schedule 05.01.2011
comment
Вам не следует создавать систему аутентификации самостоятельно, потому что очень многое может пойти не так. Вместо этого используйте facebook connect / twitter / openid и т. Д.!   -  person Alfred    schedule 05.01.2011
comment
@Alfred: Хотя это очень популярные методы аутентификации, вы хотите, чтобы они контролировали ваши данные пользователя и надеялись, что они не пострадают от серьезной утечки данных. У проекта Дэна, вероятно, есть то преимущество, что он является гораздо меньшей и, следовательно, менее вероятной целью для хакеров.   -  person ashurexm    schedule 05.01.2011
comment
Если они (универсальный вход) будут взломаны, вам нужно будет изменить только 1 пароль. Если у всех есть другая система входа в систему, вы должны случайно ввести все пароли (потому что большинство людей используют одни и те же пароли для всех веб-сайтов)   -  person Alfred    schedule 05.01.2011

Ответы (3)


arrow_upward
4
arrow_downward

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

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

person Tesserex    schedule 04.01.2011
comment
Я не согласен с тем, что токен является подписью. Вам нужно, чтобы токен был нераспознаваемым, и единственный способ гарантировать это - случайность. Обязательно имейте подпись, но случайный токен очень важен. - person Cameron Skinner; 05.01.2011

arrow_upward
2
arrow_downward

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

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

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

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

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

Вы также можете выбрать соль и хэш из базы данных и выполнить сравнение хешей на стороне сервера (а не в БД), чтобы уменьшить количество обращений к базе данных.

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

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

person Cameron Skinner    schedule 04.01.2011

arrow_upward
1
arrow_downward

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

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

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

person symcbean    schedule 04.01.2011