Как получить пароль из хеша

Обновлено: 30.06.2024

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

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

Важно

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

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

Итак, если пользователь забудет свой пароль, нам придется выслать ему временный пароль; или попросите его сбросить пароль. Сейчас это обычное дело, верно?

1. Простейший хэш пароля с алгоритмом MD5

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

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

1.1. Пример хеширования Java MD5

1.2. Недостатки

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

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

2. Повышение безопасности MD5 с помощью соли

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

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

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

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

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

Важно

Нам всегда нужно использовать SecureRandom для создания хороших солей. Класс Java SecureRandom поддерживает алгоритм генератора псевдослучайных чисел SHA1PRNG, и мы можем воспользоваться им.

2.1. Как создать соль

Давайте посмотрим, как мы должны генерировать соль.

Алгоритм SHA1PRNG используется как криптографически стойкий генератор псевдослучайных чисел на основе алгоритма дайджеста сообщения SHA-1.

Обратите внимание, что если начальное число не указано, оно будет сгенерировано генератором истинных случайных чисел (TRNG).

2.2. Сгенерировать MD5 с солью

Теперь давайте посмотрим на модифицированный пример хеширования MD5:

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

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

alt + пароль + соль => Сгенерированный хеш

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

3. Улучшенная защита паролей с помощью алгоритмов SHA

SHA (Secure Hash Algorithm) – это семейство криптографических хэш-функций. Он очень похож на MD5, за исключением того, что генерирует более надежные хэши.

Однако хэши SHA не всегда уникальны, и это означает, что у нас могут быть одинаковые хэши для двух разных входных данных. Когда это происходит, это называется «столкновением». Вероятность столкновения в SHA меньше, чем MD5. Но не беспокойтесь об этих столкновениях, потому что они очень редки.

  • SHA-1 (самый простой — 160-битный хеш)
  • SHA-256 (надежнее, чем SHA-1 — 256-битный хеш)
  • SHA-384 (надежнее, чем SHA-256 — 384-битный хеш)
  • SHA-512 (надежнее, чем SHA-384 — 512-битный хеш)

Более длинный хэш сложнее взломать. Это основная идея.

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

3.1. Пример хэширования Java SHA

Давайте создадим тестовую программу для демонстрации генерации хэша SHA:

Очень быстро мы можем сказать, что SHA-512 генерирует самый надежный хэш.

4. Больше надежных хэшей с использованием алгоритма PBKDF2WithHmacSHA1

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

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

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

Эта функция в основном реализована с использованием некоторых алгоритмов с интенсивным использованием ЦП, таких как PBKDF2, Bcrypt или Scrypt. Эти алгоритмы принимают в качестве аргумента коэффициент работы (также известный как коэффициент безопасности) или количество итераций.

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

4.1. Пример хэша Java PBKDF2WithHmacSHA1

Давайте рассмотрим пример использования алгоритма PBKDF2WithHmacSHA1.

4.2. Проверка паролей

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

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

5. Хэши с использованием Bcrypt и Scrypt

Концепция, лежащая в основе bcrypt, аналогична предыдущей концепции, как в PBKDF2. Так получилось, что в Java нет встроенной поддержки алгоритма bcrypt, чтобы замедлить атаку, но тем не менее вы можете найти одну такую ​​реализацию в прилагаемом исходном коде.

5.1. Создание хэша с помощью Bcrypt с солью

Давайте посмотрим на пример кода использования (BCrypt.java доступен в исходном коде).

5.2. Создание хэша с помощью Scrypt с солью

Как и bcrypt, я скачал scrypt с github и добавил исходный код алгоритма scrypt в исходный код.

Давайте посмотрим, как использовать реализацию:

