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

Соль (криптография)

Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена.
Вы можете отредактировать эту статью, добавив ссылки на авторитетные источники.
Эта отметка установлена 11 июня 2012.

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

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

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

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

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

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

Вот пример создания хеша с солью на PHP:

$password = 'password'; //Сам пароль $hash1 = md5($password); //Хешируем первоначальный пароль $salt = 'sflprt49fhi2'; //Генерируем случайный набор символов (соль) $hash2 = md5($hash1 . $salt); //Складываем старый хеш с солью и пропускаем через функцию md5() 

В данном примере соль является детерминированной строкой, в реальных проектах следует применять только случайные соли, сгенерированные каким-либо ГПСЧ.

Пример использования функции crypt на языке PHP:

// Создание хеша $hash = crypt('password'); // crypt сама генерирует соль и хеширует используя дефолтный алгоритм // Если есть необходимость использовать определенный алгоритм, то нужно подготовить соль в формате crypt, а именно // $$$ или $$$$ если алгоритм требует дополнительные параметры // Например: $1$xdtfsfre$ - MD5 алгоритм // Проверка хеша if (crypt($_REQUEST['password'], $hash) == $hash)  // crypt извлекает соль из хеша и хеширует входящий пароль с ее использованием // Пароль верен > 

Частые вопросы о соли для новичков

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

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

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

Соль в системах Unix

В большинстве unix систем в качестве односторонней функции используется системная библиотека crypt(3). Изначально эта библиотека использовала хеш-функцию на базе алгоритма DES. При этом пароль был ограничен 8 символами (по 7 бит на символ, т.е. 56 бит) и использовалась 12-битная соль. [1]

В 1994 году Poul-Henning Kamp на базе MD5 создал новый алгоритм хеширования паролей, который позволял использовать пароли любой длины и использовал тысячу итераций MD5 [2] [3] . Результатом работы функции стала строка, содержащая метку алгоритма хеширования (версию), соль и собственно хеш.

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

Сейчас библиотека поддерживает несколько хеш-функций на базе алгоритмов: md5, sha-256, sha-512, Blowfish (в некоторых дистрибутивах Linux, OpenBSD и некоторых других UNIX-подобных системах) [5] . Результатом работы функции является строка, содержащая метку алгоритма хеширования, соль, собственно хеш и, опционально, другие данные (например, число раундов хеш-функции).

В 2012 году Poul-Henning Kamp призвал полностью отказаться от созданного им алгоритма, как не обеспечивающего в современных условиях ощутимого увеличения времени вычисления хеша, а значит и не защищающего от полного перебора [6]

Литература

• Robert Morris, Ken ThompsonPassword security: a case history (англ.) // Communications of the ACM : журнал. — ACM New York, NY, USA, 1979. — Т. 22. — № 11. — С. 594 — 597.
• B. KaliskiPKCS #5: Password-Based Cryptography Specification Version 2.0 (англ.) (September 2000). Архивировано из первоисточника 2 июля 2012.Проверено 13 июня 2012.

Примечания

1. ↑Проект OpenNet: MAN crypt (3) Библиотечные вызовы (FreeBSD и Linux)
2. ↑FreeBSD CVS log for src/lib/libcrypt/crypt.c
3. ↑Niels Provos, David MazièresA Future-Adaptable Password Scheme. Paper — 1999 USENIX Annual Technical Conference, June 6-11, 1999, Monterey, California, USA (June 1999). Архивировано из первоисточника 9 августа 2012.
4. ↑Unix crypt with SHA-256/512
5. ↑crypt(3) — Linux manual page
6. ↑Md5crypt Password scrambler is no longer considered safe by author

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

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

2.4K открытий

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

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

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

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

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

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

Злоумышленник может угадывать 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. Для Наташи мы будем использовать соль h1m3gaw0rld, а для Ромы мы будем использовать d0kak1nggg в качестве соли.

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

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

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

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

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

Солим пароли

Данная заметка призвана пролить свет на использование соли при хешировании пароля. Если посмотреть в комментарии к этому топику habrahabr.ru/post/145642, то возникает подозрение, что некоторые люди неправильно понимают предназначение соли. На примерах постараюсь показать, для чего используется этот механизм. Всех заинтересовавшихся прошу под кат.

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

 $password = md5($password); 

В данном случае, если у пользователя пароль qwerty, мы получим следующий хеш: d8578edf8458ce06fbc5bb76a58c5ca4. Если злоумышленник получит доступ к нашей базе, для подбора паролей он может воспользоваться уже готовыми сервисами(http://wordd.org/D8578EDF8458CE06FBC5BB76A58C5CA4), в которых уже есть значения, дающие данный хеш, либо сбрутить самому.
Для защиты от уже готовых таблиц хешей с значениями, можно использовать статическую соль:

 $password = md5($password . "MyUniqueSault"); 

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

 $sault = GenerateRandomString(); $password = md5($password . $sault); 

Т.е. теперь помимо логина/хеша пароля в базе необходимо будет хранить значение сгенерированной соли для каждого пользователя. Разберем пример: у нас два пользователя: user1 и user2. Оба используют пароль qwerty. Но у первого была сгенерирована соль zxcv а у второго asdf. В итоге у пользователей при одинаковом пароле будут различные хеши: 1d8f3272b013387bbebcbedb4758586d и a192862aa3bf46dffb57b12bdcc4c199.Что это дает: теперь нельзя будет сгененерировать одну таблицу хешей, для нахождения значения хеша с динамической солью придется генерировать заново. Все это направлено на увеличение времени подбора значений в случае «слива» базы, при использовании «хороших» алгоритмов хеширования, на подбор хотя бы пары паролей уже может уйти значительное количество времени. Важно понимать, что генерируемая соль защищает не одного единственного пользователя, а всех вместе от массового брута. На этом все, хочу напомнить что используйте криптостойкие алгоритмы хеширования SHA1, SHA512. Используемый выше MD5 к использованию не желателен, т.к. признан устаревшим.

Хорошо резюмировал Kolonist в своем комментарии habrahabr.ru/post/145648/#comment_4894759 ( за что ему отдельное спасибо и плюс):
Еще раз.

1. Нет соли — используем уже готовые радужные таблицы.
2. Есть одна на всех соль — генерируем одну радужную таблицу и «ломаем» по ней всех пользователей.
3. Есть отдельная соль для каждого пользователя — отдельно брутфорсим каждого пользователя.

Безопасное хеширование паролей

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

1. Почему я должен хешировать пароли пользователей в моем приложении?
2. Почему популярные хеширующие функции, такие как md5 и sha1 не подходят для паролей?
3. Если популярные хеширующие функции не подходят, как же я тогда должен хешировать свои пароли?
4. Что такое соль?
5. Как я должен хранить свою соль?

Почему я должен хешировать пароли пользователей в моем приложении?

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

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

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

Почему популярные хеширующие функции, такие как md5() и sha1() не подходят для паролей?

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

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

Если популярные хеширующие функции не подходят, как же я тогда должен хешировать свои пароли?

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

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

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

Учтите, что, если вы используете функцию crypt() для проверки пароля, то вам нужно предостеречь себя от атак по времени, применяя сравнение строк, которое занимает постоянное время. Ни операторы PHP == и ===, ни функция strcmp() не являются таковыми. Функция же password_verify() как раз делает то, что нужно. Настоятельно рекомендуется использовать встроенное API хеширования паролей, если есть такая возможность.

Что такое соль?

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

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

password_hash() создаёт случайную соль в случае, если она не была передана, и чаще всего это наилучший и безопасный выбор.

Как я должен хранить свою соль?

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

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