что такое salt в шифровании
Солим пароли
Данная заметка призвана пролить свет на использование соли при хешировании пароля. Если посмотреть в комментарии к этому топику 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. Есть отдельная соль для каждого пользователя — отдельно брутфорсим каждого пользователя.
Хеш + соль, как панацея от декрипта
Но это всё была присказка. а сказка — впереди…
Теперь возвращаемся к нашей главной проблеме, КОРОТКИЕ И ПРОСТЫЕ ПАРОЛИ юзеров.
Что мне нужно, что бы «взломать» выше описанный способ «хранения» паролей. А главное — что я уже ИМЕЮ для этого?
А имею я совсем НЕ МАЛО! Можно сказать, что у меня уже есть пароль юзера. А точнее говоря — у меня уже есть все пароли большинства юзеров. А почему? да всё потому же! «короткие и простые пароли юзеров».
Теперь, что я делаю…
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(md5(password)+salt), при этом соль хранится в базе в соседней колонке (ну или в той же колонке где и хэш).
Такой способ конечно усложняет взлом пароля, но имея хеш и соль взломать все равно можно.
Есть ли смысл, если
1. хешируем пароль: hash1 = md5(password)
2. в качестве соли берем допустим 10 символом от хеша hash1
3. получаем итоговый хэш по старому алгоритму: md5(md5(password)+salt), или
md5( md5(password)+substr(md5(password),0,10) )
Вопрос: будет ли этот способ лучше способа с хранением соли в отдельной колонке, или хуже? Может есть что-то более «хитро-извращенное»?
Да, конечно этот способ лучше.
То, что вы предлагаете называется динамической солью.
Если уж хочется чего-то «хитро-изварщенного», то можно хранить в базе что-то такое:
где динамическая соль будет вычисляться так, например:
Обычно как… соль для каждого пользователя своя. Обычно это рандомная строка. При хешировании пароля с солью достигается большая криптозащита за счет увеличения времени перебора для получения нужной строки пароля + соли.
А можно сделать еще круче — можно использовать медленные алгоритмы. Тобиш скажем хеширование происходит в цикле. Если колличество итераций динамическое — то и это хорошо. И алгоритмы шифрования надо брать не быстрый md5 а что-нибудь помедленнее, например sha512. Это в свою очередь сведет попытки подбора хэша и генерации радужных таблиц на нет, ибо каждый вариант перебора будет происходить немыслимо медленно. На хорошей видиокарте с CUDA можно в секунду сгенерить миллиончик MD5 хэшей. А так хорошо если сотню сгенерит.
Для чего вообще нужна соль? А для того, чтобы md5(password)+salt было достаточно длинным, чтобы его нельзя было получить из хэша по предвычисленным таблицам. Таблица-то даст что-то, но нет никакой гарантии, что в конце будет именно ваша соль.
По-моему, криптостойкость одна и та же: тот же уровень противодействия перебору и та же защита от таблиц.
Как надо хешировать пароли и как не надо
В очередной раз, когда мы заканчивали проводить аудит информационной безопасности веб-проекта, моя личная бочка с гневом переполнилась негодованием так, что оно перелилось через край в этот пост.
Постараюсь очень лаконично и быстро обрисовать ситуацию с хэшами.
Сразу определю какую задачу применения хешей буду рассматривать — аутентификация пользователей. Не токены восстановления паролей, не аутентификация запросов, не что-то еще. Это также не статья про защиту канала передачи данных, так что комментарии по 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 оказался безболезненным). Выбор конкретного идеального типа хеша в конкретной ситуации может сильно разнится. Так, например, ДБО все чаще выбирают железные решения для генерации хешей с заданной скоростью.
Salt за 10 минут
SaltStack — cистема управления конфигурациями и удалённого выполнения операций.
В данный момент изучаю данную систему и раз уж есть такая возможность решил попереводить статьи с официального сайта и повыкладывать здесь пока хватит энтузиазма. Т.к. у нас в организации используется в основном Red Hat и Centos, переводить буду части касающиеся этих операционных систем.
Данная статья представляет собой перевод официальной документации. Внизу страницы вы найдете ссылку на первоисточник на англ. языке.
Установка SALT
Установка salt-master, salt-minion из официального репозитория SaltStack на RHEL / CENTOS
Внимание! При установке на Red Hat Enterprise Linux 7 с отключенными (не подписанными на) ‘RHEL Server Releases’ или ‘RHEL Server Optional Channel’ репозиториями, добавьте CentOS 7 GPG key URL к конфигурации yum репозитория SaltStack для установки базовых пакетов.
Установите salt-minion, salt-master и другие Salt компоненты:
Запуск SALT
Salt работает по топологии Master(сервер) / Minion(клиент). Миньоны подключаются к мастеру на порты TCP 4505,4506.
Дефолтная конфигурация Мастера подходит для подавляющего большинства установок. Salt Master управляется локальными сервис менеджерами:
На системах с systemd (новые Debian, OpenSuse, Fedora, Centos, RHEL):
На системах с Upstart (Ubuntu, older Fedora/RHEL):
Альтернативно, Мастер может быть запущен напрямую через командную строку как демон:
Мастер может быть также запущен в debug режиме, таким образом значительно увеличивая вывод команд:
Мастер принимает входящие соединения на портах TCP 4505,4506.
Поиск SALT MASTER
По умолчанию конфигурационные файлы лежат в каталоге /etc/salt. Большинство платформ придерживаются этой схемы, но такие платформы как FreeBSD и Windows располагают этот файл в других местах.
При старте Миньон по умолчанию ищет в сети хост с hostname salt. Если нашел, то Миньон инициирует процесс рукопожатия и аутентификации по ключу с Мастером. Это означает, что самый простой способ конфигурации это настроить внутренний DNS на разрешение имени salt в IP Мастера.
Если такой подход не устраивает, то можно внести изменения в /etc/salt/minion:
Настройка SALT MINION
Миньон может функционировать как с Мастером так и без него. Это руководство предполагает, что Миньон будет подключен к Мастеру, для получения информации о том, как запустить Миньон без Мастера смотрите тут.
После того, как Мастер может быть найден, запустить Миньон можно так же, как Мастера:
На системах с systemd (новые Debian, OpenSuse, Fedora, Centos, RHEL):
На системах с Upstart (Ubuntu, older Fedora/RHEL):
В фоновом режиме с опцией debug:
Когда Миньон запускается, он генерирует id, если он не был сгенерирован во время предыдущего запуска и кэширует в /etc/salt/minion_id по умолчанию. Это имя по которому Миньон будет пытаться аутентироваться на Мастере. Следующие шаги предпринимаются, чтобы попытаться найти значение отличное от localhost:
Если ничего не сработало, то localhost используется как запасной вариант.
id Миньона может быть задан вручную используя параметр id в файле конфигурации Миньона. Если этот параметр задан, то он будет переопределять все другие источники id.
Теперь, когда Миньон запущен, он будет генерировать криптографические ключи и пытаться подключиться к мастеру. Следующим шагом надо вернуться к Мастеру и принять новый открытый ключ Миньона.
Использование SALT-KEY
Salt аутентифицирует Миньонов используя открытый ключ шифрования и аутентификацию. Чтобы Миньон мог начать принимать команды от Мастера его ключ должен быть принят Мастером.
Команда salt-key используется для управления всеми ключами на Мастере. Для просмотра всех ключей, которые находятся на Мастере:
Будут выведены ключи, которые были приняты, отклонены и находятся в ожидании принятия. Самый простой способ принят ключ миньона это принять все отложенные ключи:
Скопируйте значение отпечатка master.pub из секции Local Keys и установите в качестве параметра master_finger в конфигурационном файле Миньона. Сохраните и перезапустите сервис salt-minion.
Если совпадают, то примите ключ командой:
Посылка первых команд
Сейчас, когда миньон подключен к Мастеру и аутентифицирован, Мастер может отправлять команды Миньону. Salt-команды позволяют выполнить обширный набор функций и для конкретных Миньонов или групп Миньонов. Salt-команды состоят из опций команд, описания цели, функции исполнения и аргументов функции.
Простая команда выглядит так:
Звездочка ( * ) определяет цель, которая определяет всех Миньонов. test.ping говорит миньонам запустить функцию test.ping. В случае test.ping, test ссылается на модуль исполнения. ping ссылается на функцию ping содержащуюся в вышеуказанном модуле.
Внимание! Исполнительные модули — это рабочие лошадки Salt. Они выполняют работу в системе выполняя различные задачи, такие как манипулирование файлами и рестарт сервисов.
Результатом выполнения этой команды будет оповещение Мастера, что все миньоны выполнили test.ping параллельно и возвращение результата.
Это на самом деле не ICMP ping, а скорее простая функция, которая возвращает True. Использование test.ping это хороший способ подтверждения что Миньон подключен.
Каждый Миньон регистрирует себя с уникальным ID. Этот ID по умолчанию есть hostname, но может быть явно задан в конфиге Миньона также с помощью параметра id.
Конечно существуют сотни других модулей, которые могут быть вызваны просто как test.ping. В следующем примере возвращается использование диска на всех Миньонах.
Знакомство с функциями
Salt поставляется с обширной библиотекой функций, доступных для выполнения и Salt функции являются самодокументирующимися. Чтобы увидеть какие функции доступны на Миньонах выполните sys.doc функцию:
Она покажет очень большой список доступных функций и документацию по ним.
Внимание! Документация модулей также может быть доступна на сайте.
Эти функции охватывают все, от управления пакетами до управления серверами баз данных. Они включают в себя мощную систему управления API, которая является основой для управления конфигурациями Salt и многих других сторон Salt.
Внимание!
Salt поставляется с большим кол-вом системных плагинов. Функции, которые доступны по средствам salt команд называются исполнительными модулями.
Полезные функции
Модуль cmd содержит функции которые выполняются на Миньонах, такие как cmd.run и cmd.run_all:
pkg функции автоматически сопоставляют локальный менеджер пакетов с соответствующими функциями. Это означает pkg.install установит пакеты через yum на Red Hat системы, через apt на Debian системы и т.д.:
Внимание! Некоторые кастомные сборки Linux и производные от некоторых дистрибутивов не правильно определяются определяются Salt. Если приведенная выше команда возвращает ошибку типа pkg.install is not available тогда вы можете переопределить pkg provider. Этот процесс описан здесь.
Функция network.interfaces выводит список всех интерфейсов на Миньоне, вместе с их IP-адресами, масками, MAC-адресами и т.д.:
CHANGING THE OUTPUT FORMAT
Формат вывода по умолчанию используемый для большинства команд Salt называется nested (вложеный), но существуют несколько других способов, которые могут использованы для изменения вывода. Например, pprint способ может быть использован для отображения возвращенных данных использующий Python-кий модуль pprint:
Полный список способов вывода Salt, а также примеры вывода могут быть найдены здесь.
SALT-CALL
Примеры выше описывали запуск команд с Мастера используя salt команду, но при диагностике может быть более эффективным зайти на Миньон по ssh и использовать salt-call.
Зерна (GRAINS)
Salt ипользует систему, называемую Grains для построения статических данных о Миньонах. Эти данные включают в себя информацию о ОС, CPU архитектуре и много другое. Система grains испольуется Salt для доставки данных платформы многим компанентам и пользователям.
Grains может также быть статическим набором, что делает его легким для присвоения значений Миньонам для группировки и управления.
Обычной практикой является назначение зерен Миньонам, чтобы указать какую роль или роли возможны для Миньон. Эти статические зерна могут быть установлены в конфигурационном файле Миньона или через grains.setval функцию.
Выбор цели
Salt позволяет указывать Миньонов в качестве цели по большому кол-ву критериев.
Есть много других способов помимо основных:
Regular Expressions
Используя pcre-совместимые регулярные выражения
Grains
Цель основанная на данных grains: Targeting with Grains
Pillar
Цель основанная на данных pillar: Targeting with Pillar
IP
Цель основанная на IP address/subnet/range
Compound
Цель основанная на нескольких целях: Targeting with Compound
Nodegroup
Target with nodegroups: Targeting with Nodegroup
Передача аргументов
Много функций могут применять аргументы, которые могут быть переданы:
В этом примере передается аргумент vim функции pkg.install. Много функций могут иметь более сложные аргументы чем просто строка, аргументы обрабатываемые через YAML, позволяющие передавать более сложные данные:
В этом случае Salt переводит строку ‘foo: bar’ в словарь «<'foo': 'bar'>«
Внимание! Любая строка, которая содержит символ новой строки не будет обработана в YAML.