Шифрование пароля php: PHP: password_hash — Manual

Хранение пароля пользователя в базе в зашифрованном виде

• Главная
• ->
• Материалы
• ->
• Хранение пароля пользователя в базе в зашифрованном виде

Reg.ru: домены и хостинг

Крупнейший регистратор и хостинг-провайдер в России.

Более 2 миллионов доменных имен на обслуживании.

Продвижение, почта для домена, решения для бизнеса.

Более 700 тыс. клиентов по всему миру уже сделали свой выбор.

Перейти на сайт->

Бесплатный Курс «Практика HTML5 и CSS3»

Освойте бесплатно пошаговый видеокурс

по основам адаптивной верстки

на HTML5 и CSS3 с полного нуля.

Начать->

Фреймворк Bootstrap: быстрая адаптивная вёрстка

Пошаговый видеокурс по основам адаптивной верстки в фреймворке Bootstrap.

Научитесь верстать просто, быстро и качественно, используя мощный и практичный инструмент.

Верстайте на заказ и получайте деньги.

Получить в подарок->

Бесплатный курс «Сайт на WordPress»

Хотите освоить CMS WordPress?

Получите уроки по дизайну и верстке сайта на WordPress.

Научитесь работать с темами и нарезать макет.

Бесплатный видеокурс по рисованию дизайна сайта, его верстке и установке на CMS WordPress!

Получить в подарок->

*Наведите курсор мыши для приостановки прокрутки.

Назад
Вперед

Хранение пароля пользователя в базе в зашифрованном виде

Тема безопасности веб-приложений была важна всегда — с момента появления первых сайтов.

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

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

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

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

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

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

Наконец, мы добьемся вывода ошибок валидации на русском языке.

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

Для ознакомления с содержанием уроков Вы можете просмотреть видео ниже. Скачать видеоуроки в высоком качестве можно по ссылкам выше.

P.S. Хотите нормально кодировать на PHP? Обратите внимание на премиум-уроки по различным аспектам сайтостроения, включая программирование на PHP, а также на бесплатный курс по созданию своей CMS-системы на PHP с нуля. Все это поможет вам быстрее и проще освоить этот мощный язык веб-разработки:

Понравился материал и хотите отблагодарить?

Просто поделитесь с друзьями и коллегами!

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

Наверх

Необратимое шифрование MD5 в PHP — PHP — WEB Программирование — Каталог статей

Зачем это нужно?При необратимом шифровании информация зашифровывается таким образом, что не подлежит обратной расшифровке. На первый взгляд это может показаться странным, в действительности же такой метод шифрования ис-пользуется очень часто. Функции, с помощью которых реализуется однонаправленное шифрование, называются функциями хеширования. При использовании таких функций создается уникальный хеш-код строки. Наиболее часто в качестве алгоритма хеширования применяется алгоритм MD5, реализовать который можно с помощью одноименной функции:

Code

string md5(string str[, bool raw_output])

В качестве обязательного аргумента эта функция принимает строку str, которую необходимо зашифровать, и возвращает ее уникальный 128-битовый хеш-код. Если необязательный аргумент raw_output имеет значение true, то возвращается бинарная строка из 16 символов. Вероятность того, что две строки дадут одинаковый хешкод, стремится к нулю.
Аналогичная функция md5_file () часто используется для создания уникального хеш-кода объемных файлов, которые передаются по сети. Загрузив файлы, всегда можно проверить целостность хеш-кода, вычислив его по алгоритму MD5 и сравнив полученный результат с хеш-кодом, предоставляемым распространителем. Это позволяет отследить повреждения файла, вызванные передачей через сеть, а так же предотвращает фальсификацию файла. Такой способ часто применяют при распространении объемных дистрибутивов.
При помощи этой функции можно зашифровывать различные данные, к примеру, пароли пользователей. Это предоставляет возможность организовать следующий алгоритм авторизации пользователей. При первой регистрации пользователя сохраняется хеш-код его пароля (к примеру, в базе данных). При дальнейших посещениях странички хеш-код вводимого пользователем пароля сравнивается с сохраненным ранее хеш-кодом. Если эти отпечатки совпадают, авторизация считается успешной.
Такая схема авторизации не позволяет получить непосредственный доступ к паролям, даже если происходит хищение базы данных. В этом случае злоумышленник вынужден тратить значительное машинное время на перебор паролей по словарю, поэтому пароли вида W5t7,9yuP практически не поддаются расшифровке, в то же время необратимое шифрование не сможет защитить от перебора при пароле вида 12345.

Биржа копирайтинга, статей, копирайтеров, контента, фриланса

Биржа копирайтеров Адвего — поставщик уникальных текстов №1

Заказывайте уникальный контент на крупнейшей бирже копирайтинга Адвего: тексты для интернет-магазинов, новости, информационные и рекламные статьи, крауд-маркетинг . Покупайте готовые авторские статьи с фото в магазине. Проверяйте уникальность антиплагиатом бесплатно на копипаст и рерайтинг, оценивайте качество текстов с помощью бесплатного SEO-анализа и проверки орфографии. Работайте в интернете во время карантина удаленно — копирайтером, комментатором, рерайтером, переводчиком, автором статей.

