Как написать / собрать безопасный вход в PHP? Руководство разработчика веб-сайта говорит, что я не должен откатываться, поэтому обращение к образцам, доступным через Google, бесполезно.
Как вы это понимаете? Допустим, вы строите приложение мирового класса в рельсах, можно ли использовать те же библиотеки / методы здесь?
благодаря
В Rails обычно используется уже существующая библиотека. Аутентификация легко сделать неправильно, и проблема была решена так много раз, что редко стоит усилий для ее решения снова. Если вы заинтересованы в написании собственной реализации, я опишу, как работает современная аутентификация.
Наивный метод аутентификации пользователя – хранить свой пароль в базе данных и сравнивать его с паролем, который пользователь представляет. Это просто, но невероятно небезопасно. Любой, кто может читать вашу базу данных, может просматривать чей-либо пароль. Даже если вы установите элементы управления доступом к базе данных, вы (и ваши пользователи) уязвимы для всех, кто их обманывает.
Правильная форма – использовать криптографическую хеш-функцию для обработки пароля при его выборе, а затем каждый раз, когда он отправляется. Хорошая хеш-функция практически необратима – вы не можете взять хэш и вернуть его обратно в пароль. Поэтому, когда пользователь входит в систему, вы берете предоставленный пароль, хеш его и сравниваете с хешем в базе данных. Таким образом, вы никогда не храните пароль самостоятельно. С другой стороны, если пользователь забывает свой пароль, вы должны сбросить его, а не отправить его им.
Однако даже это уязвимо для некоторых атак. Если злоумышленник получает хэши паролей и знает, как вы делаете свои пароли, он может сделать атаку по словарю: он просто принимает каждое слово в словаре и хеширует это слово, сохраняя его с оригиналом. Эта структура данных называется радужным столом. Затем, если какой-либо из хэшей словарного слова соответствует хэшу пароля, злоумышленник может сделать вывод, что пароль – это словарное слово, которое хеширует этот пароль. Короче говоря, злоумышленник, который может читать вашу базу данных, может войти в учетную запись со слабыми паролями.
Решение заключается в том, что до того, как пароль хэшируется, он объединяется (обычно конкатенированный или xor'd) со значением, называемым солью, которое уникально для каждого пользователя. Он может генерироваться случайным образом, или это может быть временная метка создания учетной записи или некоторые из них. Затем злоумышленник не может использовать таблицу радуги, потому что каждый пароль по существу хэшируется несколько иначе; он должен был бы создать отдельный стол радуги для каждой отдельной соли (практически для каждой учетной записи), что было бы чрезмерно дорогостоящим.
Я повторю советы других ответчиков: это не простой материал, и вам не нужно это делать, потому что это было сделано раньше, и если вы сделаете это сами, у вас будет очень хороший шанс совершить ошибку и непреднамеренно поставить под угрозу безопасность вашей системы. Но если по какой-то причине вы действительно хотите писать сами, я надеюсь, что предоставил (неполный!) План того, как это делается.
Zend Framework имеет модуль «Auth», который будет хорошим местом для начала. Или, если на вашем сайте будет установлена установка WordPress или PHPBB, существуют способы использования модулей аутентификации этих технологий для входа на другие страницы сайта.
Одна вещь, на которую нужно смотреть, когда вы пытаетесь пройти аутентификацию, – это ваша настоящая цель.
Например, на SO я использую свой логин google, и это работает, поскольку они просто должны знать, кто я, и они могут доверять тому, что у Google есть идея. Итак, если эта модель будет работать на вас, то посмотрите на использование OpenID, так как для этого есть различные инструменты.
Если вы должны сделать свое собственное, тогда будут различные тесты, чтобы гарантировать, что это безопасно, опять же, в зависимости от того, насколько вы параноик.
Я закончу свой ответ здесь, когда Том сделал фантастический ответ.
by Soulmerge:
Я думаю, что принятый ответ в другом вопросе говорит об этом довольно хорошо. Хешируйте пароли солью. Помимо этого, на транспортном уровне есть некоторые идеи безопасности:
md5($_POST['postedPwHash'] . $salt) ) хороший способ несколько закрепить транзакцию клиент-сервер (если нет ssl) – использовать одноразовый случайный ключ для создания уникального хеша из учетных данных, а затем отправлять этот уникальный хэш только серверу. Затем сервер сравнивает этот хеш с собственным хешем вместо того, чтобы сравнивать его с реальными учетными данными. это обеспечит хорошую защиту от атаки «человек в середине». Недостатком является то, что для этого пользователь должен включить JS (по крайней мере, я не знаю хорошего метода для шифрования данных на стороне клиента без него). это означает, что вам понадобится достаточный запас, если он не включен. вы даже можете создать форму в JS, чтобы убедиться, что она включена.
эта библиотека представляет собой простую библиотеку, которую я написал однажды, которая описывает описанную мной процедуру, хотя она, вероятно, нуждается в некоторых улучшениях.
обратите внимание, что это в дополнение к использованию методов «соления» и других мер безопасности на стороне сервера. он также весьма уязвим для атак на словах, поскольку весь процесс хэширования по определению является процедурным, предсказуемым и видимым для пользователя (поскольку JS всегда есть).
Мой ответ: «Не делай этого»
Это очень сложная область, полная потенциальной безопасности. Если вы не являетесь экспертом в этой области, то вы действительно просто просите о проблемах и проблемах в будущем.
Я бы рекомендовал посмотреть, как получить существующее решение. К сожалению, я не знаю, что я буду рад порекомендовать, кроме openid. Я уверен, что здесь вы получите хорошие предложения …