6. Заключение

  1. Сохранение текстового пароля с хешированием — самая опасная вещь для безопасности приложений на сегодняшний день.
  2. MD5 обеспечивает базовое хеширование для создания безопасного хэша пароля. Добавление соли сделает его еще крепче.
  3. MD5 генерирует 128-битный хэш. Чтобы повысить безопасность, используйте алгоритм SHA, который генерирует хэши длиной от 160 до 512 бит. 512-битная версия — самая надежная.
  4. Даже безопасные пароли, хешированные SHA, можно взломать с помощью современного высокопроизводительного оборудования. Чтобы победить это, вам понадобятся алгоритмы, которые могут замедлить атаки грубой силы и свести к минимуму воздействие. К таким алгоритмам относятся PBKDF2, BCrypt и SCrypt.
  5. Пожалуйста, хорошо подумайте, прежде чем применять соответствующий алгоритм безопасности.

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

Способ хеширования паролей и надежность паролей важны, потому что, если кто-то получит доступ к хешированным паролям, можно перепробовать много-много паролей за удивительно короткий промежуток времени и взломать любой слабый.< /p>

Вопрос, который у меня есть, заключается в том, как злоумышленник получает доступ к хешированным паролям. Если у них есть доступ, например, к файлу /etc/shadow, разве игра уже не окончена? Это просто неверные настройки разрешений? Резервные копии? Другие ошибки? Дело в том, что когда одна система скомпрометирована, пароль оттуда используется для попытки проникнуть в другие системы?

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

Вы также заметите, что чаще всего происходит утечка не паролей операционной системы ( /etc/shadow ), а паролей веб-приложений/служб. Обычно они хранятся в базе данных и поэтому уязвимы для взлома базы данных.

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

Необходимо помнить одну важную вещь: даже несмотря на то, что многие проблемы, связанные с раскрытием хэшей паролей, могут означать, что игра окончена для взломанного сервера, ценность не обязательно в этом. Взломанный сервер может быть почти бесполезен для хакера, но если эти хэши могут быть взломаны (или если они были открытым текстом и т. д.), то повторное использование пароля означает, что хакер может получить доступ к учетным записям электронной почты, банковским счетам и т. д.< /p>

5 ответов 5

Существует множество способов:

  • Внедрение SQL
  • Утечка резервных копий
  • Недовольные сотрудники сливают их
  • Любой взлом сервера, позволяющий выполнить код.

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

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

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

@JimmyJames Причина, по которой вы не найдете никакой конкретной информации о предотвращении утечки паролей, заключается в том, что это допускает практически каждая уязвимость на стороне сервера. Из 10 лучших классов уязвимостей OWASP классы 1, 2, 4, 5, 6 и 9 могут привести к утечке хэшей паролей. Другими словами, более всех усилий по обеспечению безопасности так или иначе противодействуют раскрытию хэшей паролей.

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

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

SQL-инъекция

Пример:
а ИЛИ 1=1'; exec sp_msforeachtable "SELECT * FROM?";--

Вы также можете использовать sp_msforeachdb , например:

а'; exec sp_msforeachdb 'ИСПОЛЬЗОВАТЬ ?;exec sp_msforeachTable "SELECT * FROM !","!"';--

Кнопка -- предназначена для комментирования частей оператора SQL, которые могут помешать вашей инъекции. Это только очень простые примеры. Это действительно зависит от формата запроса.

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

/etc/passwd%00 (примечание: пароли, конечно, здесь не хранятся; ключом здесь является поиск действительных имен пользователей, когда люди повторно используют пароли, или использование имен пользователей для повышения привилегий)

%00 — это «нулевой ограничитель», который используется для того, чтобы ничего не шло после него, поэтому вы не пытаетесь включить что-то несуществующее, например: /etc/passwd.txt . Это также может быть \000 , \x00 , \z , \u0000 , \0 или \00 в зависимости от используемого вами языка.

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

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

@MikeP Я должен был уточнить: /etc/passwd позволяет вам находить имена пользователей, которые затем можно использовать для входа в систему или повышения привилегий. Это небольшая часть процесса, но фундаментальная. Когда пользователи повторно используют пароли в нескольких системах, вам может просто понадобиться найти действительное имя пользователя, если у вас есть действительные пароли. LFI/RFI также можно использовать для выполнения кода, который может предоставлять учетные данные БД, учетные данные AWS и т. д.

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

