Что такое соль при хэшировании

Обновлено: 03.07.2024

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

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

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

Хешированные пароли не уникальны сами по себе из-за детерминированного характера хеш-функции: при одних и тех же входных данных всегда получается один и тот же результат. Если Алиса и Боб выберут в качестве пароля dontpwnme4, их хэш будет одинаковым:

имя пользователя	хэш
алиса	4420d1918bbcf7686defdf9560bb5087d20076de5f77b7cb4c3b40bf46ec428b
джейсон	695ddccd984217fe8d79858dc485b67d66489145afa78e8b27c1451b27cc7a2b
Марио	cd5cb49b8b62fb8dca38ff2503798eae71bfb87b0ce3210cf0acac43a3f2883c
Teresa	73fb51a0c9be7d988355706b18374e775b18707a8a03f7a61198eefc64b409e8
боб	4420d1918bbcf7686defdf9560bb5087d20076de5f77b7cb4c3b40bf46ec428b
майк	77b177de23f81d37b5b4495046b227befa4546db63cfe6fe541fc4c3cd216eb9

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

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

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

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

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

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

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

К счастью, несмотря на то, что Алиса и Боб выбрали один и тот же пароль, они выбрали пароль, который нелегко найти в словаре: dontpwnme4 . Наш друг Майк, с другой стороны, выбрал дружбу в качестве своего пароля, который является прямой записью в словаре английского языка. Майк подвергается высокому риску взлома в результате атаки по словарю; риск для Алисы и Боба ничем не отличается. Чтобы придумать пароль, такой как dontpwnme4 , злоумышленник может использовать специальные словари, такие как leetspeak, для взлома пароля.

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

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

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

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

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

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

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

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

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

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

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

Предотвращение атак на пароль с помощью соли

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

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

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

Соленый ввод: f1nd1ngn3m0farm1990M0O

Хэш (SHA-256): 7528 ed35c6ebf7e4661a02fd98ab88d92ccf4e48a4b27338fcc194b90ae8855c

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

Соленый ввод: farm1990M0Of1nd1ngn3m0

Хэш (SHA-256): 07 dbb6e6832da0841dd79701200e4b179f1a94a7b3dd26f612817f3c03117434

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

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

Алиса и Боб решают использовать один и тот же пароль, farm1990M0O . Для Алисы мы снова будем использовать f1nd1ngn3m0 в качестве соли. Однако для Боба мы будем использовать f1nd1ngd0ry в качестве соли:

Хеширование и добавление соли к паролю Алисы

Соленый ввод: farm1990M0Of1nd1ngn3m0

Хэш (SHA-256): 07 dbb6e6832da0841dd79701200e4b179f1a94a7b3dd26f612817f3c03117434

Хеширование и добавление соли к паролю Боба

Соленый ввод: farm1990M0Of1nd1ngd0ry

Хэш (SHA-256): 11 c150eb6c1b776f390be60a0a5933a2a2f8c0a0ce766ed92fea5bfd9313c8f6

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

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

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

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

Отправить твит

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

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

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

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

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

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

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

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

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

Отправить твит

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

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

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

Отправить твит

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

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

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

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

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

Дэн Ариас

Инженер по исследованиям и разработкам

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

Большая часть моей инженерной работы связана с AWS, React и Node, но мои исследования и разработка контента связаны с широким кругом тем, таких как Golang, производительность и криптография. Кроме того, я являюсь одним из основных сопровождающих этого блога. Ведение блога с более чем 600 000 уникальных посетителей в месяц – довольно сложная задача!

Я был клиентом Auth0 до того, как стал сотрудником, и мне всегда нравилось, насколько проще реализовать аутентификацию с помощью Auth0. Хотите попробовать? Зарегистрируйте бесплатный аккаунт ⚡️.

Дэн Ариас

Инженер по исследованиям и разработкам

От Yahoo, MySpace и TalkTalk до Ashley Madison и Adult Friend Finder хакеры со всего мира украли личную информацию.

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

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

Терминология

Обычный текст

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

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

Хеширование

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

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

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

Соление

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

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

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

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

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

Приправление

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

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

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

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

Шифрование

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

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

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

Шестнадцатеричный

Шестнадцатеричное число, также известное как «шестнадцатеричное» или «основание 16», представляет собой способ представления значений от нуля до 15 с помощью 16 отдельных символов. Числа от 0 до 9 представляют значения от нуля до девяти, а a, b, c, d, e и f — от 10 до 15.

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

Алгоритмы

MD5

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

ША-1

Secure Hash Algorithm 1 (SHA-1) — это криптографический алгоритм хэширования, разработанный Агентством национальной безопасности США в 1993 году и опубликованный в 1995 году.

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

ША-2

Алгоритм безопасного хэширования 2 (SHA-2), преемник SHA-1, представляет собой семейство хэш-функций, которые производят более длинные хэш-значения с 224, 256, 384 или 512 битами, записанными как SHA-224, SHA-256, SHA-384 или SHA-512.