Адвего — это универсальная площадка для заказа текстов, фото и любого контента для сайтов — от одной статьи до наполнения целых порталов.

Обеспечьте быстрое наполнение сайта, каталога, интернет-магазина текстами и статьями — каждый день копирайтеры в Адвего выполняют более 10 000 работ.

Заказывайте на бирже копирайта уникальные SEO-тексты для продвижения сайта с ключами и запросами:

• описания для товаров и услуг;
• новости, обзоры;
• комментарии и отзывы.

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

Все тексты для биржи рерайтинга и копирайтинга бесплатно проверяются антиплагиатом Адвего, вам нужно лишь оплатить готовые статьи и разместить на сайте. Копирайтинг — процесс многосторонний, требующий больших знаний и серьёзных навыков. Продукт «copywriting» придает любому ресурсу вес, делает его интересным для посетителей и конкурентоспособным в борьбе за позиции в рейтингах. Если нужна помощь в публикации, подберите в Адвего контент-менеджера и поручите ему проверку и размещение текстов.

Биржа статей и магазин готового контента Адвего

Выбирайте из более чем 25 000 проверенных уникальных статей — каждый день добавляется больше тысячи новых текстов.

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

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

Биржа контента на заказ — тексты, графика, фото, услуги

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

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

Также для вас выполнят нестандартные задания — от создания фото- и видеоколлажей до тайных покупателей и тестирования товаров.

Круглосуточная служба поддержки Адвего работает на сайте, в чате, по e-mail и в Skype — обращайтесь, и вам помогут создать заказ и найти исполнителей.

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

Адвего — крупнейшая SEO-биржа отзывов и платных обзоров из всех популярных топ рейтингов бирж копирайта, исполнители разместят сотни положительных рекомендаций и упоминаний о вашей компании в интернете: наполнение форумов, в блогах и отзовиках. В соцсетях вы получите тысячи участников для своих групп, лайки и репосты публикаций, отзывы и комментарии

Для интернет-агентств и SEO-студий — удобная работа с исполнителями в едином интерфейсе, все технические вопросы по выплатам Адвего берет на себя. Бесплатно предоставляются: автоматическая проверка уникальности и плагиата, круглосуточная служба поддержки, API для создания заказов и выгрузки текстов.

Биржа фриланса — надежная работа для фрилансеров

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

Доступ ко всем сервисам Адвего бесплатен, а вывод средств возможен на кошельки Webmoney, Qiwi и банковские карты РФ и всех стран мира.

Развивайте карьеру фрилансера копирайтера и легально зарабатывайте онлайн — для работы нужен только доступ к интернету и компьютер.

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

хеш — шифрование паролей для PHP 5.3 или стоит ли обновляться до 5.5+?

Обновление до последней поддерживаемой стабильной ветки PHP — это , рекомендуемый маршрут простой и понятный.

При этом вы заметили, что работаете с GoDaddy. Какие из их услуг вы используете для проекта? Если это их линия общего хостинга или любая линия, предлагающая cPanel, обновление версий PHP не должно увеличивать текущие расходы. Любой провайдер веб-хостинга, обладающий здравым смыслом, должен иметь возможность легко запускать EasyApache, встроенную утилиту cPanel для обновления и обновления Apache, PHP и различных других программ.

Если вы используете VPS, облачный сервер или выделенный сервер, вышеуказанное все еще применимо, если вы используете cPanel. Если вы используете barebone-комплекты и кто-то управляет всем из интерфейса командной строки (приятно!), Обновление занимает немного больше времени, хотя и ненамного. Им нужно будет убедиться, что перед компиляцией установлены правильные пакеты, или они могут просто использовать встроенные пакеты, предлагаемые апстримом.

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

Тем не менее, если ваш босс твердо настроен придерживаться устаревших выпусков, когда дело доходит до PHP 5.3.7+, я буду ссылаться на ircmaxwell и paragonie, оба из которых доступны на GitHub.

password_compat — ссылка

Цель этой библиотеки — «… обеспечить прямую совместимость с функциями password_, которые поставляются с PHP 5.5 ».

random_compat — ссылка

Цель этой библиотеки — предоставить PHP 5.x поддержка random_bytes () и random_int () (из PHP 7.x). Это не альтернатива password_compat, это просто еще один уровень совместимости, который позволит вам отключить функции, которые вы не сможете использовать (если, конечно, вы не сможете обновить).

Примечание : Если вы собираетесь использовать random_compat, убедитесь, что вы используете стабильный выпуск вместо основного (как отмечает автор).

github.com/paragonie/random_compat/releases/tag/v2.0,2

самых безопасных методов шифрования паролей в PHP

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

ХЕШИНГ ПАРОЛЯ

Методология хеширования считается одним из самых безопасных методов защиты паролей.

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

Наиболее распространенными функциями хеширования являются

мкр5 ():

Отображает хэш строки md5.

СОЛЬ

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

Как хранить соли?

Crypt () и password_hash () используются для хранения солей.

Склеп ():

По сути, это одностороннее хеширование. Crypt () используется для получения хешированной строки. Его общий синтаксис содержит параметр соли, который является необязательным, но без соли создается слабый пароль. Эта функция использует алгоритмы MD5, Blowfish и DES. Производительность этой функции зависит от операционной системы.

