Система входа, безопасность

Question

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

• На сервере есть данные для входа в таблицу базы данных - имя пользователя и хэш пароля для каждого пользователя (например, зашифрованный с помощью SHA224).
• Когда клиент хочет пройти проверку подлинности, пароль шифруется с помощью SHA224 (на стороне клиента) и отправляется с именем пользователя на сервер для проверки соответствия в базе данных.
• Если пользователь установил флажок «Запомнить меня», проверка подлинностиключ генерируется на сервере, вставляется в базу данных вместе с IP-адресом клиента.
• Ключ аутентификации отправляется клиенту и сохраняется в файлах cookie.
• Теперь, когда клиент возвращается, ключ аутентификации от файлов cookie отправляется на сервер, сервер находит его в базе данных и проверяет, совпадают ли IP-адреса.Если это так, пользователь проходит аутентификацию, и новый ключ аутентификации генерируется и отправляется пользователю (и сохраняется в файлах cookie) для следующего посещения.

Мои вопросы:

1. Как шифрование пароля делает это безопаснее?Хэш все еще может быть перехвачен на пути от клиента к серверу и использован неправильно так же, как если бы он был открытым текстом.Я знаю, что это элементарный вопрос, но я почему-то не смог найти ответ на этот вопрос.
2. Достаточно ли безопасна эта система безопасности?(или еще лучше - я правильно понял?)

Answer 1

Почему хеширование пароля делает систему более безопасной

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

Хранение паролей

Самый простой способ обезопасить схему хранения паролей - с использованием стандартной библиотеки .

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

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

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

Что бы вы ни делали, если вы пойдете на '1027 *, я сделаю это сам, спасибо , больше не используйте MD5 . Это хороший алгоритм хеширования, но не работает в целях безопасности .

В настоящее время использование crypt , с CRYPT_BLOWFISH, является лучшей практикой.

^{Из моего ответа: Помогите мне сделать безопасным хранение моего пароля}

Что касается печально известного варианта «Помни меня».

Создайте случайный токен и передайте его пользователю в виде файла cookie. Если пользователь представляет куки с этим токеном, вы предоставляете им доступ. Ключ должен принимать каждый токен только один раз. Поэтому после использования замените его новым случайным токеном.

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

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

Отправка паролей на сервер

Единственный способ, используемый в настоящее время для отправки пароля из веб-браузера на сервер, - это использование защищенного соединением SSL. Все остальное не будет безопасным, так как вы не можете гарантировать целостность решения на стороне клиента.

Answer 2

Некоторые очки, которые я хочу добавить:

• хеширование пароля не сделано на клиенте. Вы не можете сделать это надежно. Необходимая техника для вычисления хеша (JavaScript в вашем случае) может быть недоступна, и вы не можете доверять результату. Если кто-то может получить хеши паролей в вашей базе данных, он может просто войти в систему, не зная реальных паролей.

• Убедитесь, что используете SSL или другой безопасный транспорт для передачи данных паролей от клиента к серверу. В конце концов, SSL - хорошая идея для всего.

• Вы не должны использовать один алгоритм хеширования для хранения паролей в базе данных. Посмотрите на HMAC. Это намного лучше. Дополнительно читайте о солях в криптографии.

Answer 3

• Никогда не изобретайте свои собственные крипто-механизмы.Используйте чужие.Крипто не так сложно, и, если вы не Брюс Шнайер, у вас очень малые шансы улучшить его, и при этом у вас есть огромный шанс испортить его.
• Не шифруйте пароли, хешируйте их.
• Если вы используете хеши, посолите их.
• Если вам не нужно использовать прямые хэши, используйте HMAC, они намного более устойчивы к заранее рассчитанным атакам.
• Если вы отправляете материал по незащищенной ссылке, добавьте NONCE к передаче, чтобы предотвратить атаки повторного воспроизведения.Это касается как клиента-> сервера, так и сервера-> клиента.
• Если вы используете соли и одноразовые добавки, убедитесь, что они имеют высокую энтропию.«секрет» не очень хороший.Сделайте это случайным, сделайте это длинным, заставьте это использовать большие наборы символов.Дополнительные вычислительные затраты минимальны, но безопасность, которую вы получаете от этого, огромна.Если вы не уверены, как, используйте генератор случайных паролей, а затем используйте ent для измерения энтропии.
• НЕ используйте временную метку в качестве одноразового номера, если только у вас нет особых потребностейи действительно знаю, что ты делаешь.
• Использовать защиту сеанса.SSL не идеален, но он чертовски лучше, чем ничего.
• Если вы используете SSL, обязательно отключите слабые протоколы.Сеанс SSL начинается с «предложений» списков шифров, которые могут сделать обе стороны.Если вы разрешите клиентам использовать слабого, злоумышленник обязательно воспользуется этим.