безопасность — Безопасный хэш и соль для паролей PHP

Гораздо короче и безопаснее ответ — не пишите свой собственный механизм паролей вообще, использовать проверенный и проверенный механизм.

• PHP 5.5 или выше: password_hash () Хорошее качество и часть ядра PHP.
• Старые версии PHP: OpenWall’s phpass библиотека намного лучше, чем большинство пользовательских кодов — используется в WordPress, Drupal и т. д.

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

Быстрая самопроверка: что такое растяжение пароля и сколько итераций следует использовать? Если вы не знаете ответ, вы должны использовать password_hash()Поскольку расширение пароля теперь является критической особенностью механизмов паролей из-за гораздо более быстрых процессоров и использования GPU и FPGA взломать пароли по ставкам миллиарды догадок в секунду (с графическими процессорами).

Например, вы можете взломать все 8-символьные пароли Windows за 6 часов используя 25 графических процессоров, установленных на 5 настольных ПК. Это перебор, то есть перечисление и проверка каждый 8-значный пароль Windows, включая специальные символы, и не является атакой по словарю. Это было в 2012 году, по состоянию на 2018 год вы могли использовать меньше графических процессоров или быстрее взломать 25 графических процессоров.

Существует также множество радужных атак на пароли Windows, которые выполняются на обычных процессорах и очень быстры. Все это потому, что Windows еще не солит и не растягивается его пароли, даже в Windows 10 — не делайте ту же ошибку, что и Microsoft!

Смотрите также:

• отличный ответ с больше о том, почему password_hash() или же phpass лучший способ пойти.
• хорошая статья в блоге указание рекомендуемых «рабочих факторов» (количества итераций) для основных алгоритмов, включая bcrypt, scrypt и PBKDF2.

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

Начиная с PHP 5.5, PHP имеет простые, безопасные функции для хеширования и проверки паролей, password_hash () а также password_verify ()

$password = 'anna';
$hash = password_hash($password, PASSWORD_DEFAULT);
$expensiveHash = password_hash($password, PASSWORD_DEFAULT, array('cost' => 20));

password_verify('anna', $hash); //Returns true
password_verify('anna', $expensiveHash); //Also returns true
password_verify('elsa', $hash); //Returns false

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

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

Увеличение стоимости (по умолчанию 10) усложняет хэш-обработку хеша, но также означает, что создание хешей и проверка паролей против них будут более трудоемкими для ЦП вашего сервера.

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

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

Более подробное объяснение доступно на http://www.pivotalsecurity.com/blog/password-hashing-salt-should-it-be-random/

Недавно у меня была дискуссия о том, хэши паролей засолены случайно
биты более безопасны, чем соленые с угаданными или известными
соли. Давайте посмотрим: если система хранения пароля скомпрометирована как
а также система, которая хранит случайную соль, злоумышленник
иметь доступ к хешу, а также соли, так что соль случайная или
нет, не имеет значения. Злоумышленник может генерировать предварительно вычисленные
Радужные столы, чтобы взломать хэш. Здесь начинается интересная часть
не так тривиально генерировать предварительно вычисленные таблицы. Давайте возьмем пример
модели безопасности WPA. Ваш пароль WPA фактически никогда не отправляется
Беспроводная точка доступа. Вместо этого он хэшируется с вашим SSID (
сетевое имя — как Linksys, Dlink и т. д.). Очень хорошее объяснение того, как
это работает здесь. Чтобы восстановить пароль из хэша, вы
нужно знать пароль, а также соль (имя сети). Церковь
Wi-Fi уже имеет предварительно вычисленные хеш-таблицы, которые имеют 1000 лучших SSID и
около 1 миллиона паролей. Размер всех таблиц составляет около 40 ГБ.
Как вы можете прочитать на их сайте, кто-то использовал 15 массивов FGPA за 3 дня
генерировать эти таблицы. Предполагая, что жертва использует SSID как
«A387csf3 ″ и пароль как« 123456 », будут ли они взломаны
таблицы? Нет! .. это не может. Даже если пароль слабый, таблицы
нет хэшей для SSID a387csf3. Это красота наличия
случайная соль. Это будет сдерживать взломщиков, которые процветают на предварительно вычисленных
столы. Может ли это остановить решительного хакера? Возможно нет. Но используя
случайные соли обеспечивают дополнительный слой защиты. Пока мы на
В этой теме давайте обсудим дополнительное преимущество хранения случайных
соли по отдельной системе. Сценарий № 1: Хеши паролей хранятся
в системе X и значения соли, используемые для хеширования, хранятся в системе Y.
Эти значения соли являются предположительными или известными (например, имя пользователя) Сценарий № 2:
Хэши паролей хранятся в системе X, а значения соли используются для
хеширование хранится в системе Y. Эти значения соли являются случайными. В случае
Система X была скомпрометирована, как вы можете догадаться, существует огромный
преимущество использования случайной соли в отдельной системе (сценарий № 2).
Атакующий должен будет угадать дополнительные значения, чтобы иметь возможность взломать
хэши. Если используется 32-битная соль, 2 ^ 32 = 4 294 967 296 (около 4,2
миллиард) итераций может потребоваться для каждого угаданного пароля.