ПАРОЛЬ_ХЭШ ()

Создает новые пароли с помощью одностороннего алгоритма хеширования. Он совместим с crypt (). Password_hash () — один из самых надежных методов создания безопасных паролей.

Password_verify ()

Используется для проверки соответствия введенного пароля шифрованию.

Пример

$ hash = «$ 2y $ 07 $ BCryptRequires22Chrcte / VlQH0piJtjXl.0t1XkA8pw9dMXTpOq»;

Если (password_verify (‘rasmuslerdorf’, $ hash))

{

echo «Пароль действителен!»;

}

еще

{

echo «Неверный пароль.’;

}

?>

Выход

Пароль действующий!

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

Шифрование паролей — PHP — Форум W3Schools

Я удивлен, что никто не попытался объяснить цель соли, поскольку из этого можно вывести ответы на большинство вопросов. Во-первых, цель хеширования пароля помогает, ЕСЛИ злоумышленник каким-то образом получает доступ к вашей базе данных — если они это сделают, они увидят хэш, а не исходный пароль.Но что, если два или более ваших пользователя используют один и тот же пароль (например, «123456» … это один очень популярный пароль)? Злоумышленник сначала не узнает исходный пароль, но он увидит всех пользователей, у которых есть этот пароль. Взлом этого одного пароля разблокирует не только одного пользователя, но и всех пользователей, у которых есть этот пароль. Вот тут и появляется соль … Цель состоит в том, чтобы сделать хеши для одного и того же пароля разными. Таким образом, злоумышленник не узнает, используют ли два пользователя один и тот же пароль. Взлом одного хеша позволит злоумышленнику получить доступ только к этому одному пользователю, а не ко всем, кто использует этот пароль.Но как это сделать? Если вы объедините случайно сгенерированную строку с паролем, вы убедитесь, что полученный хэш будет другим. Случайно сгенерированная строка называется «солью». Единственный способ, которым злоумышленник может узнать, что два пользователя используют один и тот же пароль, — это если и хэш, и соль одинаковы, но поскольку соль генерируется случайным образом, шансы на это очень малы. , вам нужно хранить соль вместе с хешем. Таким образом, при аутентификации пользователей вы добавите ранее сгенерированную соль и посмотрите, совпадает ли хеш с хешем в базе данных.Имея это в виду (кстати говоря, мне очень жаль, что у вас сейчас болит голова) …

1. Что лучше: хешировать (sha2) пароль, а затем солить или солить и чем хешировать?

Эти две вещи выполняются вместе. Вы объединяете соль с паролем и хешируете полученную строку.

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

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

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

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

4. Я видел несколько кодов, в которых соль, и / или хэш, и / или пароль были разделены на два (например: hash.salt1a.password.salt1b или password1a.salt.password1b или salt.hash2a.password.hash2b и т. Д. ) Это хорошая идея ? Неужели это безопаснее? Если да, то что будет более безопасным (разделение пароля, хеша или соли)?

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

5. Хорошее ли двойное хеширование (например: (sha1 (md5 ($ password)))?

Как и в предыдущем случае, да, но не намного лучше. возможностей ограничено), и только самое внутреннее имеет значение. На самом деле, если ваш самый внутренний — это md5, это на самом деле хуже, потому что MD5 в настоящее время может быть очень легко расшифрован (возможно, не до исходного пароля, но, безусловно, для строка, которая генерирует такой же хеш).В качестве альтернативы, если злоумышленник знает, как вы выполняете хеширование, он может рассматривать всю последовательность хеш-функций как одну гигантскую хеш-функцию, поэтому, в конце концов, им потребуется примерно одно и то же время, чтобы взломать пароль (за исключением того, что они на каждую попытку потребуется еще несколько миллисекунд).

6. Я что-то читал про пароль соль и перец ?? Что такое перец? Это какая-то вторая соль?

Где ты это читал? Судя по очень ограниченному поиску в Google, который я сделал, кажется, что цель в основном та же, что и цель разделения соли (уменьшить вероятность повторения соли и хэша), только вместо разделения соли идея состоит в том, чтобы случайным образом выберите число / строку, соответствующую методу объединения пароля и соли.Таким образом, чтобы злоумышленник знал, что пароль используется пользователями совместно, хэш, соль и «перец» должны совпадать, а чтобы узнать исходный пароль, злоумышленник должен реализовать все методы «перца» и переключить их. соответственно для каждого пользователя. Подобно разделению соли, это не улучшает безопасность значительно, но, в отличие от двойного хеширования, не может ухудшить безопасность. Между разделением соли и перцем, я бы выбрал перец, но это в основном вопрос предпочтений.С точки зрения злоумышленника, оба одинаково сложно взломать — в любом случае, чтобы знать, что пароль одинаковый, все компоненты должны совпадать, а для взлома вам нужно знать, как соль (и) и хеш (а) объединены, что может быть одним методом (без перца) или несколькими методами (с перцем), но если злоумышленник сможет обнаружить один метод, он, вероятно, обнаружит и все методы перца.

