что такое соль в программировании

Солим пароли

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

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

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

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

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

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

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

Источник

Как надо хешировать пароли и как не надо

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

Постараюсь очень лаконично и быстро обрисовать ситуацию с хэшами.

Сразу определю какую задачу применения хешей буду рассматривать — аутентификация пользователей. Не токены восстановления паролей, не аутентификация запросов, не что-то еще. Это также не статья про защиту канала передачи данных, так что комментарии по challenge-response и SSL неуместны!

Матчасть (короткая)

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

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

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

Для выполнения первого требования нужно использовать стойкие в настоящее время (а не в 90х годах!) хеш-функции.
Для выполнения второго — к паролю перед хешированием добавляется случайная строка (соль). Таким образом, у двух пользователей с паролем «123456» будут разные соли «соль1» и «соль2», а соответственно и хеш-функции от «123456соль1» и «123456соль2» в базе тоже будут разные.

Теперь немного про систему хранения — и соль и сам хеш хранятся в базе данных.
То есть получив доступ к СУБД, злоумышленник получает и значения хешей и соли.

Используйте локальный параметр!

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

Для того чтобы еще усложнить жизнь атакующему, Solar Designer www.openwall.com/presentations/YaC2012-Password-Hashing-At-Scale/mgp00005.html предлагает ввести еще одну штуку, под названием локальный параметр.

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

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

Единственный раз мы (ONsec) ломали хеши с локальным параметром, выработав при этом тактику атаки на сам локальный параметр (регистрируемся в приложении, затем ищем в базе свой хеш, соль (свой пароль мы и так знаем) и перебираем ЛП). И тщетно. На длинах 16+ байт для современных функций хеширования — это очень дорого по железу. В итоге проще оказалось скомпрометировать систему аутентификации (проставить себе role=admin в базе через UPDATE )

Защищайте свои хранилища надежно и грамотно!

Заключение

Буду реалистом — естественно, никто не станет переписывать свои проекты ради «каких-то» хешей. Но новые проекты можно писать на scrypt/bcrypt. А также — внедряйте локальный параметр даже на слабых MD5 — он правда помогает, проверено

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

Источник

Взлом «посоленных» хешей

Безопасность веб-приложений: Что можно, а что нельзя делать при шифровании с использованием соли.

Безопасность веб-приложений: Что можно, а что нельзя делать при шифровании с использованием соли

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

Соль (Криптография)
http://en.wikipedia.org/wiki/Salt_(cryptography)
Предположим, что украден хешированный пароль пользователя. Известно, что пароль является одним из 200,000 английских слов. Система использует 32-х битную соль. «Посоленный» ключ – это оригинальный пароль, добавленный к произвольной 32-х битной соли. Из-за соли посчитанные хеши злоумышленника не подойдут (не удастся использовать радужные таблицы). Злоумышленник должен посчитать хеш каждого слова с каждым из 232 (4,294,967,296) возможных вариантов соли, добавленных к паролю, до тех пор, пока не будет получено совпадение. Общее число возможных комбинаций может быть получено умножением количества слов в словаре на количество возможных вариантов соли:
2^ <32>\умножить на 200 000 = 8.58993459 \умножить на 10^ <14>
Для завершения брут-форс атаки злоумышленник должен перебрать почти 900 триллионов хешей, вместо всего-лишь 200,000. Даже если пароль сам по себе достаточно прост, соль делает взлом паролей достаточно сложной операцией.
Соль должна быть неизвестной. Если злоумышленник знает, какая используется соль, он сразу может перейти к первому шагу. Ниже приведены несколько возможных способов взлома «посоленных» хешей.

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

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

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

Иногда такого рода программы выдают много информации.

Пункт №1: Всегда шифруйте вашу базу данных паролей.

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

Функция: md5(“входные данные”); Hash(“входные данные”); Вывод: 32 Символа Пример: “5f4dcc3b5aa765d61d8327d eb882cf99”

Функция: System.Security.Cryptogr aphy Вывод: 32 Символа Пример: “5f4dcc3b5aa765d61d8327d eb882cf99”

Функция:java.secur ity.MessageDigest Вывод: 32 Символа Пример: “5f4dcc3b5aa765d61d 8327deb882cf99”

Функция: Crypt() По-умолчанию DES вывод: 13 Символов Пример: “sih2hDu1acVcA”

Источник

Хеш + соль, как панацея от декрипта

Но это всё была присказка. а сказка — впереди…

Теперь возвращаемся к нашей главной проблеме, КОРОТКИЕ И ПРОСТЫЕ ПАРОЛИ юзеров.

Что мне нужно, что бы «взломать» выше описанный способ «хранения» паролей. А главное — что я уже ИМЕЮ для этого?
А имею я совсем НЕ МАЛО! Можно сказать, что у меня уже есть пароль юзера. А точнее говоря — у меня уже есть все пароли большинства юзеров. А почему? да всё потому же! «короткие и простые пароли юзеров».

