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

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

Хеширование

Многие разработчики приложений и систем взяли ваш пароль, который вы ввели, и отправили его через математическую функцию, которая превращает ваш пароль в закодированный вывод. Идея состоит в том, что, несмотря на то, что ваш пароль легко превратить в этот новый вывод, теоретически невозможно изменить вывод на исходный пароль. Обычно известные типы хэшей включают, но не ограничиваются ими, MD5 и SHA-1. Как работают эти функции, выходит за рамки данной статьи. Просто знайте, что любой введенный пароль, например «foobar», отправляется через что-то вроде MD5, а затем он выплевывает что-то вроде этого: «3858f62230ac3c915f300c664312c63f» это результат того, что вы использовали пароль «foobar» и функцию одностороннего хеширования MD5. .

Соленые верительные грамоты

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

Примеры без засолки:

foobar = 3858f62230ac3c915f300c664312c63f
пароль = 5f4dcc3b5aa765d61d8327deb882cf99
thesearebadpasswords = 96b803bad93743620ed3b18912a148f1

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

Статические соленые примеры:

foobar123 = ae2d699aca20886f6bed96a0425c6168
password123 = 482c811da5d5b4bc6d497ffa98491e38
thesearebadpasswords123 = 549e1e8f4fc229265e24f8f9da679d22

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

Динамически солидные учетные данные

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

Например, если типичная пользовательская таблица выглядит примерно так:

Имя пользователя, имя, фамилия, дата создания, хеш пароля, активный пользователь? (Да / Нет)
VictimUser, Бонни, Клайд, 01.01.1970, 3858f62230ac3c915f300c664312c63f, Y

Не могли бы вы использовать аспекты из разных областей, чтобы сделать это своей солью? Поскольку каждый пользователь обычно «уникален», то все, что вы используете в качестве дополнительных входных данных, является новым значением соли. Очевидно, вы захотите сделать это достаточно сложным, чтобы злоумышленники не могли просто «угадать» вашу функцию засолки. Поэтому, если вы создаете функцию соления, которая говорит, что используйте строку: «Имя пользователя» + «Дата создания учетной записи» + «Длина исходного введенного пароля (foobar = 6)», тогда соль действительно превращается в что-то вроде этого: VictimUser01 / 01/19706

Теперь давайте объединим соль с нашим исходным паролем: foobar, и мы перейдем к нашим новым учетным данным с солью:

foobarVictimUser01 / 01/19706 = ac3b9718b592734058659efd3f46ec2a

Это, очевидно, изменилось бы, если бы даже у нас было все то же самое, и единственное, что отличалось, это то, что у нас был второй пользователь с именем VictimUser2. Все остальные элементы равны, поэтому мы получаем новые уникальные учетные данные с солью:

foobarVictimUser201 / 01/19706 = 63a3de523e031237c9e959fb246b90a2

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

Пользователи / учащиеся: Если вы хотите увидеть пример кода, демонстрирующий, как все это демонстрируется на практике, посетите https://github.com/dc401/Dynamic-Salting-Example, загрузите и запустите DynamicSalting.exe.

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

Узнайте о других способах усиления ваших операций по киберзащите на сайте: www.scissecurity.com