Использование HTTPS является абсолютным требованием и должно использоваться в течение всей жизни сеанса. Имейте в виду, что идентификаторы сеансов используются для аутентификации браузеров, и если злоумышленник может получить его (сниффинг или xss), то ему не нужны имя пользователя / пароль. Это изложено в OWASP Top 10 2010 A3 Сломанная аутентификация и управление сеансами . Если вы хотите реализовать безопасный сеанс, вы должны прочитать эту ссылку.
md4, md5 sh0 и sha1 - все функции дайджеста сообщений, которые нельзя использовать для паролей. Любой член семьи sha-2 - хороший выбор, sha256 очень большой и отличный выбор для паролей.
Вы не должны абсолютно никогда передавать хэш пароля по сети или передавать его пользователю / злоумышленнику. Если вы отправляете хеш на сервер для аутентификации, вы ввели очень серьезную уязвимость в вашу систему. Используя SQL-инъекцию, хеш пароля можно получить из базы данных, затем этот хеш можно просто воспроизвести для аутентификации, минуя необходимость взломать хэш пароля. Это как если бы вы хранили пароли в виде открытого текста.
Используйте $ _SESSION superglobal и session_start () для поддержания вашего состояния сеанса, никогда не изобретайте заново wheal. Обработчик сеанса PHP по умолчанию безопасен и будет делать то, что вам нужно.
session_start();
if(!$_SESSION['logged_in']){
die("Authentication required!");
}
Также убедитесь, что в вашей системе реализована защита CSRF . Используя CSRF, злоумышленник может получить доступ к административной панели, заставив браузер отправлять запросы. Обязательно протестируйте свое приложение на XSS. Это хороший бесплатный xss сканер , опять же, xss можно использовать для перехвата аутентифицированного сеанса с помощью XHR или получения значения document.cookie. Также неплохо бы проверить на наличие SQL-инъекций и других уязвимостей, wapiti поможет.