Безопасное хеширование паролей с добавлением соли — как это сделать правильно

Поиск хеша (яблоко) в списке хешей пользователей…: Соответствует [alice3, 0bob0, charles8]
Поиск хэша (blueberry) в списке хэшей пользователей …: Соответствует [usr10101, timmy, john91]
Поиск хэша (letmein) в списке хэшей пользователей … : Соответствует [wilson10, dragonslayerX, joe1984]
Поиск хэша (s3cr3t) в списке хэшей пользователей …: Соответствует [bruce19, knuth2337, john87]
Поиск хэша (z @ 29hjja) в списке хэшей пользователей … : Ни один пользователь не использовал этот пароль

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

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

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

Добавление соли

хэш ( «Привет») = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
хэш ( «Привет» + «QxLUF1bgIAdeQX») = 9e209040c863f84a31e719795b2577523954739fe5ed3b58a75cff2127075ed1
хэш ( «Привет» + «bv5PehSMfV11Cd») = d1d3ec2e6f20fd420d50e2642992841d8338a314b8ea157c9e18477aaef226ab
хэш ( «Привет» + «YYLmfY6IehjZMQ») = a49670c3c18b9e079b9cfaf51634f563dc8ae3070db2c4a8544305df1b60f007

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

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

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

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

НЕПРАВИЛЬНЫЙ способ: короткое повторное использование соли и соли

Наиболее распространенные ошибки реализации соли — это повторное использование одной и той же соли в нескольких
хеши или использование слишком короткой соли.

Повторное использование соли

Распространенная ошибка — использовать одну и ту же соль в каждом хэше. Либо соль
жестко запрограммированы в программу или генерируются случайным образом один раз. Это неэффективно
потому что, если у двух пользователей один и тот же пароль, у них все равно будет один и тот же хэш.
Злоумышленник по-прежнему может использовать атаку по таблице обратного просмотра для запуска словаря.
атака на каждый хэш одновременно. Им просто нужно нанести соль на каждый
угадайте пароль, прежде чем они его хэшируют. Если соль жестко закодирована в популярном
продукта, таблицы поиска и радужные таблицы могут быть построены для этой соли, чтобы сделать ее
легче взламывать хэши, сгенерированные продуктом.

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

Короткая соль

Если соль слишком короткая, злоумышленник может построить таблицу поиска для каждого
возможна соль. Например, если соль состоит только из трех символов ASCII, там
всего 95x95x95 = 857 375 возможных солей. Может показаться, что это много, но если
каждая таблица поиска содержит только 1 МБ наиболее распространенных паролей вместе
они будут всего 837 ГБ, что немного, учитывая, что жесткие диски на 1000 ГБ могут
быть купленным менее чем за 100 долларов сегодня.

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

Чтобы злоумышленник не мог создать таблицу поиска для каждого
возможна соль, соль должна быть длинной. Хорошее практическое правило — использовать соль, которая
имеет тот же размер, что и результат хеш-функции.Например, вывод
SHA256 составляет 256 бит (32 байта), поэтому соль должна быть не менее 32 случайных байтов.

НЕПРАВИЛЬНЫЙ способ: двойное хеширование и дурацкие хеш-функции

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

Вот несколько примеров плохих дурацких хеш-функций, которые я видел на форумах в Интернете.

• md5 (sha1 (пароль))
• md5 (md5 (соль) + md5 (пароль))
• sha1 (sha1 (пароль))
• sha1 (str_rot13 (пароль + соль))
• md5 (sha1 (md5 (md5 (пароль) + sha1 (пароль)) + md5 (пароль)))

Не используйте ничего из этого.

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

Злоумышленник не может атаковать хэш, если он не знает алгоритма, но обратите внимание на алгоритм Керкхоффа.
принцип, что злоумышленник обычно будет иметь доступ к исходному коду
(особенно если это бесплатное программное обеспечение или программное обеспечение с открытым исходным кодом), и это с учетом некоторых
пары пароль-хеш из целевой системы, отменить несложно
разработать алгоритм.На вычисление дурацких хэш-функций уходит больше времени, но
только небольшим постоянным множителем. Лучше использовать итерационный алгоритм, который
спроектирован так, чтобы его было чрезвычайно трудно распараллелить (это обсуждается ниже). А также,
правильное засоление хеша решает проблему с радужной таблицей.

Если вы действительно хотите использовать стандартизированную «дурацкую» хеш-функцию, такую ​​как HMAC, тогда ничего страшного.
Но если вы сделали это для того, чтобы замедлить вычисление хэша, сначала прочтите раздел ниже о растяжении ключей.

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

Хэш-коллизии

Поскольку хеш-функции отображают произвольные объемы данных в строки фиксированной длины,
должны быть некоторые входные данные, которые хешируются в одну и ту же строку. Криптографический хеш
функции предназначены для того, чтобы сделать эти столкновения невероятно трудными для обнаружения.Время от времени криптографы обнаруживают «атаки» на хеш-функции, которые делают
легче находить столкновения. Недавний пример — хеш-функция MD5, для которой
столкновения действительно не обнаружены.

