Что лучший способ состоит в том, чтобы сделать аутентификацию пользователя в php?
Я просто писал 2 cookie, 1 содержащий идентификатор пользователя и 2-е, содержащее 1/2 хеш SH1 (посолившего) пароля. Путем это работает, самоочевидно.
Я понял, что не делал этого самым безопасным способом. Что такое лучший способ сделать это? Предпочтительно с помощью единственного cookie аутентификации.
Кроме того, есть ли точка к использованию "трудно для вычисления хешей"? Этим я имею в виду, с помощью bcrypt, или хешируя каждый объект 10,000 раз с джакузи, для создания этого (относительно) медленной хеш-функцией (200 мс по сравнению с меньше чем 1 мс просто SHA1)? Я имею в виду, нарушает ли кто-то Ваш DB и получает хеши...., что там оставляют защитить, так как все Ваши данные находятся в том же DB (Если у Вас нет своего рода децентрализованная установка, которую я не делаю).
5 ответов
use Sessions. Сохраняйте идентификатор сессии в cookie-файле и состояние пользователя на стороне сервера (logIn, userId, IP).
Чтобы уточнить, что нужно хранить в массиве сеансов:
- logIn: булевая переменная о том, вошел ли пользователь в систему или нет. Вы повторно используете одну и ту же cookie-файл для нескольких сессий, таким образом, вы запоминаете имя пользователя при следующем посещении сайта и т.д.
- userId: Уникальный идентификатор пользователя в базе данных. Используйте его для получения дополнительной информации о пользователе, такой как имя пользователя, электронная почта и т.д. Это также может быть сохранено в массиве сеансов после выхода пользователя из системы.
- IP: Для предотвращения кражи идентификатора сессии и его использования, вы также сохраняете IP пользователя. Это необязательно, так как иногда вы хотите позволить пользователю блуждать (например, stackoverflow позволяет мне перемещаться с моим ноутбуком, не выходя из системы, когда IP меняется).
- lastPing: Штемпель времени, которую пользователь видел в последний раз. Эта метка может быть использована вместо срока действия куки-файлов. Если вы также сохраняете время жизни сессии, то вы можете выйти из системы по причине неактивности. Это означает, что файл cookie идентификатора сессии может храниться на компьютере пользователя в течение очень долгого времени.
Когда пользователь выходит из системы или выходит из системы по причине бездействия, вы просто устанавливаете значение logIn равным false. Когда пользователь входит в систему с правильным именем пользователя и паролем, вы устанавливаете значение logIn равным true и обновляете другие поля (userId, IP, life). При загрузке страницы пользователь сверяет lastPing с текущим временем и временем жизни и либо обновляет lastPing, либо выходит из системы.
Данные сеанса могут быть сохранены либо в файловой системе, либо в базе данных. Если данные хранятся в базе данных, то userId является либо посторонним ключом к записи пользователя, либо все данные могут быть помещены в запись пользователя.
Хэширование
повторное перепрошивание значения несколько раз не является хорошей идеей, так как вы снижаете безопасность . Вместо этого используйте соль, комбинируя статическую соль (например, имя страницы) и имя пользователя вместе с паролем. Хэш, который занимает много времени, не лучше, чем быстрый хэш, хэш, который приводит к большому дайджесту, лучше, чем хэш, который приводит к короткому дайджесту (из-за грубой силы). Использование SHA1 должно быть достаточно хорошим для обычного сайта (IE, а не банк или секретная военная организация).
Спросите себя, насколько строги ваши требования к безопасности, чтобы определить, насколько тяжело это будет или нет. Я использую Zend_Auth и Zend_Acl для обработки аутентификации/авторизации в моих php приложениях. Если вы в настоящее время используете фреймворк, вы можете поискать в нем рекомендуемые лучшие методы. Даже если вы не используете фреймворк, вы можете выполнить поиск по другим сайтам/приложениям, чтобы получить представление об этом. Однако, есть еще кое-что, когда речь заходит об использовании https для входа/входа и входа в сессию целиком, http - только cookies и т.д.
Если вы хотите реализовать функциональность "запомнить меня" для вашего сайта, сохранение юзеида в файле cookie является приемлемым.
Пароль не следует хранить в файле cookie пользователя. При желании они могут сохранить его в своем браузере.
В настоящее время уникальный токен для идентификации пользователя - это их имя пользователя + 1/2 из соленого пароля HASH. Этот токен статичен, что означает, что он останется прежним для каждого запроса, пока пользователь не изменит свой пароль. Это означает, что если я хочу вытеснить пользователя в системе, мне нужно только для захвата / перехватить токен один раз. (Если вы не введете энтропию в токен во время создания хеша, хранящегося в cookie). Поскольку большинство пользователей редко меняют пароли, атакующий будет иметь то, что на нестерку истекает токен для доступа к учетной записи пользователя.
Лучшее решение состоит в том, чтобы использовать механизм сеанса PHP и вызов Session_regenerate_id на каждом запросе, чтобы постоянно обновить токен. Таким образом, делает сессию угона почти невозможным, особенно через SSL-соединение с помощью ограничения IP-адреса / диапазона.
В настоящее время я делаю вызовы 0 дБ (кроме во время входа или когда что-то Изменения) для зарегистрированных пользователей. я хотел Это останется таким образом ... - Егор 7 Mins назад
Данные сеанса PHP хранятся в файловой системе по умолчанию, поэтому вы не будете делать дополнительные вызовы БД с помощью встроенного сеанса.
Также есть ли точка для использования " рассчитать хэши "? По тому, что я имею в виду, Использование BCRYPT или HASHING каждого элемента 10 000 раз с джакузи, чтобы сделать Это (относительно) медленная хеш-функция (200 мс против менее 1 мс просто просто SHA1)?
Хеширование строки в 10 000 раз. не не делает его в размере в 10 000 раз больше, чем хвалить его один раз. Хаш один раз с хорошим односторонним шифрованием, как Sha1 или Whirlpool.
Я имею в виду, если кто-то нарушает вашу БД и получает хэши .... Что там осталось защищать, так как все ваши данные находится в том же дБ (если у вас нет какая-то наращивание децентрализованной установки, который я не).
Прилив пароль хэши защищает их от атак радуги . В настоящее время очень сложно, если не невозможно взломать соленые пароли с радугой.
Есть несколько способов сделать это. Я не собираюсь идти слишком глубоко, так как есть множество литературы на эту тему.
- Прежде всего, лучше использовать что-то вроде
SHA256, чтобы уменьшить вероятность столкновения. - Вы также должны использовать соленую или двойную соление с одной переменной солью (например, IP - для предотвращения кражи сеансов). Строка печенья будет выглядеть как
YourSalt123.123.123.123USernamePasswordПеред хешистом. - Используйте сеансы в сочетании с вашими файлами cookie.
- В зависимости от ваших требований безопасности используйте SSL.
Все зависит от того, насколько вас небезопасно . Сообщественный сайт о Lolcats имеет различные требования к безопасности по сравнению с банковским сайтом.