Как создать надежный пароль, а также об использовании хеш функции — NTA на vc.ru

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

1931 просмотров

Для начала разберемся с базовыми понятиями.

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

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

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

Рассмотрим таблицу с количеством возможных вариантов паролей при разных условиях

Чтобы понять, как это работает. Давайте решим задачу.

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

Считаем: сколько может угадать паролей злоумышленник за 90 дней.

90 (дни) * 24 (часы) * 60 (минуты) * 60 (секунды) * 1000 (кол-во паролей в секунду) = 7 776 000 000 до истечения срока действия пароля. Из нашей таблицы видно, если использовать все возможные условия, то пароля из 6 символов будет достаточно, до того момента как злоумышленник взломает пароль.

Так каким же должен быть пароль? (Немного о создании)

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

Что такое хешированные пароли? Рассмотрим подробнее.

Сами хешированные пароли не являются уникальными, когда задается одно и то же входное значение, всегда получится одинаковое выходное значение. Если Рома и Наташа выберут NewTechAudit2020 в качестве пароля, то и их хеш будет одинаковым:

Задача на подумать, сложные ли у ребят пароли?

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

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

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

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

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

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

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

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

Допустим, у нас есть пароль NewTechAudit2020 и соль l0veaaaud1t. Мы можем использовать соль одним из следующих образов: добавлением соли справа — NewTechAudit2020l0veaaaud1t или добавлением соли слева — l0veaaaud1tNewTechAudit2020. Как только соль будет добавлена, мы сможем затем захешировать ее. Давайте посмотрим на это на примере с использованием следующего кода Python:

import hashlib salt = “l0veaaaud1t” password = “NewTechAudit2020” salt_password = salt + password password_salt = password +salt hash_1 = hashlib.sha256(salt_password.encode()).hexdigest() hash_2 = hashlib.sha256(password_salt.encode()).hexdigest()

Мы получили:

hash_1: e2d71ae71fcbaa8b5c525b5e9449a13a6d0d33dcdf80461be63c3d7cb7f87ff7 hash_2: ef344582eb7e3224141ea661c9d063b5dd199e49f4805ef451782a90dd271c1f

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

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

Наташа и Рома используют один и тот же пароль NewTechAudit2020. Для Наташи мы будем использовать соль h2m3gaw0rld, а для Ромы мы будем использовать d0kak1nggg в качестве соли.

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

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

Итак, каким же идеальный пароль должен быть?

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

  • Используйте минимальную длину пароля 10 или более символов;
  • Используйте нижний и верхний регистр, числа и символы;
  • Используйте случайные пароли;
  • Не используйте один и тот же пароль для разных аккаунтов;
  • Не используйте информацию, которая доступна в публичном доступе;
  • Не используйте пароли, состоящие полностью из простой комбинации.

Соли @ хешируй · GitHub

Этот урок переехал по адресу: https://github.com/codedokode/pasta/blob/master/security/password-hashing.md

Здесь старая версия урока, которая больше не обновляется.

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

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

Почитать про md5: http://ru.wikipedia.org/wiki/Md5

Какой смысл в хэше, если md5 все равно можно расшифровать? Пусть даже перебором?

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

Ок, достаточно ли использовать хеширование и хранить только хеши?

Нет! Без так называемой «соли» многие пароли можно подобрать за секунду если там использовать просто md5(pass). Не веришь? Читай ниже.

Что такое соль? Что значит «соленый хеш»?

Соль — случайно сгенерированная последовательность символов, которая хранится рядом с хешем. Дан пароль $pass = "123456", мы генерируем случайную соль например $salt = 'A&%6t*(k:' и получаем хеш от «соль + пароль»: $hash = md5($salt . $pass). В базу сохраняется отдельно использованная соль (она для каждого пользователя своя), отдельно хеш.

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

Способ 1

Перебираем все возможные пароли, начиная например с 1111111 и заканчивая zzzzzzz и вычисляем от каждого md5-хеш. 9 секунд на одной карте (11500 дней) или 115 дней на сотне карточек.

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

В общем, видишь, без добавления соли пароли подберутся на раз. И не все же ставят 10-символьные пароли, у многих там просто слово или цифры.

Способ 2