Впервые он был опубликован в 2001 году, снова разработан АНБ, и эффективная атака против него еще не продемонстрирована. Это означает, что SHA-2 обычно рекомендуется для безопасного хеширования.

SHA-3, хотя и не является заменой SHA-2, был разработан не АНБ, а Гвидо Бертони, Джоан Демен, Микаэлем Петерсом и Жилем Ван Аше из STMicroelectronics и Университета Радбауд в Неймегене, Нидерланды. Он был стандартизирован в 2015 году.

Bcrypt

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

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

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

PBKDF2

Функция формирования ключа на основе пароля 2 (PBKDF2), разработанная RSA Laboratories, представляет собой еще один алгоритм расширения ключа, который затрудняет подбор хэшей методом грубой силы. Считается, что использовать грубую силу с определенным значением несколько проще, чем Bcrypt, поскольку для запуска алгоритма требуется меньше компьютерной памяти.

Скрипт

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

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

А как же пароли?

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

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

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

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

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

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

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

Что такое CSPRNG?

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

В чем разница между хэшированием и солением?

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

Что означает хеширование пароля?

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

Что такое одноразовый номер в криптографии?

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

В чем разница между фиксированной SALT и повторно используемой SALT?

Фиксированная соль — это когда программист использует одну и ту же соль для каждого хешированного пароля. Таким образом, фиксированная соль — это соль, которая используется повторно.

Отчет о беспарольном доступе за 2021 год

Бумага

Отчет о беспарольной матрице Aite Group за 2021 год

Краткий обзор нашего решения

Бумага

Обзор решения Secret Double Octopus

Secret Double Octopus's Passwordless Enterprise™ — идеальное решение для всех потребностей аутентификации в домене. Узнайте, как работает наш революционный подход к аутентификации сотрудников и что он может сделать для вашей организации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Начало пути

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

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

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

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

Джейсон Юнг (Jason Jung) — член команды по маркетингу продуктов компании Okta. Сосредоточив внимание на управлении идентификацией и доступом клиентов (CIAM), он увлечен стратегией, контентом и обеспечением продаж. Джейсон окончил Школу бизнеса Маккомбса в UT Austin, где изучал маркетинг и финансы.

Шифрование и хэширование выполняют разные функции, несмотря на их сходство

Быстро, вы знаете разницу между шифрованием и хешированием? Вы знаете, что такое соление? Вы думаете, что солить гашиш — это просто часть ирландского завтрака?

Шутки в сторону, если вы обращаете внимание на мир кибербезопасности, вы, вероятно, услышите эти термины. Часто без каких-либо объяснений.

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

Давайте обсудим это.

Что такое шифрование?

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

Это ключевое различие между шифрованием и хэшированием (простите меня за каламбур).

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

Шифрование имеет долгую и богатую историю. Он датируется как минимум 1900 годом до нашей эры после обнаружения стены гробницы с высеченными на ней нестандартными иероглифами. С тех пор было бесчисленное количество исторических примеров.

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

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

Как работает шифрование?

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

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

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

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

Исторические алгоритмы шифрования

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

Шифры сдвига. Как и в примере, который мы обсуждали выше, две стороны определяют число от 1 до 25 и сдвигают буквы на это количество пробелов в алфавите. Номер смены служит ключом.

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

Шифры перестановки. В этом алгоритме используется набор правил, которые служат ключом для изменения порядка текста в различные перестановки, которые затем можно зашифровать. Распространенными примерами являются шифры Rail Fence и Route.

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

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

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

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

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

Современное шифрование

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

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

Асимметричное шифрование. Это только что приведенный нами пример открытого ключа. Один ключ шифрует, другой ключ расшифровывает. Шифрование идет только в одну сторону. Эта концепция лежит в основе PKI (инфраструктуры открытых ключей), которая представляет собой модель доверия, лежащую в основе SSL/TLS.
Симметричное шифрование. Оно ближе к форме шифрования с закрытым ключом. У каждой стороны есть свой ключ, который может как шифровать, так и расшифровывать. Как мы обсуждали в приведенном выше примере, после асимметричного шифрования, которое происходит при рукопожатии SSL, браузер и сервер взаимодействуют с использованием передаваемого симметричного ключа сеанса.

Асимметричное шифрование, как правило, более надежное из-за его одностороннего характера.

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

Шифрование во всем, Патрик Ноэ

Современные алгоритмы шифрования

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

AES. AES расшифровывается как Advanced Encryption Standard, первоначально называвшийся Rijndael. Это спецификация шифрования, опубликованная Национальным институтом стандартов и технологий (NIST) еще в 2001 году. Она подвергает открытый текст ряду "раундов преобразования", определяемых размер ключа, каждый раунд состоит из нескольких шагов обработки. Давайте не будем заходить слишком далеко в сорняки на этом. AES — это общий алгоритм с SSL/TLS. Он заменил стандарт шифрования данных (DES), созданный в 1977 году.