@Bergi, OP не указывает "много". Однако, если у кого-то есть доступ к способу атаки MitM, он может получить «много».

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

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

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

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

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

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

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

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

В настоящее время поддерживаются следующие алгоритмы:

  • PASSWORD_DEFAULT — использовать алгоритм bcrypt (по умолчанию в PHP 5.5.0). Обратите внимание, что эта константа предназначена для изменения со временем, когда в PHP добавляются новые и более сильные алгоритмы. По этой причине длина результата использования этого идентификатора может меняться со временем. Поэтому рекомендуется хранить результат в столбце базы данных, длина которого может превышать 60 символов (хорошим выбором будет 255 символов).
  • PASSWORD_BCRYPT — используйте алгоритм CRYPT_BLOWFISH для создания хэша. Это создаст стандартный хэш, совместимый с crypt(), с использованием идентификатора «$2y$». Результатом всегда будет строка из 60 символов или false в случае ошибки.
  • PASSWORD_ARGON2I — используйте алгоритм хеширования Argon2i для создания хэша. Этот алгоритм доступен только в том случае, если PHP был скомпилирован с поддержкой Argon2.
  • PASSWORD_ARGON2ID — используйте алгоритм хэширования Argon2id для создания хэша. Этот алгоритм доступен только в том случае, если PHP был скомпилирован с поддержкой Argon2.

Поддерживаемые параметры для PASSWORD_BCRYPT:

salt ( string ) — вручную указать соль для использования при хешировании пароля. Обратите внимание, что это переопределит и предотвратит автоматическое создание соли.

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

Опция соли устарела. Теперь предпочтительнее просто использовать соль, которая генерируется по умолчанию. Начиная с PHP 8.0.0 явно указанная соль игнорируется.

cost ( int ) — обозначает стоимость алгоритма, которую следует использовать. Примеры этих значений можно найти на странице crypt().

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

Поддерживаемые параметры для PASSWORD_ARGON2I и PASSWORD_ARGON2ID:

memory_cost ( int ) — максимальная память (в кибибайтах), которую можно использовать для вычисления хэша Argon2. По умолчанию PASSWORD_ARGON2_DEFAULT_MEMORY_COST .

time_cost ( int ) — максимальное количество времени, которое может потребоваться для вычисления хэша Argon2. По умолчанию PASSWORD_ARGON2_DEFAULT_TIME_COST .

threads ( int ) — количество потоков, используемых для вычисления хэша Argon2. По умолчанию PASSWORD_ARGON2_DEFAULT_THREADS .

Доступно, только если PHP использует libargon2, но не с реализацией libsodium.

Параметры

Пароль пользователя.

Использование PASSWORD_BCRYPT в качестве алгоритма приведет к усечению параметра пароля до максимальной длины 72 байта.

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

Ассоциативный массив, содержащий параметры. Документацию по поддерживаемым параметрам для каждого алгоритма см. в константах алгоритма пароля.

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

Возвращаемые значения

Возвращает хешированный пароль.

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

Журнал изменений

< td>password_hash() больше не возвращает false при ошибке.
Версия Описание
8.0.0
8.0.0 Параметр algo теперь может принимать значение NULL.
7.4.0 Параметр algo теперь ожидает строку, но по-прежнему принимает int для обратной совместимости.
7.4. 0 Расширение натрия обеспечивает альтернативную реализацию паролей Argon2.
7.3.0 Поддержка паролей Argon2id с использованием PASSWORD_ARGON2ID была добавлено.
7.2.0 Добавлена ​​поддержка паролей Argon2i с использованием PASSWORD_ARGON2I.

Примеры

/**
* Мы просто хотим хэшировать наш пароль, используя текущий алгоритм DEFAULT.
* В настоящее время это BCRYPT, результат будет состоять из 60 символов.
*
* Имейте в виду, что DEFAULT может измениться со временем, поэтому вы должны подготовиться,
* Разрешив расширение хранилища за пределы 60 символов (255 было бы хорошо)
*/
echo password_hash ("rasmuslerdorf", PASSWORD_DEFAULT);
?>