Есть еще другой вариант — скачать огромные радужные таблицы (читай в вики про них) где хранятся уже рассчитанные цепочки хешей (для простых паролей). И конечно все хеши от обычных паролей длиной до 10 символов там уже есть (больше нету, так как они начинают занимать гигабайты. Но это вопрос времени, когда жесткие диски станут больше). Если ты хранишь в базе md5(pass) она вскроется мигом. Таблицы можно скачать тут: https://www.freerainbowtables.com/en/tables2/ (если не открывается, выбери английский язык и открой ссылку еще раз). juYUHkd%$fdtd123456). Опять же, соль должна быть подлиннее и содержать спецсимволы чтобы было больше комбинаций для перебора. Ну конечно, простые пароли типа 123456 все равно вскроют, так как их при переборе проверяют в первую очередь. А вот сложные придется подбирать долго.

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

    • С правильным подходом даже простой md5 замучаешься расшифровывать.

    Еще

    Вычисление хеша md5 очень быстро делается на современном железе. Чтобы усложнить перебор, можно использовать более тяжелые для вычисления хеши, например http://ru.wikipedia.org/wiki/Bcrypt и http://ru.wikipedia.org/wiki/Scrypt где можно задавать сложность вычисления хеша (а в scrypt — еще и необходимый объем памяти).

    В php 5.5 сделали стандартные функции хеширования паролей password_*: http://habrahabr. ru/post/194972/

    Лучший способ хранения паролей

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

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

    Хотите посмотреть видеоверсию этой статьи?

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

    Хешированные пароли не уникальны сами по себе из-за детерминированной природы хэш-функции: при одних и тех же входных данных всегда получается один и тот же вывод. If Alice and Bob both choose dontpwnme4 as a password, their hash would be the same:

    username hash
    alice 4420d1918bbcf7686defdf9560bb5087d20076de5f77b7cb4c3b40bf46ec428b
    jason 695ddccd984217fe8d79858dc485b67d66489145afa78e8b27c1451b27cc7a2b
    mario cd5cb49b8b62fb8dca38ff2503798eae71bfb87b0ce3210cf0acac43a3f2883c
    teresa 73fb51a0c9be7d988355706b18374e775b18707a8a03f7a61198eefc64b409e8
    bob 4420d1918bbcf7686defdf9560bb5087d20076de5f77b7cb4c3b40bf46ec428b
    mike 77b177de23f81d37b5b4495046b227befa4546db63cfe6fe541fc4c3cd216eb9

    Как мы видим, Алиса и Боб имеют тот же пароль, что и мы видим, что оба имеют одинаковый хэш: 4420D1918BBCF7686DEFDF9560BB5087D20076DE5F7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7B7BA7

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

    Можете ли вы найти пароль jason на основе хеша 695ddccd984217fe8d79858dc485b67d66489145afa78e8b27c1451b27cc7a2b ?

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

    Атака на несоленые пароли

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

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

    К счастью, несмотря на выбор одного и того же пароля, alice и bob выбрали пароль, который нелегко найти в словаре: dontpwnme4 . Наш друг mike , с другой стороны, выбрал Friendship в качестве своего пароля, который является прямой записью в словаре английского языка. mike подвержен высокому риску взлома в результате атаки по словарю; риск для alice и bob ничем не отличается. Придумать пароль например dontpwnme4 , злоумышленник может использовать специальные словари, такие как leetspeak, для взлома пароля.

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

    Словарь -> использовать списки из словаря Брутфорс -> использование случайных символов

    Какого рода профилирование пароля они пытаются сделать.

    Взлом несоленых хэшей с помощью таблиц

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

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

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

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

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

    Сила хеш-таблиц зависит от объема, а не от скорости вычислений, а объем огромен! Каждое нарушение данных увеличивает этот объем. Список взломанных компаний можно найти на сайте haveibeenpwned.com.

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

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

    Смягчение атак на пароли с помощью соли

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

    Допустим, у нас есть пароль farm1990M0O и соль f1nd1ngn3m0 . Мы можем солить этот пароль, добавляя или добавляя к нему соль. Например: farm1990M0Of1nd1ngn3m0 или f1nd1ngn3m0farm1990M0O являются действительными паролями с солью. Как только соль добавлена, мы можем ее хешировать. Давайте посмотрим на это в действии:

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

    Пароль: farm1990M0O

    Соль: f1nd1ngn3m0

    Salted input: f1nd1ngn3m0farm1990M0O

    Hash (SHA-256): 7528ed35c6ebf7e4661a02fd98ab88d92ccf4e48a4b27338fcc194b90ae8855c

    Appending the Salt

    Password: farm1990M0O

    Salt: f1nd1ngn3m0

    Salted input: farm1990M0Of1nd1ngn3m0

    Hash (SHA-256): 07dbb6e6832da0841dd79701200e4b179f1a94a7b3dd26f612817f3c03117434

    Хэши были рассчитаны с использованием следующего кода Python:

     импортировать хеш-библиотеку