Атаки столкновения — признак того, что это может быть более вероятно для строки, отличной от
пароль пользователя должен иметь такой же хеш. Однако обнаружение столкновений даже в
слабая хеш-функция, такая как MD5, требует много выделенной вычислительной мощности, поэтому она
Очень маловероятно, что на практике эти столкновения произойдут «случайно».А
хеширование пароля с использованием MD5 и соли для всех практических целей так же, как
безопасный, как если бы он был хеширован с помощью SHA256 и соли. Тем не менее, это хороший
идея использовать более безопасную хеш-функцию, такую ​​как SHA256, SHA512, RipeMD или
ПОЖАЛУЙСТА, если возможно.

Правильный способ: как правильно хешировать

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

Основы: перемешивание с солью

Предупреждение: не просто читайте этот раздел. Вы обязательно должны реализовать
материал в следующем разделе: «Усложнение взлома паролей: медленное хеширование
Функции ».

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

Соль должна генерироваться с использованием криптографически безопасного псевдослучайного кода .
Генератор чисел (CSPRNG).CSPRNG сильно отличаются от обычных
генераторы псевдослучайных чисел, такие как язык «C»
rand () функция. Как следует из названия, CSPRNG являются
спроектированы так, чтобы быть криптографически безопасными, что означает, что они обеспечивают высокий уровень
случайность и совершенно непредсказуемы. Мы не хотим, чтобы наши соли были
предсказуемо, поэтому мы должны использовать CSPRNG. В следующей таблице перечислены некоторые CSPRNG.
которые существуют для некоторых популярных платформ программирования.

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

для хранения пароля

1. Сгенерируйте длинную случайную соль, используя CSPRNG.
2. Добавьте соль к паролю и хешируйте его с помощью стандартной функции хеширования паролей , такой как Argon2, bcrypt, scrypt или PBKDF2.
3. Сохраните соль и хэш в записи базы данных пользователя.

Проверка пароля

1. Получить соль и хэш пользователя из базы данных.
2. Добавьте соль к данному паролю и хешируйте его, используя ту же хеш-функцию.
3. Сравните хэш заданного пароля с хешем из базы данных. Если они совпадают, пароль правильный. В противном случае пароль неверный.

В веб-приложении

всегда хэш на сервере

Если вы пишете веб-приложение, вам может быть интересно: , а где — хешировать.Если пароль хешируется в браузере пользователя с помощью JavaScript, или должен
отправить его на сервер «в открытом виде» и там хешировать?

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

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

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

• Хеширование паролей на стороне клиента — , а не , заменяющий HTTPS.
  (SSL / TLS). Если соединение между браузером и сервером установлено
  небезопасно, человек посередине может изменить код JavaScript как есть
  загружен, чтобы удалить функцию хеширования и получить пользовательский
  пароль.

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

• Вам также нужно солить хэши на стороне клиента. Очевидное решение —
  заставить клиентский сценарий запрашивать у сервера соль пользователя.Не делай
  это потому, что он позволяет плохим парням проверять, действительно ли имя пользователя без
  зная пароль. Поскольку вы перемешиваете и солите (с хорошим
  соль) на сервере тоже, можно использовать имя пользователя (или адрес электронной почты)
  объединены со строкой, зависящей от сайта (например, доменным именем), в качестве
  клиентская соль.

Усложнение взлома паролей: медленное хеширование

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

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

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

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

Если вы используете хэш растяжения ключа в веб-приложении, имейте в виду, что вы
потребуются дополнительные вычислительные ресурсы для обработки больших объемов
запросы аутентификации, и это растяжение ключа может облегчить запуск
Атака отказа в обслуживании (DoS) на ваш сайт.Я все еще рекомендую использовать ключ
растяжение, но с меньшим количеством итераций. Вы должны рассчитать
количество итераций на основе ваших вычислительных ресурсов и ожидаемого
максимальная частота запросов аутентификации. Угроза отказа в обслуживании может быть
устраняется, заставляя пользователя вводить CAPTCHA каждый раз при входе в систему.
Всегда проектируйте свою систему так, чтобы количество итераций можно было увеличить или
снизился в будущем.

Если вас беспокоит вычислительная нагрузка, но вы все еще хотите использовать ключ
растягивание в веб-приложении, рассмотрите возможность запуска растягивания клавиш
алгоритм в браузере пользователя с помощью JavaScript.Стэнфордская криптовалюта JavaScript
Библиотека включает PBKDF2. Количество итераций должно быть достаточно низким.
что систему можно использовать с более медленными клиентами, такими как мобильные устройства, и
система должна вернуться к вычислениям на стороне сервера, если браузер пользователя
не поддерживает JavaScript. Растяжение клавиши на стороне клиента не устраняет
необходимость хеширования на стороне сервера. Вы должны хешировать хэш, сгенерированный клиентом
так же, как и обычный пароль.

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

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

Это не так просто, как кажется. Ключ должен храниться в секрете от
злоумышленник даже в случае взлома. Если злоумышленник получает полный доступ к
системы, они смогут украсть ключ независимо от того, где он хранится.Ключ должен храниться во внешней системе, например, в физически отдельном
сервер, предназначенный для проверки пароля, или специальное аппаратное устройство
прикреплен к серверу типа ЮбиХСМ.