Я просто хочу отметить, что PHP 5.5 включает в себя API хеширования паролей это обеспечивает обертку вокруг crypt(), Этот API-интерфейс значительно упрощает задачу хеширования, проверки и перефразирования хэшей паролей. Автор также выпустил пакет совместимости (в виде одного файла password.php, который вы просто require использовать), для тех, кто использует PHP 5.3.7 и выше и хочет использовать это прямо сейчас.

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

API предоставляет четыре функции:

• password_get_info() — возвращает информацию о данном хеше
• password_hash() — создает хеш пароля
• password_needs_rehash() — проверяет, соответствует ли данный хеш заданным параметрам. Полезно, чтобы проверить, соответствует ли хеш вашей текущей схеме техники / стоимости, позволяя вам при необходимости перефразировать
• password_verify() — проверяет, что пароль соответствует хешу

На данный момент эти функции принимают константы паролей PASSWORD_BCRYPT и PASSWORD_DEFAULT, которые на данный момент являются синонимами, с той разницей, что PASSWORD_DEFAULT «может измениться в более новых версиях PHP, когда поддерживаются более новые, более сильные алгоритмы хеширования». Использование PASSWORD_DEFAULT и password_needs_rehash () при входе в систему (и, при необходимости, перефразировке) должно гарантировать, что ваши хэши достаточно устойчивы к атакам методом перебора и практически ничего для вас не делают.

РЕДАКТИРОВАТЬ: Я только что понял, что это кратко упоминается в ответе Роберта К. Я оставлю этот ответ здесь, так как думаю, что он предоставляет немного больше информации о том, как он работает, и простоту использования, которую он предоставляет тем, кто не знает безопасности.

я использую Phpass это простой однофайловый PHP-класс, который можно очень легко реализовать практически в каждом PHP-проекте. Смотрите также H.

По умолчанию он использует сильнейшее доступное шифрование, которое реализовано в Phpass, который bcrypt и прибегает к другим шифрованию вплоть до MD5, чтобы обеспечить обратную совместимость с фреймворками, такими как WordPress.

Возвращенный хеш может быть сохранен в базе данных как есть. Пример использования для генерации хэша:

$t_hasher = new PasswordHash(8, FALSE);
$hash = $t_hasher->HashPassword($password);

Для подтверждения пароля можно использовать:

$t_hasher = new PasswordHash(8, FALSE);
$check = $t_hasher->CheckPassword($password, $hash);

ТО, ЧТО НУЖНО ЗАПОМНИТЬ

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

SERVER

ПОРТЫ

Неважно, насколько хорошо ваше шифрование, если вы не обеспечите надлежащую защиту сервера, на котором работает PHP и БД, все ваши усилия бесполезны. Большинство серверов работают относительно одинаково, им назначены порты, позволяющие вам получить к ним удаленный доступ либо через ftp, либо через оболочку. Убедитесь, что вы изменили порт по умолчанию для любого удаленного подключения, которое у вас активно. Не делая этого, вы фактически заставили злоумышленника сделать на один шаг меньше доступа к вашей системе.

USERNAME

Для всего, что хорошо в мире, не используйте имя пользователя admin, root или что-то подобное. Также, если вы работаете в системе на основе Unix, НЕ делайте доступной учетную запись root, это всегда должно быть только sudo.

ПАРОЛЬ

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

БАЗА ДАННЫХ

SERVER

В идеале вы хотите, чтобы ваша БД и ПРИЛОЖЕНИЕ на отдельных серверах. Это не всегда возможно из-за стоимости, но это обеспечивает некоторую безопасность, так как злоумышленнику придется пройти два шага, чтобы полностью получить доступ к системе.

USER

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

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

Как всегда, НЕ делайте этот корень или что-то подобное.

ПАРОЛЬ

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

PHP

ПАРОЛЬ

НИКОГДА не храните пароль в вашей БД, вместо этого храните хеш и уникальную соль, я объясню почему позже.

HASHING

ОДИН СПОСОБ ХЕШИНГА !!!!!!!, Никогда не хэшируйте пароль таким образом, чтобы его можно было перевернуть, Хэши должны быть односторонними, то есть вы не должны переворачивать их и сравнивать их с паролем, вместо этого вы хэшируете введенный пароль Точно так же и сравните два хеша. Это означает, что даже если злоумышленник получит доступ к БД, он не знает, что на самом деле представляет собой пароль, а только его результирующий хеш. Что означает больше безопасности для ваших пользователей в худшем из возможных сценариев.

Есть много хороших хеш-функций (password_hash, hashи т. д.), но вам нужно выбрать хороший алгоритм, чтобы хэш был эффективным. (bcrypt и подобные ему являются достойными алгоритмами.)

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

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

засол

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

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

ПОЛЬЗОВАТЕЛИ, СОЗДАЮЩИЕ ПАРОЛИ

Если пользователь создает пароль через интерфейс, это означает, что он должен быть отправлен на сервер. Это открывает проблему безопасности, потому что это означает, что незашифрованный пароль отправляется на сервер, и если злоумышленник может прослушать и получить доступ, что вся ваша безопасность в PHP бесполезна. ВСЕГДА передайте данные БЕЗОПАСНО, это делается через SSL, но будьте утомлены, даже если SSL не безупречен (например, недостаток OpenSSL Heartbleed).

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

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

Вот класс PHP, который легко создает хеш и соль для пароля

http://git.io/mSJqpw