Приведенный выше пример выведет что-то похожее на:

/**
* В этом случае мы хотим увеличить стоимость по умолчанию для BCRYPT до 12.
* Обратите внимание, что мы также переключились на BCRYPT, который всегда будет 60 символов.
*/
$options = [
'cost' => 12 ,
];
echo password_hash ("rasmuslerdorf", PASSWORD_BCRYPT, $options);
?>

Приведенный выше пример выведет что-то похожее на:

$cost = 8 ;
делать $cost ++;
$start = микровремя ( true );
password_hash ("test" , PASSWORD_BCRYPT , [ "cost" => $cost ]);
$end = microtime ( true );
> while (( $end - $start ) < $timeTarget );

echo "Найдена подходящая стоимость: " . $стоимость;
?>

Приведенный выше пример выведет что-то похожее на:

Приведенный выше пример выведет что-то похожее на:

Примечания

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

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

Примечание:

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

  • Любой новый алгоритм должен находиться в ядре как минимум 1 полной версии PHP, прежде чем он станет стандартным. Поэтому, если, например, новый алгоритм будет добавлен в 7.5.5, он не будет иметь права на использование по умолчанию до 7.7 (поскольку 7.6 будет первым полным выпуском). Но если в версии 7.6.0 будет добавлен другой алгоритм, он также будет иметь право на использование по умолчанию в версии 7.7.0.
  • Значение по умолчанию должно меняться только в полной версии (7.3.0, 8.0.0 и т. д.), но не в исправлении. Единственным исключением из этого правила является экстренная ситуация, когда в текущем заданном по умолчанию обнаружена серьезная уязвимость в системе безопасности.

См. также

  • password_verify() — проверяет, соответствует ли пароль хешу.
  • crypt() — одностороннее хеширование строк
  • sodium_crypto_pwhash_str() — получить хэш в кодировке ASCII

Примечания, внесенные пользователями 12 примечаний

С 2017 года NIST рекомендует использовать секретный ввод при хешировании запомненных секретов, таких как пароли. Подмешивая секретный ввод (обычно называемый «перцем»), злоумышленник не может полностью подобрать хэши паролей, даже если у них есть хэш и соль. Например, SQL-инъекция обычно влияет только на базу данных, а не на файлы на диске, поэтому перец, хранящийся в файле конфигурации, все равно будет недоступен для злоумышленника.Перец должен быть сгенерирован случайным образом один раз и может быть одинаковым для всех пользователей. Многие утечки паролей могли бы стать совершенно бесполезными, если бы этим занимались владельцы сайтов.

// register.php
$pepper = getConfigVariable ("перец");
$pwd = $_POST ['пароль'];
$pwd_peppered = hash_hmac("sha256", $pwd, $pepper);
$pwd_hashed = пароль_хэш ( $pwd_peppered , PASSWORD_ARGON2ID );
add_user_to_database ( $username , $pwd_hashed );
?>

// login.php
$pepper = getConfigVariable ("перец");
$pwd = $_POST ['пароль'];
$pwd_peppered = hash_hmac("sha256", $pwd, $pepper);
$pwd_hashed = get_pwd_from_db ( $username );
if ( password_verify ( $pwd_peppered , $pwd_hashed )) echo "Пароль совпадает." ;
>
else echo "Неверный пароль." ;
>
?>

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

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

Почему это работает? Потому что после кражи базы данных злоумышленник делает следующее:

password_verify("a", $stolen_hash)
password_verify("b", $stolen_hash)
.
password_verify("z", $stolen_hash)
password_verify("aa", $stolen_hash)
и т. д.

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

Что, если бы вы использовали этот перец? Теперь им нужно сделать следующее:

password_verify(hmac_sha256("a", $secret), $stolen_hash)

Без этого $secret (перца) они не смогут выполнить это вычисление. Они должны были бы сделать:

проверка_пароля(hmac_sha256("a", "a"), $stolen_hash)
проверка_пароля(hmac_sha256("a", "b"), $stolen_hash)
.
и т. д., пока они не найдут правильный перец.

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

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

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