строка = "соленый пароль"
hashlib. sha256(string.encode()).hexdigest()

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

    Алиса и Боб решают использовать один и тот же пароль, farm1990M0O . Для Алисы мы снова будем использовать f1nd1ngn3m0 в качестве соли. However, for Bob, we'll use f1nd1ngd0ry as the salt:

    Hashing and Salting Alice's Password

    User: Alice

    Password: farm1990M0O

    Salt: f1nd1ngn3m0

    Salted input: farm1990M0Of1nd1ngn3m0

    Хэш (SHA-256): 07dbb6e6832da0841dd79701200e4b179f1a94a7b3dd26f612817f3c03117434

    Hashing and Salting Bob's Password

    User: Bob

    Password: farm1990M0O

    Salt: f1nd1ngd0ry

    Salted input: farm1990M0Of1nd1ngd0ry

    Hash (SHA-256): 11c150eb6c1b776f390be60a0a5933a2a2f8c0a0ce766ed92fea5bfd9313c8f6

    Разные пользователи, один и тот же пароль. Разные соли, разные хэши. Если бы кто-нибудь взглянул на полный список хэшей паролей, никто бы не сказал, что Алиса и Боб используют один и тот же пароль. Каждая 9Уникальная соль 0003 расширяет пароль farm1990M0O и преобразует его в уникальный пароль . Кроме того, когда пользователь меняет свой пароль, служба также должна генерировать новую соль.

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

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

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

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

    Твитнуть это

    Создание хорошей случайной соли

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

    В соответствии с рекомендациями OWASP для правильной реализации солей для учетных данных мы должны:

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

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

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

    OWASP предлагает SecureRandom в качестве примера криптографически стойких случайных данных.

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

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

    "Хэш-соли - это лежачие полицейские на пути злоумышленника к взлому ваших данных. Неважно, видны ли они и незашифрованы, важно то, что они на месте."

    Tweet This

    Согласно этим рекомендациям, f1nd1ngn3m0 не генерируется из непредсказуемого источника. На самом деле соль — это 1337 способ написания findnemo , популярного анимационного фильма, который может быть частью стратегии перебора словаря. f1nd1ngn3m0 не соответствует рекомендациям по длине, чтобы быть солью: его длина составляет всего 11 байт.

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

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

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

    Tweet This

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

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

    Упрощение управления паролями с помощью Auth0

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

    Auth0 помогает предотвратить попадание важных идентификационных данных в чужие руки. Мы никогда не храним пароли в открытом виде. Пароли всегда хешируются и солятся с помощью bcrypt. Кроме того, данные в состоянии покоя и в движении всегда шифруются с помощью TLS с не менее чем 128-битным шифрованием AES. Мы встроили в наш продукт самые современные средства безопасности, чтобы защитить ваш бизнес и ваших пользователей.

    Сделайте Интернет безопаснее, зарегистрируйте бесплатную учетную запись Auth0 сегодня.

    Что такое соленые пароли и хеширование паролей?

    При создании приложений, ориентированных на клиентов, безопасность часто не имеет значения. Но в условиях постоянных утечек данных крупных корпораций, таких как T-Mobile и Google, компании должны проявлять бдительность, чтобы придерживаться передовых методов обеспечения безопасности.

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

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

    Криптография и шифрование

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

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

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

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

    Если бы вся информация была открытым текстом и не содержала шифрования или криптографии, конфиденциальные материалы, такие как информация о паролях, медицинские записи (PII) и даже информация о банковских счетах (PIFI), могли быть украдены и проданы тому, кто больше заплатит. Один из первых шагов базовой гигиены безопасности — не хранить конфиденциальные данные в открытом виде, особенно пароли. Здесь на помощь приходит хеширование паролей.

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

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

    Ниже приведен пример нескольких слов, прошедших процесс хеширования.

     

    Что такое солевой пароль?

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

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

    Соление — это добавление ряда случайных символов к паролю перед прохождением функции хеширования. Как это работает? Давайте посмотрим:

     

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

    Где хранить соленые пароли?

    С точки зрения того, как это работает в ИТ-инфраструктуре, соли должны храниться в базе данных вместе с паролем пользователя, как показано ниже. Рекомендуется, чтобы соли были случайными и уникальными для каждого входа в систему, чтобы смягчить атаки с использованием радужных таблиц предварительно вычисленных хэшей. Хотя злоумышленник по-прежнему может повторно вычислять хэши общих списков паролей, используя заданную соль для пароля, способ обеспечить дополнительную глубокую защиту — это зашифровать хранилище паролей в состоянии покоя, предпочтительно поддерживаемое HSM или облачной службой управления ключами, такой как AWS KMS. .

    Начало пути

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

    Как Okta может помочь

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

    No related posts.