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

Question

[Юрий Шиков]

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

Comments

[aleks-th]

Немного усложнит перебор паролей.
Как минимум стандартные инструменты без настройки не сработают.

Answer 1

[Dimonchik]

в усложнении , затруднении и увеличении времени взлома

Comments

[Юрий Шиков]

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

[Dimonchik]

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

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

[jcmvbkbc]

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

Юрий Шиков, в действии обозначенном как "вычесть". Нельзя её быстро "вычесть".

[Юрий Шиков]

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

Answer 2

[mayton2019]

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

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

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

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