Что такое соль в хешировании
Перейти к содержимому

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

  • автор:

codedokode / Как солить и хешировать пароли.md

Save codedokode/9576319 to your computer and use it in GitHub Desktop.

Соли @ хешируй

Здесь старая версия урока, которая больше не обновляется.

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

Соли @ хешируй

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

Какой смысл в хэше, если md5 все равно можно расшифровать? Пусть даже перебором?

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

Ок, достаточно ли использовать хеширование и хранить только хеши?

Нет! Без так называемой «соли» многие пароли можно подобрать за секунду если там использовать просто md5(pass). Не веришь? Читай ниже.

Что такое соль? Что значит «соленый хеш»?

Соль — случайно сгенерированная последовательность символов, которая хранится рядом с хешем. Дан пароль $pass = «123456» , мы генерируем случайную соль например $salt = ‘A&%6t*(k:’ и получаем хеш от «соль + пароль»: $hash = md5($salt . $pass) . В базу сохраняется отдельно использованная соль (она для каждого пользователя своя), отдельно хеш.

Теперь попробуем применить математику и посчитать насколько надежны разные способы хеширования. Сейчас подбор пароля делается 2 способами:

Способ 1

Перебираем все возможные пароли, начиная например с 1111111 и заканчивая zzzzzzz и вычисляем от каждого md5-хеш. При этом число вариантов, которые надо подобрать, зависит от длины и набора символов (чем их больше тем больше перебирать). Скорость перебора md5 на топовых видеокартах составляет около 10 миллиардов в секунду ( http://www.opennet.ru/opennews/art.shtml?num=30201 и http://hashcat.net/oclhashcat/ ). А ведь можно взять не одну видеокарту, а много, если очень надо.

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

Считаем число вариантов.

36^6 — значит 36 в 6-й степени, то есть 36*36*36*36*36*36 если что.

  • Если в пароле 12 цифр 0-9 : число комбинаций = 10^12 = 1000 миллиардов = 100 секунд перебора на 1 видеокарте (1 секунда на 100 карточках параллельно).
  • Если 6 букв a-z или цифр 0-9 . Число вариантов = 36^6 (считаем гуглом) = 2 млрд. Хехе, меньше секунды.
  • Если 6 букв a-zA-Z (добавим маленькие и большие буквы) и 0-9 . Комбинаций 62^6 = 56 млрд. 6 секунд перебора.
  • Если в пароле 8 букв a-zA-Z и цифр 0-9 . Комбинаций уже 62^8 = 218 триллионов. Это 22000 секунд перебора (в часе 3600 секунд, так что выходит 6 часов) на 1 карточке или 220 секунд на 100 карточках. Ого, не очень-то надежно.
  • Если в пароле 10 символов a-zA-Z0-9 + 20 знаков вроде минус, плюс.. то выходит 82^10 комбинаций ~ 10^19 и перебирать их 10^9 секунд на одной карте (11500 дней) или 115 дней на сотне карточек.

Люди часто ставят паролем не бредовый набор букв, а слова или куски слов. Значит, какие-то символы рядом встречаются чаще, их можно перебирать в первую очередь тем самым сокращая число вариантов и ускоряя время нахождения.

В общем, видишь, без добавления соли пароли подберутся на раз. И не все же ставят 10-символьные пароли, у многих там просто слово или цифры.

Способ 2

Есть еще другой вариант — скачать огромные радужные таблицы (читай в вики про них) где хранятся уже рассчитанные цепочки хешей (для простых паролей). И конечно все хеши от обычных паролей длиной до 10 символов там уже есть (больше нету, так как они начинают занимать гигабайты. Но это вопрос времени, когда жесткие диски станут больше). Если ты хранишь в базе md5(pass) она вскроется мигом. Таблицы можно скачать тут: https://www.freerainbowtables.com/en/tables2/ (если не открывается, выбери английский язык и открой ссылку еще раз).

Вот пример такой таблицы: md5_loweralpha-numeric#1-10 588 GB — подбирает пароли без соли до 10 символов [a-z0-9].

Заметь что в будущем компьютеры будут мощнее, и значит подбираться пароли будут быстрее. Теперь подумаем как защититься и усложнить жизнь взломщикам:

  • разрешаем использовать больше видов символов в паролях
  • добавляем соль. С солью не получится параллельно подбирать все хеши так как у каждого юзера соль своя и каждый хеш надо перебирать отдельно, что сильно замедляет взлом. Также, при добавлении соли даже к простому паролю он по сути становится длинным и сложным и его не будет в радужных таблицах (123456 → Y^juYUHkd%$fdtd123456). Опять же, соль должна быть подлиннее и содержать спецсимволы чтобы было больше комбинаций для перебора. Ну конечно, простые пароли типа 123456 все равно вскроют, так как их при переборе проверяют в первую очередь. А вот сложные придется подбирать долго.
  • используем вместо md5 более тяжелые для вычисления алгоритмы вроде bcrypt, который сделан так, что его нельзя перебрать быстрее чем за опредеенное время (и ты можешь указать требемый уровень сложности).

С правильным подходом даже простой md5 замучаешься расшифровывать.

В чем суть соли хэш паролей?

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

  • Вопрос задан 12 авг. 2023
  • 191 просмотр

1 комментарий

Простой 1 комментарий

Немного усложнит перебор паролей.
Как минимум стандартные инструменты без настройки не сработают.
Решения вопроса 0
Ответы на вопрос 2

dimonchik2013

Dimonchik @dimonchik2013
non progredi est regredi
Ответ написан 12 авг. 2023
Нравится 1 4 комментария
Юрий Шиков @a55le Автор вопроса

Ну насколько я понял в БД это храниться в формате Логин/Пароль+соль в хэш формате/Соль в текст формате. Вот хацкер получит доступ к бд, в чем проблема будет соль в хэш преобразовать и вычесть из паролей, тем самым получить оригинальный пароль в хэше? Или прикол в том что это займет больше времени?

dimonchik2013

Dimonchik @dimonchik2013

Юрий Шиков, там же описано все, в том число и то что если криво применять — толку никакого

но в целом да — пароль ищется куда быстрее из таблиц чем qwertyC8UpF39Vk^5F

в чем проблема будет соль в хэш преобразовать и вычесть из паролей

Юрий Шиков, в действии обозначенном как «вычесть». Нельзя её быстро «вычесть».
Юрий Шиков @a55le Автор вопроса

Насколько я понял процесс авторизации будет по типу: ввод логин/пароль => получение корректной связки пароль + соль в хэш формате из бд => получение соли в нехэшированном формате из бд => добавление к введенному паролю соль из бд => хэшированние новой связки введеного пароля и соли из бд=> получение логина с бд в формате текста => сравнение связки введенный логин/введенный пароль + соль из бд и связки правильный хэш пароля и соли/правильного логина => ответ на фронте по типу правильный пароль.

mayton2019

mayton2019 @mayton2019
Bigdata Engineer

В 2000х годах хакеры, используя метод радужных таблиц (rainbow tables) научились находить пароль по известному хешу
за вполне короткое время если обладали заранее расчитанной базой этих таблиц. И если они знали
какая хеш-функция работала. Особенно для Windows NTLM у них ловко выходило. И при условии
что пароль был корткий. До 8 символов например. Для большего пароля база росла экспоненциально.

Противостоять этому методу можно было легко. Для каждой единицы программного обеспечения
нужно было создать соль (salt) и на уровне алгоритма и добавлять ее к паролям везде. Логику алгоритма
аутентификации это вообще не меняло но зато отбрасывало злоумышленников во времени намного назад.

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

В криптографии есть аналогия с вектором инициализации IV для симметричных шифров.

Солим пароли

Данная заметка призвана пролить свет на использование соли при хешировании пароля. Если посмотреть в комментарии к этому топику 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. Есть отдельная соль для каждого пользователя — отдельно брутфорсим каждого пользователя.

Зачем нужна соль при хешировании

Очень часто можно встретить различного рода соль при хешировании паролей.

Как она выглядит?

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

$salt = '&WsW

Зачем она все таки нужна?

Криптографическая соль нужна только для одной цели: защита от радужных таблиц. Дублируя википедию, скажу что радужная таблица — это набор готовых (предрассчитанных) хешей и их оригинальных значений. Такие таблицы генерируются обычным брут форсом, часто по словарю (Пример: http://md5decrypt.net). Быстрота определения оригинальной фразы по хешу осуществляется индексированным поиском по всей базе.

Зачастую пароли пользователей очень просты — словарь очень узок и часто пользуются шаблонные слова и словосочетания. В случае, если соль не была добавлена к оргинальному паролю, есть большая вероятность что такой хеш уже скомпрометирован (например хеш от «mypassword» 34819D7BEEABB9260A5C854BC85B3E44 уже есть в базе данных md5decrypt.net).

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

Какие к ней требования?

Требования к соли следующие:

  1. приватную соль не ставить соль в начало фразы, поскольку в таком случае возможна атака удлиннением сообщения
  2. соль должна иметь достаточную длину, хотя бы 10 символов, больше — лучше.
  3. алфавит лучше использовать из всех возможных символов.

2030039 — не очень хорошая соль

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *