Как сделать проверку пароля в php
Хэширование паролей в PHP 5.5 с использованием нового API
Использование BCrypt является общепринятым и лучшим способом для хэширования паролей, но большое количество разработчиков по-прежнему используют старые и слабые алгоритмы, вроде MD5 и SHA1. Некоторые разработчики даже не используют соль для хэширования. Новый API хэширования в PHP 5.5 ставит своей целью привлечь внимание к BCrypt, упрощая работу с ним. В этой статье я расскажу об основах использования нового API для хеширования в PHP.
password_hash()
Хотя функция crypt() довольно безопасна, она, по мнению многих, слишком сложная. Некоторые разработчики, чтобы не возиться с ней, используют слабую соль и слабый алгоритм для генерирования хэша, например:
Но функция password_hash() позволяет упростить нашу жизнь и обезопасить наш код. Когда вам нужно получить хэш пароля, просто скормите его в эту функцию, и она вернет хэш, который можно хранить в базе данных.
Вот и все! Первым параметром является строка пароля, который необходимо захэшировать, а второй параметр определяет алгоритм, который должен быть использован для генерирования хэша.
Алгоритм по умолчанию, в настоящее время, BCrypt, но более сильный алгоритм может быть установлен по умолчанию, когда-нибудь в будущем, и, возможно, он будет генерировать большие строки. Если вы используете PASSWORD_DEFAULT в ваших проектах, обязательно храните хэш в колонке, размером больше 60 символов. Установка размера колонки до 255 может быть хорошим выбором. Вы также можете использовать PASSWORD_BCRYPT в качестве второго параметра. В этом случае результат всегда будет 60 символов.
Главное здесь в том, что вам не нужно заботиться о значении соли и стоимости вычисления хэша. Новый API будет делать это за вас. И соль является частью хэша, так что вам не придется хранить его отдельно. Если вы хотите использовать вашу собственную соль (или стоимость вычисления), вы можете сделать это путем передачи третьего аргумента функции:
Таким образом, Вы будете всегда идти в ногу с актуальными мерами безопасности. Если PHP позже примет решение о применении более мощного алгоритма хеширования, ваш код может воспользоваться им без изменений.
password_verify()
Теперь, когда вы видели, как генерировать хэши с новым API, давайте посмотрим, как проверить пароль. Мы просто берем хэш из базы, и пароль, введенный пользователем и передаем их в эту функцию. password_verify() возвращает true, если хэш соответствует указанному паролю.
Соль является частью хэша и именно поэтому нам не придется возиться с ней отдельно.
password_needs_rehash()
Что делать, если вам нужно изменить соль или стоимость вычисления для сохраненных паролей? Например, вы решили усилить безопасность и увеличить стоимость вычисления или изменить соль. Или PHP изменил алгоритм хэширования, используемый по умолчанию. В этих случаях вы хотели бы изменить существующие хэши паролей. Функция password_needs_rehash() проверяет, использует ли хэш пароля конкретный алгоритм, соль и стоимость вычисления.
Имейте в виду, что вам нужно сделать это, когда пользователь авторизуется на сайте, так как это единственный раз, когда у вас есть доступ к его незашифрованному паролю.
password_get_info()
Заключение
Новый API хэширования паролей, безусловно, удобнее, чем возня с crypt(). Если ваш сайт в настоящее время работает на PHP 5.5, то я настоятельно рекомендуется использовать новое API хэширования. Те, кто используют PHP 5.3.7 (или более новой версии), могут использовать библиотеку под названием password_compat которая эмулирует это API и автоматически отключает себя при использовании PHP версии 5.5+.
Безопасный метод авторизации на PHP
Примечание: мини-статья написана для новичков
Давайте посмотрим вокруг: форумы, интернет магазины, гостевые книги и т.д. используют регистрацию и последующую авторизацию пользователей. Можно даже сказать, что это почти необходимая функция каждого сайта (только если это не домашняя страничка Васи Пупкина или не визитная карточка, какой-нибудь небольшой компании). Сегодня я хочу поделиться со всеми новичками информацией, о том, как лучше это все реализовать.
1. Модель (клиент)
Регистрация
— логин (a-z0-9)
— пароль
Вход
— логин
— пароль
Cookie
— уникальный идентификатор юзера
— хэш
Модель (сервер)
MySQL
Таблица users
user_id (int(11))
user_login (Varchar(30))
user_password (varchar(32))
user_hash (varchar(32))
user_ip (int(10)) по умолчанию 0
При регистрации в базу данных записываеться логин пользователя и пароль(в двойном md5 шифровании)
При авторизация, сравниваеться логин и пароль, если они верны, то генерируеться случайная строка, которая хешируеться и добавляеться в БД в строку user_hash. Также записываеться IP адрес пользователя(но это у нас будет опциональным, так как кто-то сидит через Proxy, а у кого-то IP динамический… тут уже пользователь сам будет выбирать безопасность или удобство). В куки пользователя мы записываем его уникальный индетификатор и сгенерированный hash.
Почему надо хранить в куках хеш случайно сгенерированной строки, а не хеш пароля?
1. Из-за невнимательности программиста, во всей системе могут быть дырки, воспользовавшийсь этими дырками, злоумышленик может вытащить хеш пароля из БД и подставить его в свои куки, тем самым получить доступ к закрытым данным. В нашем же случае, двойной хеш пароля не чем не сможет помочь хакеру, так как расшифровать он его не сможет(теоретически это возможно, но на это он потратит не один месяц, а может быть и год) а воспользоваться этим хешем ему негде, ведь у нас при авторизации свой уникальный хеш прикрепленный к IP пользователя.
2. Если злоумышленик вытащит трояном у пользователя уникальный хеш, воспользовать им он также не сможет(разве если только, пользователь решил принебречь своей безопастностью и выключил привязку к IP при авторизации).
2. Практика
—
— Структура таблицы `users`
CREATE TABLE `users` (
`user_id` int(11) unsigned NOT NULL auto_increment,
`user_login` varchar(30) NOT NULL,
`user_password` varchar(32) NOT NULL,
`user_hash` varchar(32) NOT NULL,
`user_ip` int(10) unsigned NOT NULL default ‘0’,
PRIMARY KEY (`user_id`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 AUTO_INCREMENT=1 ;
register.php
// Страница регситрации нового пользователя
$err [] = «Логин может состоять только из букв английского алфавита и цифр» ;
$err [] = «Логин должен быть не меньше 3-х символов и не больше 30» ;
# проверяем, не сущестует ли пользователя с таким именем
$err [] = «Пользователь с таким логином уже существует в базе данных» ;
# Если нет ошибок, то добавляем в БД нового пользователя
# Убераем лишние пробелы и делаем двойное шифрование
header ( «Location: login.php» ); exit();
print «При регистрации произошли следующие ошибки:
» ;
login.php
// Страница авторизации
# Функция для генерации случайной строки
$chars = «abcdefghijklmnopqrstuvwxyzABCDEFGHI JKLMNOPRQSTUVWXYZ0123456789» ;
# Вытаскиваем из БД запись, у которой логин равняеться введенному
# Генерируем случайное число и шифруем его
$hash = md5 ( generateCode ( 10 ));
# Если пользователя выбрал привязку к IP
# Переводим IP в строку
# Записываем в БД новый хеш авторизации и IP
# Переадресовываем браузер на страницу проверки нашего скрипта
header ( «Location: check.php» ); exit();
print «Вы ввели неправильный логин/пароль» ;
check.php
// Скрипт проверки
print «Хм, что-то не получилось» ;
print «Включите куки» ;
Для защиты формы логина от перебора, можно использовать captcha.ru target=»_blank»>капчу.
Хочу отметить, что здесь я рассматривал авторизацию основоную на cookies, не стоит в комментариях кричать, что сессии лучше/удобнее и т.д. Спасибо.
Будни программиста
Пишем свою авторизацию на PHP и MySQL
Ну что же, сегодня я вам расскажу о безопасной авторизации на PHP и Cookie. Ну о том что она абсолютна безопасна я не говорю, ибо взломать можно все, но для маленького сайта она вполне подходит. Так же я предвижу комментарии о том что сессии безопаснее. Не спорю куки уступают сессиям в безопасности но для реализации простенькой авторизации вполне подходят. Подробности ниже.
И так, в базе у нас будет 1 база из 4 полей: users_id, users_login, users_password и users_hash. SQL запрос:
Давайте разберем каждый файл.
conf.php
В константах содержится данные SQL подключения, а именно хост, логин, пароль и имя вашей базы. Тут же мы подключаемся к базе, устанавливаем кодировку в которой будут передаваться данные в бд и выбираем бд с которой будем работать. Так же тут содержится массив ошибок которые могут возникнуть при авторизации.
# массив ошибок
$error [ 0 ] = ‘Я вас не знаю’ ;
$error [ 1 ] = ‘Включи куки’ ;
$error [ 2 ] = ‘Тебе сюда нельзя’ ;
?>
register.php
Файл регистрации, тут содержится простейшая форма и ее обработчик. Исходный код прокомментирован, но общий процесс я коротко опишу. Вначале проверяем наш логин, он может содержать только английские буквы и цифры. Далее мы проверяем длину логина, от 3 до 30 символов. Проверяем свободен ли логин. При успешных проверках добавляем нового пользователя в базу. Из введенного пароля мы вырезаем пробелы на случай если пользователь хранит свои пароли в каком ни будь текстовом файле (в windows текстовые редакторы любят «хватать» пробелы в начале или конце выделяемого текста). Шифруем пароль в двойном MD5 и добавляем в базу данные о новом пользователе. Перебрасываем пользователя на login.php.
# Подключаем конфиг
include ‘conf.php’ ;
login.php
Опять кратко расскажу о действиях совершаемых в данном скрипте. В самом начале у нас висит функция для генерации случайной строки, она служит для хеша пользователя (чуть позже более подробно). Далее мы проверяем наличие куков с ошибками (они ставятся в check.php). Подключаем файл конфигурации и проверяем пользователя. Вытаскиваем из бд логин и пароль, сравниваем с введенными и генерируем хеш. Записываем в бд новый хеш пользователя и ставим куки. В куках находится id и хеш пользователя. Пересылаем пользователя на check.php.
# Подключаем конфиг
include ‘conf.php’ ;
# Переадресовываем браузер на страницу проверки нашего скрипта
header ( «Location: check.php» ) ; exit ( ) ;
>
else
<
print «Вы ввели неправильный логин/пароль
» ;
>
>
?>
check.php
И последний файл, который содержит проверку авторизации пользователя. В начале подключаем конфиг и если существуют куки начинаем проверку, если их нет, то ставим куки с номером ошибки и отсылаем на login.php. И так проверка. Вытаскиваем из бд id и хеш. Если они не проходят проверку на соответствие с теми куками которые стоят у посетителя, то удаляем существующие куки посетителя и ставим куки с номером ошибки, пересылаем на login.php. Если же все нормально то пользователь увидит страницу.
# подключаем конфиг
include ‘conf.php’ ;
Логин и проверка пароля в PHP из MySQL
Здравствуйте, возникла проблема. Есть форма, и есть файл, который обрабатывает форму. В форму вводить лишь надо логин и пароль. С помощью SQL запроса нахожу строку с идентичным логином, дальше вытаскиваю оттуда с помощью mysqli_fetch_assoc пароль в массив, и помещаю пароль из массива в переменную. Проверку делаю с помощью password_verify (пароль шифрую с помощью password_hash(‘password’, PASSWORD_ARGON2I) ). Но даже при вводе правильного логина и пароля (все логины уникальные, поэтому путаницы не должно быть) отправляет мою же ошибку, которая срабатывает, если какое-то из условий не было выполнено. Прошу помочь с данным вопросом, и объяснить в чем заключалась моя ошибка.
Помощь в написании контрольных, курсовых и дипломных работ здесь.
задание: логин и пароль + потверждение пароля + проверка в БД
Привет всем помогите пожалуйста с заданием: Комплексный пример идентификации пользователя.
Проверка пароля php
Доброго времени суток, уважаемые пользователи данного форума! То ли время такое, то ли что, пытался.
Шифрование пароля на php mysql
Как сделать что бы код в бд записывался зашифрованным, а при авторизации она был декодирован Ниже.
Смена пароля. Yii, MySQL, PHP
Нужно было сменить пароль от админ. панели. Я зашел в базу данных, через phpmyadmin, пользователь.
Извините за беспокойство. Сам разобрался в коде. Оказывается ошибка не в нем, а в СУБД. Исправил все работает.
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Регистрация на PHP + MySQL с E-mail и повтором пароля
Помогите, люди добрые! Никак не могу разобраться! Введённое в поле «Повтор пароля» с самого начала.
Проверка условия в php, mysql
Тут тестовая программа, вопрос, как сделать условие чтобы после последнего вопроса был переход на.
password_hash
(PHP 5 >= 5.5.0, PHP 7, PHP 8)
password_hash — Создаёт хеш пароля
Описание
В данный момент поддерживаются следующие алгоритмы:
Поддерживаемые опции для PASSWORD_BCRYPT :
Если не задано, то password_hash() будет генерировать случайную соль для каждого хешируемого пароля. Это предпочтительный режим работы.
Эта опция объявлена устаревшей. Рекомендуется использовать автоматически генерируемую соль. Начиная с PHP 8.0.0 явно заданная соль игнорируется.
Поддерживаемые опции для PASSWORD_ARGON2I и PASSWORD_ARGON2ID :
Доступно только тогда, когда PHP использует libargon2, но не при реализации libsodium.
Список параметров
Использование алгоритма PASSWORD_BCRYPT приведёт к обрезанию поля password до максимальной длины 72 символа.
Константа, обозначающая используемый алгоритм хеширования пароля.
Ассоциативный массив с опциями. За документацией по поддерживаемым опциям для каждого алгоритма обратитесь к разделу Константы алгоритмов хеширования паролей.
Если не задано, то будет использована стандартная стоимость и соль будет генерироваться автоматически.
Возвращаемые значения
Возвращает хешированный пароль.
Использованный алгоритм, стоимость и соль будут возвращены как часть хеша. Таким образом, информация, необходимая для проверки хеша будет в него включена. Это позволит функции password_verify() проверять хеш без необходимости отдельного хранения информации о соли и алгоритме.
Список изменений
Примеры
Пример #1 Пример использования password_hash()
Результатом выполнения данного примера будет что-то подобное:
Пример #2 Пример использования password_hash() с ручным заданием стоимости
Результатом выполнения данного примера будет что-то подобное:
Пример #3 Пример поиска хорошего значения стоимости для password_hash()
/**
* Данный код замерит скорость выполнения операции хеширования для вашего сервера
* с разными значениями алгоритмической сложности для определения максимального
* его значения, не приводящего к деградации производительности. Хорошее базовое
* значение лежит в диапазоне 8-10, но если ваш сервер достаточно мощный, то можно
* задать и больше. Данный скрипт ищет максимальное значение, при котором
* хеширование уложится в 50 миллисекунд.
*/
$timeTarget = 0.05 ; // 50 миллисекунд.
Результатом выполнения данного примера будет что-то подобное:
Пример #4 Пример использования password_hash() с Argon2i
Результатом выполнения данного примера будет что-то подобное:
Примечания
Настоятельно рекомендуется использовать автоматическую генерацию соли. Данная функция самостоятельно создаст хорошую соль, если вы не будете ей мешать подсовывая свою.
Как было замечено выше, опция salt была объявлена устаревшей в PHP 7.0 и будет вызывать соответствующее предупреждение. Поддержка ручного задания соли может быть удалена в более новых версиях.
Рекомендуется протестировать данную функцию на вашем железе для определения оптимального значения алгоритмической сложности. Убедитесь, что с выбранной сложностью функция выполняется быстрее 100 миллисекунд для интерактивных систем. Скрипт показанный выше поможет вам выбрать подходящее значение.
Замечание: Обновление поддерживаемых алгоритмов для этой функции (или изменение значения по умолчанию) обязаны следовать правилам:
Смотрите также
User Contributed Notes 12 notes
Since 2017, NIST recommends using a secret input when hashing memorized secrets such as passwords. By mixing in a secret input (commonly called a «pepper»), one prevents an attacker from brute-forcing the password hashes altogether, even if they have the hash and salt. For example, an SQL injection typically affects only the database, not files on disk, so a pepper stored in a config file would still be out of reach for the attacker. A pepper must be randomly generated once and can be the same for all users. Many password leaks could have been made completely useless if site owners had done this.
Since there is no pepper parameter for password_hash (even though Argon2 has a «secret» parameter, PHP does not allow to set it), the correct way to mix in a pepper is to use hash_hmac(). The «add note» rules of php.net say I can’t link external sites, so I can’t back any of this up with a link to NIST, Wikipedia, posts from the security stackexchange site that explain the reasoning, or anything. You’ll have to verify this manually. The code:
Also note that the pepper is useless if leaked or if it can be cracked. Consider how it might be exposed, for example different methods of passing it to a docker container. Against cracking, use a long randomly generated value (like in the example above), and change the pepper when you do a new install with a clean user database. Changing the pepper for an existing database is the same as changing other hashing parameters: you can either wrap the old value in a new one and layer the hashing (more complex), you compute the new password hash whenever someone logs in (leaving old users at risk, so this might be okay depending on what the reason is that you’re upgrading).
Why does this work? Because an attacker does the following after stealing the database:
(More realistically, they use a cracking dictionary, but in principle, the way to crack a password hash is by guessing. That’s why we use special algorithms: they are slower, so each verify() operation will be slower, so they can try much fewer passwords per hour of cracking.)
Now what if you used that pepper? Now they need to do this:
If your pepper contains 128 bits of entropy, and so long as hmac-sha256 remains secure (even MD5 is technically secure for use in hmac: only its collision resistance is broken, but of course nobody would use MD5 because more and more flaws are found), this would take more energy than the sun outputs. In other words, it’s currently impossible to crack a pepper that strong, even given a known password and salt.