Я настоятельно рекомендую этот подход для любого крупного масштаба (более 100 000
пользователей) сервис. Считаю необходимым для любой услуги хостинга более чем
1000000 учетных записей пользователей.

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

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

Прочие меры безопасности

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

Даже опытные разработчики должны иметь образование в области безопасности, чтобы писать безопасные приложения.
Отличный ресурс для изучения уязвимостей веб-приложений —
Открытое веб-приложение
Проект безопасности (OWASP).Хорошее введение — это
Список десяти наиболее уязвимых уязвимостей OWASP.
Если вы не разбираетесь во всех уязвимостях в списке, не пытайтесь
написать веб-приложение, которое работает с конфиденциальными данными. Это работодатель
ответственность за обеспечение надлежащего обучения всех разработчиков безопасным
разработка приложения.

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

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

Часто задаваемые вопросы

Какой алгоритм хеширования мне следует использовать?

DO использование:

НЕ используйте :

• Быстрые криптографические хеш-функции, такие как MD5, SHA1, SHA256, SHA512, RipeMD, WHIRLPOOL, SHA3 и т. Д.
• Небезопасные версии крипты (1 доллар, 2 доллара, 2 доллара, 3 доллара).
• Любой алгоритм, который вы разработали самостоятельно. Используйте только те технологии, которые являются общественным достоянием и были хорошо протестированы опытными криптографами.

Несмотря на то, что нет никаких криптографических атак на MD5 или SHA1, которые делают
их хеши легче взломать, они старые и широко считаются
(несколько неправильно), чтобы не подходить для хранения паролей. Так что я не
рекомендую их использовать. Исключением из этого правила является PBKDF2, который
часто реализуется с использованием SHA1 в качестве базовой хеш-функции.

Как разрешить пользователям сбрасывать свой пароль, если они его забыли?

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

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

Срок действия токена должен истечь через 15 минут или после его использования, в зависимости от того, что
на первом месте. Также рекомендуется истечь все существующие токены паролей, когда
пользователь входит в систему (он запомнил свой пароль) или запрашивает повторный сброс
токен. Если срок действия токена не истекает, его можно навсегда использовать для взлома
аккаунт пользователя. Электронная почта (SMTP) — это простой текстовый протокол, и может быть
вредоносные маршрутизаторы в Интернете, записывающие почтовый трафик. И электронная почта пользователя
учетная запись (включая ссылку для сброса) может быть взломана спустя долгое время после ввода пароля
был изменен.Если срок действия токена истекает как можно скорее,
подверженность пользователя этим атакам.

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

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

Что мне делать, если произошла утечка / взлом базы данных моей учетной записи?

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

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

Объясните своим пользователям, как именно были защищены их пароли — надеюсь
посыпали солью — и что, несмотря на то, что они были защищены соленым
хеша, злонамеренный хакер по-прежнему может проводить атаки по словарю и методом перебора
хеши.Злоумышленники будут использовать любые найденные пароли, чтобы попытаться войти в
учетной записи пользователя на другом веб-сайте, надеясь, что они использовали тот же пароль на
оба сайта. Сообщите своим пользователям об этом риске и порекомендуйте им изменить
их пароль на любом веб-сайте или в сервисе, где они использовали аналогичный пароль.
Заставьте их сменить пароль для вашей службы при следующем входе в систему.
Большинство пользователей попытаются «сменить» свой пароль на исходный, чтобы получить
вокруг принудительно меняют быстро. Используйте текущий хэш пароля, чтобы убедиться, что
они не могут этого сделать.

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

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

Какой должна быть моя политика паролей? Следует ли мне применять надежные пароли?

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

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

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

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

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

Почему мне нужно использовать специальный алгоритм, такой как HMAC? Почему я не могу просто добавить
пароль к секретному ключу?

Хеш-функции, такие как MD5, SHA1 и SHA2, используют
Конструкция Меркла-Дамгарда, которая делает их уязвимыми для известных
как атаки удлинения длины.Это означает, что при наличии хэша H (X) злоумышленник может
найти значение H (pad (X) + Y) для любой другой строки Y, не зная X.
pad (X) — это функция заполнения, используемая хешем.

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

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

Должна ли соль быть до или после пароля?

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

Почему хеш-код на этой странице сравнивает хеш-коды в
«длина-константа»
время?

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

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

Например, стандартное сравнение строк «xyzabc» и
«abcxyz» сразу увидит, что первый символ отличается
и не стал бы проверять оставшуюся часть строки. С другой стороны, когда
строки «aaaaaaaaaaB» и «aaaaaaaaaaZ» сравниваются,
алгоритм сравнения просматривает блок «а», прежде чем он определит
струны неравны.

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

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

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

Как работает код SlowEquals?

Предыдущий вопрос объясняет, почему необходим SlowEquals, этот объясняет
как на самом деле работает код.

1. частное статическое логическое значение slowEquals (byte [] a, byte [] b)
2.»оператор для сравнения целых чисел на равенство вместо
оператор «==». Причина объясняется ниже. Результат XORing
два целых числа будут равны нулю тогда и только тогда, когда они точно такие же. Это
потому что 0 XOR 0 = 0, 1 XOR 1 = 0, 0 XOR 1 = 1, 1 XOR 0 = 1. Если мы применим это к
все биты в обоих целых числах, результат будет нулевым, только если все биты
совпадает.