RSA — RSA расшифровывается как Rivest-Shamir-Adlemen по имени его создателей. Это алгоритм шифрования с открытым ключом (асимметричный), который существует с 1978 года и широко используется по сей день. Он использует факторизацию простых чисел для шифрования открытого текста.

[Забавный факт: Клиффорд Кокс, математик, нанятый британской разведывательной службой GCHQ, изобрел аналогичную систему пятью годами ранее, в 1973 году, но она не была рассекречена до 1997 года.]

ECC — ECC означает криптографию на основе эллиптических кривых, основанную на алгебраической структуре эллиптических кривых над конечными полями. Хотя ECC существует с 1985 года, он используется только примерно с 2004 года. ECC имеет явные преимущества перед RSA и, вероятно, будет играть более заметную роль в будущем SSL/TLS.

PGP — PGP означает Pretty Good Privacy. Он был создан в 1991 году Филом Циммерманом. На самом деле это скорее набор алгоритмов, чем один, все для хеширования, сжатия данных и криптографии как с открытым, так и с закрытым ключом. На каждом шаге используется свой алгоритм. PGP критиковали за плохое удобство использования, отсутствие повсеместного распространения и длину ключей.

Когда следует использовать шифрование?

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

Ключ в том, что шифрование обратимо. Хеширование — нет.

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

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

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

Вот как это работает: каждый алгоритм хеширования выдает фиксированную длину. Так, например, вы можете слышать о SHA-256, что означает, что алгоритм будет выводить хеш-значение, состоящее из 256 бит, обычно представленное 64-символьной шестнадцатеричной строкой (h/t Мэтью Хаслетт).

Каждое хеш-значение уникально. Если два разных файла производят одно и то же уникальное хеш-значение, это называется коллизией и делает алгоритм практически бесполезным. В прошлом году Google создал коллизию с алгоритмом хэширования SHA-1, чтобы продемонстрировать его уязвимость. SHA-1 был официально заменен SHA-2 в начале 2016 года. Но у Google была цель, поэтому она выделила два года средств, человеко-часов и талантов в партнерстве с лабораторией в Амстердаме, чтобы создать что-то, что был к тому моменту скорее абстракцией в реальность. Это долгий путь, чтобы доказать свою точку зрения. Но Google пошел туда.

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

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

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

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

Распространенные алгоритмы хеширования

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

MD5. MD5 – это еще один алгоритм хеширования, созданный Рэем Ривестом, который, как известно, подвержен уязвимостям. Он был создан в 1992 году как преемник MD4. В настоящее время MD6 находится в разработке, но с 2009 года Rivest исключил его из рассмотрения NIST для SHA-3.

SHA — SHA – это безопасный алгоритм хеширования. Вероятно, он наиболее известен как алгоритм хеширования, используемый в большинстве наборов шифров SSL/TLS. Набор шифров — это набор шифров и алгоритмов, которые используются для соединений SSL/TLS. SHA обрабатывает аспекты хеширования. SHA-1, как мы упоминали ранее, теперь устарел. SHA-2 теперь является обязательным. Иногда известно, что SHA-2 имеет SHA-256, хотя также доступны варианты с большей длиной бита.

RIPEMD – семейство криптографических алгоритмов хеширования длиной 128, 160, 256 и 320 бит. Он был разработан в рамках европейского проекта Ripe Хансом Доббертином и группой ученых в 1996 году. Его 256- и 320-битные варианты на самом деле не добавляют никакой дополнительной безопасности, они просто уменьшают вероятность коллизии. В 2004 году сообщалось о коллизии для RIPEMD-128, а это означает, что RIPEMD-160 – единственный достойный алгоритм из этого семейства (примерно в двух абзацах это будет потрясающий каламбур).

TIGER – довольно новый алгоритм, который начинает набирать популярность в сетях обмена файлами и торрент-сайтах. В настоящее время нет известных атак, эффективных против его полного 24-раундового варианта.

Что такое соление?

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

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

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

Давайте рассмотрим небольшой пример.

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

Ваша соль — это просто слово СОЛЬ

Перед хэшированием вы добавляете SALT в конец данных. Итак, это будет выглядеть так:

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

Теперь, если взломщик знает вашу соль, она практически бесполезна. Они могут просто добавить его в конец каждого варианта пароля, который они пытаются найти, и в конечном итоге найти его. Вот почему соль для каждого пароля должна быть разной — для защиты от атак с радужными таблицами [h/t предложение Джона в комментариях].

Мы могли бы написать целую статью о безопасности паролей (которые у нас уже есть) и о том, по-прежнему ли это полезная защита, но пока это должно быть приемлемое определение соления.

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

Что мы выяснили (для скиммеров)

Вот что мы рассмотрели в сегодняшнем обсуждении:

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

44 комментария

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

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