Теперь, что я делаю…
1. Я регюсь на взламываемом сайте.
2. Взламываю БД или то место, где хранятся хеши паролей. (это условие данной темы)
3. Нахожу свой хеш. (по моему имени юзера)

-. Зачем мне нужны первые три шага?
+. Для того, чтобы определить, каким образом получают хеш на сайте. Т. е. я перебираю возможные варианты:
md5($pass);
md5(md5($pass));
md5(md5(md5($pass)));
sha1(md5(crypt($pass)));
… и т. д., пока не получу мой хеш!
Если программер использовал просто md5(md5($pass));, то мне легче.

4. «Формула» получения хеша у меня есть, теперь мне нужна прога которая сгенерирует
все хеши ПО ДАННОЙ формуле (скачаю или сам напишу), и не много времени (если в секунду 1’000’000 хешей, то для 56’800’235’584 хешей это около 20 часов, НО это считайте МАКСИМУМ, а если по словарю перебирать или только пароли из цифр, то времени на порядок меньше потребуется).
И ВСЁ! Все пароли длиной до 6-и символов у меня «в кармане»!

И так! Этот метод взломали, теперь ПРО СОЛЬ…

Ломаем метод автора статьи…

-. Выполняю первые 3 шага.

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

И что я делаю?
Да всё тоже самое.

Просто теперь при поиске «формулы» получения хеша я добавляю эту соль, при чём всеми возможными вариантами!

md5(md5($pass.$salt));
md5(md5($pass).$salt);
md5(sha1($salt.crypt($pass)));
… и т. д…
Ну а далее думаю уже догадываетесь… Генерю все хеши добавляя соль УЖЕ в правильное место и используя правильную формулу.

НО здесь как видите уже есть один «худенький» плюсик.
Речь уже идёт не о взломе всех паролей, а о взломе одиночного аккаутна, соль то для каждого юзера своя, а значит генерировать таблицу придётся для каждого юзера заново. Во как!
А почему плюсик «худенький»?
Да опять же всё потому, что «ПРОСТЫЕ И КОРОТКИЕ ПАРОЛИ». (на верное я вам уже надоел. терпи’те!)

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

Так же, даты когда юзер пишет что то типа 111977; (1 января 1977 года, т. е. варианты без нулей)

Так же варианты с 7-и значными датами и с 8-и значными…

«Год у меня был… 3 — за побег… 5 — за дет-сад… ну сколько за старуха дадут? ну пусть 10 лет… И я из-за каких-то 16 лет. »

Ну пусть у нас получилось всего 1’000’000 вариантов даты рождения! Если машина генерирует 1’000’000 хешей в секунду — получается я буду вскрывать по юзеру в секунду, а если двигаться от младших к старшим, то ещё быстрее.

И что у нас получилось? Мы вскрыли за один час — 3600 юзеров «с СОЛЬЮ»!

И вся прелесть в том, что и соль НЕ ПОМОГЛА! А почему? Вижу по лицу, уже догадались!
последний раз: «ПРОСТЫЕ И КОРОТКИЕ ПАРОЛИ».

«И что же?» — скажете вы — «значит нет надёжного метода?».

И ПРАВИЛЬНО скажете!

Вы ищете в интернете надёжный метод или как вы ещё любите «часто используемый метод», и при этом вы УЖЕ СОВЕРШАЕТЕ ОШИБКУ! потому, как «то, что знают двое — знают все!» и как вы знаете «то, что один человек построил — другой завсегда поломать сможет».

Ну так и что же делать?

А всё просто, «ХОЧЕШЬ ЖИТЬ — УМЕЙ ВЕРТЕТЬСЯ!»

Не используйте общеизвестные приёмы, или изменяйте их на свой манер, отпиливайте, приклеивайте, меняйте местами, копируйте, придумывайте что то своё, и т. д. и т. п… Думайте своей головой. И вообще, подумайте, а стоит ли овчина выделки. Нужна ли вам эта бетонная крепость, или можно и и так прожить в деревянной… Даже если вы напишете код, который будет чередовать функции хеширования 10-20 раз, например в файле «enter.php». Во первых: что мне помешает написать программку которая будет перебирать все варианты чередования функций md5, sha1, crypt, и т.д., и в итоге будет находить нужную последовательность за считанные секунды. А во вторых: где гарантия, что я не заставлю сервер не выполнить ваш файл «enter.php», а просто прочитать его, или найти в вашем сайте ещё какую дырку и получить исходный код файла. И тогда хоть ваш код чередует 1000 раз, да и всё что угодно, я просто повторю ваш код при генерации таблицы хешей и результат будет тот же, а все ваши старания понапрасну…

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

Источник

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

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

Источник