Итак, в первой строке, если а. Длина равна
b.length , переменная diff получит нулевое значение, но если нет, то она
получит какое-то ненулевое значение.Затем мы сравниваем байты с помощью XOR и OR
результат в diff. Это установит для diff ненулевое значение, если байты различаются.
Поскольку операция ИЛИ никогда не сбрасывает биты, единственный способ diff будет равен нулю в конце
цикл — если он был равен нулю до начала цикла (a.length == b.length) и все
байтов в двух массивах совпадают (ни один из XOR не привел к ненулевому
ценить).

Причина, по которой нам нужно использовать XOR вместо оператора «==» для сравнения целых чисел
заключается в том, что «==» обычно переводится / компилируется / интерпретируется как ветка.b «должен компилироваться во что-то вроде
следующие, время выполнения которых не зависит от равенства
целые числа:

MOV EAX, [A]
XOR EAX, [B]
OR [DIFF], EAX

Зачем заморачиваться с хешированием?

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

Хеширование паролей | Руководство разработчика Adobe Commerce

В настоящее время Magento использует собственную стратегию хеширования паролей, основанную на различных собственных алгоритмах хеширования PHP. Magento поддерживает несколько алгоритмов, таких как MD5 , SHA256 или Argon 2ID13 . Если установлено расширение Sodium (установлено по умолчанию в PHP 7.3), то в качестве алгоритма хеширования по умолчанию будет выбран Argon 2ID13 .В противном случае SHA256 будет по умолчанию. Magento может использовать встроенную функцию PHP password_hash с поддержкой алгоритма Argon 2i.

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

.

  
 
 
 
 
 1
 
 password_hash: salt: version : version 
 
 
, где  версия  …  версия   представляет все версии алгоритмов хеширования, используемые в пароле.Кроме того, соль всегда хранится вместе с хешем пароля, поэтому мы можем восстановить всю цепочку алгоритмов. Пример выглядит так:
  
 
 
 
 
 1
 
 a853b06f077b686f8a3af80c98acfca763cf10c0e03597c67e756f1c782d1ab0: 8qnyO4h2OYIfGCUb: 1: 2
 
 
 Первая часть представляет собой хэш пароля. Второй,  8qnyO4h2OYIfGCUb  — это соль. Последние два — это разные хеш-алгоритмы: 1 — это  SHA256,  и 2 — это  Argon 2ID13 .Это означает, что пароль клиента изначально был хеширован с использованием  SHA256 , а затем алгоритм был обновлен с использованием  Argon 2ID13 , а хеш был повторно хеширован с помощью Argon.
 Обновление стратегии хеширования 
 Рассмотрим, как выглядит механизм обновления хэша. Предположим, что изначально пароль был хеширован с помощью  MD5 , а затем алгоритм был обновлен несколько раз с помощью Argon 2ID13. На следующей диаграмме показан процесс обновления хэша.
 Каждый алгоритм хеширования использует хеш предыдущего пароля для создания нового хеша.Magento не хранит исходный необработанный пароль.
 Как обсуждалось выше, хэш пароля может иметь несколько версий хеша, примененных к исходному паролю.
 Вот как работает механизм проверки пароля при аутентификации клиента.
  
 
 
 
 
 1
2
3
4
5
6
7
8
9
10
11
12
13
 
 def verify (пароль, хеш):
    восстановлен = пароль

    hash_map = извлечение (хеш)
    # перебираем все версии, указанные в полученном хэше [md5, sha256, argon2id13]
    для версии в hash_map.get_versions ():
        # генерировать новый хеш на основе пароля / предыдущего хеша, соли и версии
        восстановлено = hash_func (соль. восстановлено, версия)

    # извлекаем из цепочки hash: salt: version только хэш пароля
    hash = hash_map.get_hash ()

    вернуть сравнение (восстановлено, хеш)
 
 
 Поскольку Magento хранит все использованные версии хешей паролей вместе с хешем пароля, мы можем восстановить всю цепочку хешей во время проверки пароля. Механизм проверки хэша аналогичен стратегии обновления хэша: на основе версий, хранящихся вместе с хешем пароля, алгоритм генерирует хеш-коды из предоставленного пароля и возвращает результат сравнения между хешированным паролем и хешем, хранящимся в базе данных.
 Реализация 
 Класс  \ Magento \ Framework \ Encryption \ Encryptor  отвечает за создание и проверку хэша пароля. Команда  bin / magento customer: hash: upgrade  обновляет хэш пароля клиента до последнего алгоритма хеширования.
 Лучшее шифрование паролей — запрос функции 
 Можно ли добавить в Wappler параметры медленного шифрования хэша (например, PBKDF2 или bcrypt)?
 Я спрашиваю, потому что не был уверен, какие криптографические параметры Wappler по умолчанию мне следует использовать для шифрования паролей пользователей для моего веб-приложения.Итак, я немного погуглил, и рекомендуемые варианты кажутся PBKDF2, bcrypt или scrypt.
 Насколько я могу судить, Wappler не предлагает ничего из этого. Вот скриншот текущих криптографических опций Wappler…
 Эта статья о безопасности несколько датирована (2013 г.), но общий вывод…
 Пароли следует хешировать с помощью PBKDF2, bcrypt или scrypt. MD-5 и SHA-3 никогда не должны использоваться для хеширования паролей, а SHA-1/2 (пароль + соль) также являются большим запретом.В настоящее время наиболее проверенным алгоритмом хеширования, обеспечивающим максимальную безопасность, является bcrypt. PBKDF2 тоже неплох, но если вы можете использовать bcrypt, вам следует. Scrypt, хотя и считается очень безопасным, давно не существует, поэтому его не часто рекомендуют, но, похоже, он станет преемником bcrypt, как только он просуществует немного дольше. Обратите внимание: несмотря на то, что для PBKDF2 и bcrypt существуют некоторые предостережения и стратегии перебора паролей, они по-прежнему считаются неприменимыми для надежных паролей (паролей длиной более 8 символов, содержащих цифры, буквы, знаки и хотя бы одну заглавную букву).
 В несколько более поздней статье по безопасности (от 2016 г.) говорится…
