Лучшие практики PHP для аутентификации пользователя и безопасности пароля

PHPass - это легкая библиотека хеширования паролей с переменной стоимостью, использующая bcrypt.

Переменная стоимость означает, что позже вы можете увеличить «стоимость» хеширования паролей, чтобы беспрепятственно повысить безопасность без необходимости аннулировать ранее хешированные пароли пользователей.

Размер поля, используемый для хранения хэшей, является постоянным даже при увеличении «стоимости» 'из-за увеличения не размера хэша, а количества итераций, необходимых для его создания.

Я использую OpenID .

Но, как и stackoverflow, я использую проект Google openid-selector для выполнения тяжелой работы.
Демонстрационная страница здесь .

Очевидные преимущества (OpenID):

• Вам не нужно быть экспертом по безопасности.
• Пользователи доверяют крупным сайтам свою информацию.
• ] Вы можете запросить такие вещи, как (псевдоним и т. Д.), Но пользователь должен согласиться.
• Вам не нужно беспокоиться о:
  • процессы регистрации
  • потерянный / забытый пароль

Сворачивание собственной HTTP-аутентификации в вашем языке сценариев

Фактически вы можете расширить HTTP Basic Auth , эмулируя его в языке сценариев. Единственное требование для этого - ваш язык сценариев должен иметь возможность отправлять HTTP-заголовки HTTP-клиенту. Подробное объяснение того, как это сделать с помощью PHP, можно найти здесь: ( подробнее о PHP и HTTP AUTH ).

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

Недостатки HTTP AUTH

1. Основным недостатком HTTP-аутентификации является сложности, связанные с выходом из системы. Основной способ очистить пользователя сеанс заключается в том, чтобы закрыть браузер или передать заголовок с 403 Authentication Required. К сожалению, это означает, что всплывающее окно HTTP AUTH возвращается на страницу, а затем требует от пользователей либо войти в систему, либо нажать «Отмена». Это может не сработать, если принять во внимание удобство использования, но можно обойти некоторые интересные результаты (например, используя комбинацию файлов cookie и HTTP AUTH для сохранения состояния).

2. Обработка всплывающих окон HTTP AUTH, сеанса и HTTP-заголовка осуществляется определяется реализацией стандарта в браузере. Это означает, что вы застрянете с этой реализацией (включая любые ошибки) без возможности обходного решения (в отличие от других альтернатив).

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

Здесь много отличных ответов, но я чувствую, что стоит сказать следующее - НЕ пытайтесь заново изобрести колесо в этом случае! Очень просто испортить аутентификацию пользователя самыми разными способами. Если вы действительно не нуждаетесь в индивидуальном решении и не обладаете твердым знанием схем и передовых методов безопасности, то у вас почти наверняка будут недостатки безопасности.

OpenID отлично подходит, или если вы собираемся накатить свою собственную, по крайней мере, использовать установленную библиотеку и следовать документации!

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

Например, предположим, что сейчас вы проверяете пользователей следующим образом:

user_cookie = getSecureCookie()
if (user_cookie.password == session_user.password) {
    do_secure_thing()
    ...
}

Если в getSecureCookie () обнаружена уязвимость, и вы используете этот код для проверки пользователей во всем приложении, вы можете не найти все экземпляры getSecureCookie (), которые необходимо исправить. Если, однако, вы отделяете свою логику от безопасности:

if (userVerified()) {
    do_secure_thing()
    ...
}

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