Пароли, соли и аутентификации

Question

Если у меня есть произвольная буквенно-цифровая соль длиной 16 символов (разный регистр), которая генерируется и сохраняется для пользователя, нужна ли мне соль всего сайта?

Другими словами, хорошо ли это?

sha1($user_salt . $password)

Должен ли я сделать это вместо этого?

sha1($user_salt . $password . $site_salt)

Кроме того,

В настоящее время у меня есть зашифрованный файл cookie, который просматривает сеанс вDB.В этом сеансе есть user_id и user_token.Затем я выполняю запрос к БД, используя user_id - если sha1 из user_id + хеша в DB === user_token, то пользователю разрешено через.

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

Это то, что я нашел, просматривая веб-сайты и вопросы здесь.Как вы думаете?Я что-то пропустил?

Мне нужно добавить проверку ролей, но это, вероятно, добавит еще один запрос (третий только для аутентификации).Любые советы?

Answer 1

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

Я думаю, что если ваша база данных была взломана и кто-то понял, что ваши пароли были хешированысоль, они перешли бы на следующий сайт с меньшей безопасностью (если, конечно, вы не пользуетесь сайтом, который стоит взломать - скорее всего, это не так: P)

Answer 2

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

Я называю это подходом «соль» и «перец»,Соль, хранящаяся на пользователя, перец - это значение для всего сайта.

Соль
Цель уникальной соли на человека - аннулировать радужные таблицы.Соль обычно хранится в базе данных и либо добавляется, либо добавляется к паролю.Кто-то, кто знает об этом, может по-прежнему запускать атаки на основе словаря для каждого пользователя, но хорошо для соли - то, что они не могут использовать радужную таблицу для таких общих словарных терминов.

Pepper
Цель "перца", как я его называю, состоит в том, чтобы добавить потенциально неизвестную строку к каждому паролю, что означает, что атака по словарю с использованием грубой силы с учетом соли будет просто не выполняться из-за отсутствия перца.Это также означает, что при грубой проверке на символ необходимо «обнаружить» более длинный пароль, который может занять больше времени.Эти преимущества исчезают, как только перец обнаружен.

Answer 3

На данный момент у меня есть зашифрованный файл cookie, который ищет сеанс в БД.В этом сеансе есть user_id и user_token.Затем я выполняю запрос к БД с помощью user_id - если sha1 из user_id + хеша в DB === user_token, то пользователю разрешено через.

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

Комментирование только в случае, если здесь что-то не так, что никто не поймал:

1. Вы упоминаете, что cookie зашифрованы
2. Вы имеете в виду sha1 из user_id + hash
3. Вы упоминаете второй запрос (мне не ясно, что это за запрос), чточувствителен к смене пароля.

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

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

Моя рекомендация (если вы хотитесеанс, чувствительный к смене пароля) - это изменение идентификатора сеанса при каждом изменении пароля.

Answer 4

sha1($user_salt . $password)

Это очень обычно , но это не хорошо.

Типичный пароль конечного пользователя имеет длину ~ 8 символов и в основном соответствует 7-битному набору символов ASCII. Таким образом, типичный пароль составляет около 64 бит случайных данных или меньше. Современные параллельные атаки методом перебора могут победить это, просто испробовав все возможные пароли. Использование SHA256 или SHA512 вместо этого существенно не меняет результат, поскольку ограничивающим фактором является пароль конечного пользователя.

Из моего прочтения здесь, в Переполнении стека, , похоже, есть две мысли о хранении пароля:

1. Вы должны использовать вычислительно дорогой подход, такой как BCrypt или scrypt . Таким образом, атаки методом грубой силы становятся невозможными. Это работает за счет того, что при входе пользователя в систему требуется гораздо больше ресурсов процессора от сервера. См. Эту превосходную статью для обзора обоснования .
2. Вторая школа мысли заключается в том, что, хотя BCrypt и scrypt, безусловно, работают, они нежелательны для многопользовательских приложений, поскольку занимают слишком много процессорного времени - заставляют конечного пользователя ждать или потенциально открываются для атаки отказа в обслуживании отправив множество запросов на аутентификацию. См. длинное обсуждение здесь (обязательно прочитайте также комментарии).

В данный момент у меня есть зашифрованный cookie, который ищет сеанс в БД. В этом сеансе есть user_id и user_token. Затем я запрашиваю базу данных, используя user_id - если sha1 из user_id + хеша в DB === user_token, то пользователю разрешено через.

Одним из основных моментов безопасной обработки сеансов, о котором вы не упомянули, является SSL повсеместно для защиты от Sidejack . И идентификаторы пользователей, как правило, не годятся для безопасности, потому что они часто являются угадываемыми (автоинкрементный первичный ключ) или по ошибке попадают в URL и т. Д. Вместо того, чтобы использовать свою собственную систему обработки сеансов, разве не может быть использована проверенная база кода?

Answer 5

Похоже, вы пытаетесь воссоздать DIGEST-MD5 или SCRAM . Оба из них позволяют вам хранить строку, не являющуюся паролем, которая является уникальной для вашего сайта, и посылать вызов / отвечать другой стороне, чтобы убедиться, что у них есть строка пароля, без отправки строки пароля по сети.