… не рекомендуется, чтобы обычные веб-приложения использовали какие-либо члены семейства SHA, будь то SHA1, SHA256 или даже SHA512 для хеширования паролей. Причина в том, что все эти хеши — это  быстрых хэша . Когда злоумышленник получает доступ к вашей базе данных хэшей паролей и у него также есть копия вашей соли, которую он предположительно получит, учитывая, что ваш сервер был скомпрометирован, тогда пароли ваших пользователей окажутся в опасности.Благодаря быстрому хешированию злоумышленник может вычислять миллиарды хешей в секунду в автономной атаке.
 Я также прочитал несколько других статей, и общее мнение, кажется, таково, что быстрые хеши (например, семейство SHA) менее безопасны и не рекомендуются, в то время как медленные хеши (например, PBKDF2, bcrypt и scrypt) рекомендуются. Я считаю, что фреймворки Laravel и Rails используют bcrypt. Существует PHP-реализация PBKDF2.
 В этой подробной статье о безопасности 2019 также рекомендуется медленное хеширование.
 Я не эксперт по безопасности, поэтому, если я неправильно понимаю текущие параметры шифрования Wappler, сообщите мне.
 Очень признателен!
 Различий между шифрованием и хешированием — GCN 
 Почему соленый хеш так же хорош для паролей, как и для завтрака 
 Уильям Джексон
 2 декабря 2013 г.
 Пароли остаются основным средством сетевой аутентификации и должны быть защищены при хранении на сервере.Шифрование — это вариант, но он имеет присущую этому приложению слабость, поскольку сервер, проверяющий пароль, должен иметь ключ для его расшифровки. Злоумышленник, укравший файл с зашифрованными паролями, также может украсть ключ.
 Хеширование — лучший вариант, особенно при разумном использовании соли, по мнению математика Эндрю Регеншайда и компьютерного ученого Джона Келси из отдела компьютерной безопасности Национального института стандартов и технологий.
 Шифрование — это двусторонняя функция; то, что зашифровано, можно расшифровать с помощью правильного ключа.Однако хеширование — это односторонняя функция, которая шифрует простой текст для создания уникального дайджеста сообщения. При правильно разработанном алгоритме невозможно отменить процесс хеширования, чтобы раскрыть исходный пароль. Затем злоумышленник, укравший файл хешированных паролей, должен угадать пароль.
 Вот как это работает: пользователь вводит пароль и идентификатор в браузере и отправляет их (желательно по защищенной ссылке) на сервер аутентификации.Сервер использует идентификатор для поиска связанного профиля сообщения. Пароль, представленный пользователем, затем хешируется с использованием того же алгоритма, и если полученный дайджест сообщения совпадает с тем, который хранится на сервере, он аутентифицируется.
 В этом процессе сервер не хранит пароли в открытом виде и не видит их. Кража хешированных файлов приносит злоумышленнику мало пользы, поскольку злоумышленник не может отменить процесс хеширования.
 Но поскольку люди редко используют полностью случайные пароли, есть уловка, с помощью которой можно угадать пароли в файле.Злоумышленник может запустить набор из миллиона или около того часто используемых паролей с помощью алгоритма хеширования и получить список, называемый радужной таблицей, связанных дайджестов сообщений для этих паролей. Сравнивать файл украденных хэшей паролей с радужной таблицей — это детская игра. Для каждого совпадения в таблице будет отображаться пароль для этого хэша.
 Защита от этого заключается в добавлении хеш-кода: добавление случайного числа к каждому паролю перед его хешированием. Результирующий дайджест сообщения является продуктом как пароля, так и значения соли и не будет совпадать ни с чем в радужной таблице.
 Конечно, злоумышленник всегда может попробовать добавить случайные значения к обычным паролям, чтобы найти соответствующий хэш, но теперь сложность угадывания пароля делает это непрактичным.
Добавить комментарий Отменить ответ
Ваш адрес email не будет опубликован. Обязательные поля помечены *
Комментарий *
Имя * 
Email * 
Сайт