Конфигурация

Драйвер хеширования по умолчанию для вашего приложения настраивается в файле конфигурации config/hashing.php вашего приложения. В настоящее время поддерживается несколько драйверов: Bcrypt и Argon2 (варианты Argon2i и Argon2id).

Основное использование

Хеширование паролей

Вы можете хешировать пароль, вызвав метод make на фасаде Hash:

Корректировка рабочего фактора Bcrypt

Если вы используете алгоритм Bcrypt, метод make позволяет вам управлять коэффициентом работы алгоритма с помощью параметра раундов; однако рабочий фактор по умолчанию, управляемый Laravel, приемлем для большинства приложений:

Регулировка рабочего коэффициента Argon2

Если вы используете алгоритм Argon2, метод make позволяет вам управлять рабочим фактором алгоритма с помощью параметров памяти, времени и потоков; однако значения по умолчанию, которыми управляет Laravel, приемлемы для большинства приложений:

Проверка соответствия пароля хешу

Метод проверки, предоставляемый фасадом Hash, позволяет проверить, соответствует ли заданная текстовая строка заданному хэшу:

Определение необходимости повторного хеширования пароля

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

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

Взлом паролей Инструменты

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

Оглавление

Что такое хэши паролей?

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

<Р> хэш ( «Привет») = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
хэш ( «hbllo») = 58756879c05c68dfac9866712fad6a93f8146f337a69afe7dd238f3364946366
хэш ( «вальс») = c0e81794384491161f1777c232bc6bd9ec38f616560b120fda8e90f383853542

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

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

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

  1. Пользователь создает учетную запись на веб-сайте или в сети.
<р>2. Их пароль хешируется и хранится в базе данных.

<р>3. Когда пользователь пытается войти в систему, хэш введенного им пароля сравнивается с хэшем его фактического сохраненного пароля (хэш извлекается из базы данных).

<р>4. Если хэши совпадают, пользователю предоставляется доступ. В противном случае отображаются предупреждения о неверных учетных данных.

<р>5. Шаги 3 и 4 повторяются каждый раз, когда кто-то пытается войти в аккаунт.

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

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ. Это образовательная статья, предназначенная для информирования читателей о взломах. Не используйте этот инструмент или веб-сайт на любом веб-сайте. Не применяйте и не выполняйте какие-либо методы или инструменты без участия стороны.

1) Получение хэшей паролей Linux

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

Чтобы получить доступ к скрытым хэшам, введите следующую команду:

снять тень /etc/passwd /etc/shadow > crack.txt

unshadow — это команда Linux, которая извлекает хэши паролей. Как видите, приведенная выше команда отправляет хэши в файл crack.txt.

Как вы можете видеть ниже, файл crack.txt содержит хэши пароля.

Как извлечь хэши паролей с помощью ОС Windows и Linux

2) Извлечение дампов паролей из Windows

Pwdump – это замечательный инструмент для взлома, который поможет вам получить хэши секретных паролей LM и NTLM учетных записей клиентов из базы данных Security Account Manager (SAM).

Загрузите и распакуйте pwdump на компьютере с Windows, который вы хотите взломать. В этом руководстве используйте pwdump7.

извлечь хэши паролей

Теперь с помощью этого инструмента мы можем получить хэши паролей Windows из базы данных SAM.

Откройте терминал и введите следующую команду в каталоге pwdump7

pwdump7 > hash.txt

хэш пароля

Как вы можете видеть ниже, хэши извлекаются и сохраняются в файле с именем hash.txt

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

Часто задаваемые вопросы о получении хэшей

В.1. Есть ли на веб-сайтах похожие хэши паролей?

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

В.2. Можем ли мы получить хэши паролей Facebook и Instagram?

Нет. Вы не можете взломать пароли Facebook и Instagram

В.3. Есть ли в WhatsApp хэш?

Нет, он использует зашифрованную систему ключей. Я уже делал статью о том, как взломать WhatsApp этим методом, вы можете ее прочитать.

В.4. Можно ли взломать любой хэш пароля?

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

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

Читайте также: