Проверка пароля; этот способ сделать его безопасный?

Не сохранять фактический пароль в базе данных. Вместо этого сохраните контрольную сумму (MD5, SHA1 и т. Д.). Если вы хотите сравнить, выполните контрольную сумму значения, отправленного пользователем, и сравните контрольные суммы.

Таким образом, у вас никогда не будет в памяти фактического пароля.

Лучшей практикой является хранение соленого sha1 хэша в базе данных:

if (sha1($pass.$row['poster_salt'])==$row['poster_password'])

(poster_salt - случайная строка, сгенерированная и сохраненная, когда пользователь выбирает пароль.)

Таким образом, если злоумышленник получит доступ к вашей базе данных, он все равно не получит пароли пользователей (которые, вероятно, используются и в других местах - большинство людей не утруждают себя выбором разных паролей для разных сайтов).

Также следует использовать безопасное (HTTPS) соединение. И требовать достаточно сложные пароли.

(По крайней мере, если вам нужна хорошая безопасность, что может быть излишеством в случае простого размещения объявлений).

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

При вставке вы бы сделали

Insert into table(email, password, whatever) values('$email', md5($password), whatever)

А при сравнении вы бы сделали

if (md5($pass) == $row['password'])

мое предложение следующее

в таблице users есть два столбца, один называется "password", а другой "salt"

$password =  'youruserpassword in plain text';
$salt = bin2hex(openssl_random_pseudo_bytes(32));
$passtostore = hash_hmac('sha384', $password, $salt);
insert into users(password, salt) values($passtostore, $salt);

Затем, чтобы проверить, ввел ли пользователь правильный пароль...

извлекаем пароль и соль из базы данных и

if(hash_hmac('sha384',$userpass, $row['salt']) === $row['password']) { 
 // is valid 
 }

Вы должны как-то хэшировать пароль и хранить и сравнивать, используя хэшированную версию. Смотрите эту ссылку для более подробной информации:

http://phpsec.org/articles/2005/password-hashing.html

Я хотел бы зашифровать пароль перед его сохранением, а затем расшифровать его при получении, чтобы вы могли сравнить его с тем, что пользователь ввел в виде открытого текста (согласно приведенному выше примеру кода).

Также защитите себя от любых SQL-инъекций , иначе кто-то сможет увидеть все пароли (и другие данные) в вашей базе данных.

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

SQL Injection

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

Шифрование

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

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

Хеш-значения (рекомендуется)

Лучшей практикой и более безопасной является хранение в базе данных только односторонних хеш-значений (SHA1 или SHA256) паролей, а не самих паролей. Таким образом, вы не сможете получить пароль. Хеш-значения намеренно являются односторонними, отбрасывая часть данных.

Вместо того чтобы восстанавливать оригинальный пароль, вы хэшируете пароль, который вводит пользователь, и сравниваете хэш-значение с сохраненным хэш-значением, чтобы проверить, совпадает ли оно. Если в этом случае пользователь теряет пароль, вместо того чтобы отправить его по электронной почте, вы отправляете ему новый, случайно сгенерированный пароль.

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

Когда вы хэшируете пароли, обязательно используйте случайное значение соли и храните соль для защиты списка хэшей от радужных атак.

Резюме

Иногда вы не можете выбрать пароль. Иногда пароль приходит из другой системы, так что у вас не всегда есть выбор, а иногда ваше начальство (возможно, даже пользователи) требует, чтобы они могли получить пароли, однако, когда это возможно, вы должны выбрать более безопасный вариант.

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

Вам нужно защитить свою базу данных. Есть ли у вас надежный пароль на вашей системе баз данных? Разрешаете ли вы только локальный доступ к своим данным? Создали ли вы пользователя базы данных с наименьшими привилегиями для использования в вашем приложении? Защищаетесь ли вы должным образом от SQL-инъекций и скриптовых атак?

Если кто-то имеет доступ на чтение и запись к вашим данным, вся эта история с паролями становится спорной.