Лучший способ кодирования паролей в PHP

В настоящее время я использую,
base64_encode () для кодирования пароля пользователя, это хорошо работает, потому что это позволяет мне просто использовать base64decode () для декодирования пароля для слова и отправки туда электронной почты, если они теряют там пароль.

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

Что ты используешь? Вы можете дать мне какой-то совет? И есть ли способ декодировать считываемый пароль для отправки по электронной почте пользователю?

Когда я набрал этот вопрос, я просто вспомнил, что некоторые форумы не отправляют вам пароль по запросу, а вместо этого отправляют специальную ссылку для повторного установления вашего пароля, я предполагаю, что это потому, что они не могут расшифровать ваш пароль, может быть?

//what I use now $password_encoded = base64_encode($password); //what I am considering using $password_encoded = sha1($password); 

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

Ни один веб-сайт, который не заинтересован в защите себя или своих пользователей (или имеет лижущий смысл), отправит пользователю свой пароль по электронной почте. Единственное, что мы можем сделать, даже отдаленно близко к безопасности, – это отправить пользователям электронное письмо с уникальной одноразовой ссылкой, которая позволяет им установить новый пароль.

  • Храните хэш ( bcrypt или PBKDF2 ) пароля, который был солен
  • Отбросьте исходный пароль, как только вы его сохранили. Акцизируйте его из памяти.
  • Всегда требуется, чтобы пользователь создавал свой собственный новый пароль по каналу SSL

Пытаться пройти с чем-нибудь еще – честно просто халатность. Давайте используем очень распространенный сценарий, используемый в обсуждениях безопасности:

Письмо пользователя Фредерика скомпрометировано. Это может быть от разблокировки компьютера или с использованием слабого пароля. Несмотря на это, у неё есть доступ к его сообщениям. В идеале это означало бы не что иное, как некоторые неловкие любовные письма, прочитанные незнакомцем. К сожалению, неавторизованный человек обнаруживает, что форум будет отправлять пароль Фредерика в текстовом виде. Как и большинство пользователей, Фредерик использует одинаковый пароль для всего, включая его онлайн-банкинг. Его имя пользователя указано в электронном письме своего банка. Сейчас ситуация очень неудачная.

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

Связанный

Множество окружающих вопросов и идей очень хорошо ответили на SO:

  • Разница между Хешированием пароля и Шифрование
  • Почему подход-ответ подходит к плохому решению для забытых паролей?
  • Неслучайная соль для хэшей паролей

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

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

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

Чтобы избежать простого поиска предварительно вычисленной строки, вы должны солить свои пароли перед их использованием. Соль может быть добавлена ​​в их имя пользователя или их идентификатор пользователя, если у вас есть дополнительная информация о пользователе, который является постоянным, что вы можете легко добавить к паролю во время аутентификации.

Вы должны позволить пользователю СБРОСИТЬ пароль, но никогда не НАПОМИНАЙТЕ их пароль. Вот почему вы хотели бы использовать односторонний хеш (SHA2) вместо формы шифрования, которая позволяет его декодировать.

Представьте, если вы оставили свою электронную почту открытой. Я мог бы просто запросить, чтобы получить ваш пароль для какого-либо веб-сайта, удалить письмо, и вы никогда не узнаете. С другой стороны, если вы потребовали меня сбросить пароль, пароль учетной записи изменится, и владелец, очевидно, поймет, что что-то не так. (Это глупый сценарий, но концепция важна)

Хеши можно «отменить», пытаясь использовать все возможные комбинации слов (или используя таблицы радуги), пока не будет создан соответствующий хеш. Одним из способов избежать этого является добавление / добавление предоставленного пароля с солью, чтобы сделать его очень длинной и непредсказуемой строкой. Соль должна быть уникальной строкой данных, уникальной для учетной записи пользователя.

В PHP нет функции SHA2. SHA-2 – семейство хэш-алгоритмов (SHA-256, SHA-384, SHA-512 и т. Д.)

 hash('sha256', 'The quick brown fox jumped over the lazy dog.'); 

Абсолютное обязательное чтение на эту тему – это собственный Джефф. Вероятно, вы храните пароли неправильно . Вот исполнительное резюме:

  1. Не изобретайте свою собственную «умную» схему хранения паролей.
  2. Никогда не храните пароли в виде открытого текста.
  3. Добавьте длинную уникальную случайную соль к каждому сохраненному вами паролю.
  4. Используйте криптографически безопасный хэш.

Base64Encode не обеспечивает безопасность, потому что любой может легко ее перевернуть.

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

Это не так безопасно, как хэш-шифрование, но если вам нужно отправить пароль, это хороший компромисс.

Вы можете посмотреть библиотеку mcrypt для php http://ca3.php.net/mcrypt

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

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

 $user = "joe"; $password = 'password'; $saved_hash = DB::Query("select hash from users where username = ".quote($user)." LIMIT 1"); if (sha256($password) == $saved_hash) User::authenticated(); 

Никогда, никогда не отправляйте пароли по электронной почте. Отправить уникальный, непредсказуемый, сгенерированный ключ, например, в PHP:

 $key = sha256(time().rand().$secret_seed); 

Отправьте этот ключ клиенту, для однократного использования, для установки нового пароля.

Вы хотите использовать хэш (предпочтительно sha1) с «солью»,

Вы можете делать хеширование на сервере при аутентификации одним быстрым запросом:

 SELECT * FROM user WHERE password = MD5(CONCAT(?, salt));