Если известна соль и хэш пароля, чем это отличается от того же, но без соли?

Поиск будит медленнее

Но таблица может быть сгенерирована же? Соль-то известна.

Что такое «парольная» хеш-функция? Crypt? Он вроде давно уже не юзается нигде, везде минимум мд5 или sha1.

А так да, соль нарушает соответствие пароль->хэш в готовых таблицах для перебора.

Генерация таблицы это, по сути, то же самое что и перебор. Какой смысл?

Сломать можно всё. Кроме следующего пароля:

123456 (угадал ведь, да?)!

Хотя, всё ещё существует опасность подбора человеком :)

смысл в том что таблицы уже есть готовые

Таблицы готовые есть, но несолёные. А товарищ предлагает сгенерить новую таблицу для конкретно его соли, что бессмыслено.

Да, но соль может быть в любом месте «пароля» что не позволяет с легкостью её обойти.

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

Моя видяха HD7770 может считать до 250 млн SHA256 за секунду — это примерно 8 Гб только хешей (без самого значения, из которого вычисляли хеш). Всего лишь за сутки будет больше 650 Тб информации. От одной видяхи. Куда их записывать с такой скоростью и самый важный вопрос — где и как хранить такие объемы?

PS: Тут многие выступали... В общем соль приписывается спереди (сзади, сбоку, да куда угодно) к паролю и:

• Повышает его безопасность (123456 или sdfghj123456);
• усложняет как кодирование, так и декодирование (если твой скрипт пытается логинится в цикле, он будет работать очень долго);
• Из-за соли даже валидный пароль декодируется ~300 мсек, так что брут отпадает по определению

1. Безопасность она не повышает. Соль - известна заранее, как она может повысить безопасность?

2. Это да, но не очень сильно.

3. 300мсек на хеширование пароля? Это на чём, на китайском калькуляторе?

Безопасность она не повышает.

Допустим тётя Лариса (подруга твоей мамы), что бы не париться придумала себе пароль 123. А тут херакс! К нему добавляется 71182d5d689c02948d9b189c55481dea. В итоге 71182d5d689c02948d9b189c55481dea123. Привет брутфорсерам.

2) использование именно парольных хэш-функций вместо криптографических оказывает заметное влияние?

Я ничего не понял. Какие-какие хеш-функции?

Гениально. Только проблема в том, что соль хранится рядом с хешем пароля в открытом виде (иначе как её использовать при верификации вводимого пароля?) и поэтому сложности не добавляет :) Ты, похоже, не совсем себе представляешь алгоритм.

Вот и я об этом. Просто нет преимущества использовать таблицы для несоленых паролей - и все?

Те, которые by design работают медленнее или потребляют больше памяти, что не дает возможности массово параллельно их считать - это парольные, а те, которые быстро отрабатывают - криптографические. Есть ли смысл об этом говорить вообще?

Это у тебя какая-то каша в голове. Для усложнения брутфорса используется многократное хеширование, например в LUKS:

# cryptsetup luksDump /dev/sdg
...
MK iterations:  59625
...

Нет такого разделения на «парольные» и криптографические хеши.

Есть хеши слабые, подверженные коллизиям, но быстрые (CRC32 к примеру) и есть хеши сильные, потенциально не подверженные коллизиям в обозримом будущем, как sha256 и выше. Те, которые сильные обычно называют криптографическими.

Я вот это читал: http://crypto.stackexchange.com/questions/3196/what-differentiates-a-password...

Там тоже сказано, что разделения как такового нет, но кое-как их различают.

У меня просто преподавтель спросил сегодня, в чем преимущество хэшировать пароль с солью, если он один. Мне вот стало интересно - и в самом деле, неочевидно же преимущество.

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

Как минимум радужные таблицы сделает малоприменимыми.

Там вопрос был как раз про _одного_ пользователя в /etc/shadow. Таблицы, наверное, единственный ответ.

Таблицы + небольшое усложнение брута за счёт дополнительных операций сложения строк пароля и соли, и удлинения хешируемой строки.

Те, которые by design работают медленнее или потребляют больше памяти, что не дает возможности массово параллельно их считать

Ты про 100500-кратное применение хеш-функций? Не стоит его лепить к аутентификации на сайте, ибо работает действительно долго. Это используется, как правило, для защищенной транспортировки закрытых ключей (пакет PKCS#12) и тому подобных целей, где эти вычисления производятся достаточно редко.

Вопрос у автора очень уж теоретический, про одного пользователя. Главный плюс соли, что она не дает произвести атаку сразу на всю базу паролей (разумеется соли должны быть разные). И в ответах уважаемое сообщество начинает склонятся к бесполезности соли. А конкретно по заданию автора: имеем хэш, несоленый 991d857082824900bfd9b50e3f92e5ae, гуглим, платим ~60 центов получаем в считанные секунды пароль - yadyogjij. Если пароль пароль посолили, и даже соль известна, то CUDA нам в помощь и ждать придется недели, а то и месяцы... И проблема не в том, что радужные таблицы можно сгенерировать, а в том, что они уже есть и генерируют их уже десятилетие и террабайты их и хранить их есть где...