Невипадкова сіль для хешування паролів

ОНОВЛЕННЯ: Нещодавно з цього запитання я дізнався, що в усьому обговоренні нижче я (і я впевнений, що і інші) був трохи заплутаним: те, що я продовжую називати райдужним столом, насправді називається хеш-таблицею. Веселкові столи - це більш складні істоти, і насправді вони є різновидом Hellman Hash Chains. Хоча я вважаю, що відповідь все та ж (оскільки справа не зводиться до криптоаналізу), деякі обговорення можуть бути дещо перекошеними.
Питання: " Що таке райдужні столи і як вони використовуються? "

Як правило, я завжди рекомендую використовувати криптографічно сильну випадкову величину як сіль, для використання з хеш-функціями (наприклад, для паролів), наприклад, для захисту від атак Rainbow Table.

Але чи насправді криптографічно необхідно, щоб сіль була випадковою? Чи достатньо в цьому відношенні якогось унікального значення (унікального для кожного користувача, наприклад userId)? Фактично це не дозволило б використовувати одну таблицю Веселки для злому всіх (або більшості) паролів у системі ...
Але чи справді відсутність ентропії послаблює криптографічну міцність хеш-функцій?

Зауважте, я не запитую про те, навіщо використовувати сіль, як її захищати (це не обов’язково), використовуючи єдиний константний хеш (не потрібно) чи яку хеш-функцію використовувати.
Тільки потрібна солі ентропія чи ні.

Дякую всім за відповіді на даний момент, але я хотів би зосередитись на областях, які (трохи) мені менш відомі. В основному це має наслідки для криптоаналізу - я був би дуже вдячний, якщо хтось має якийсь внесок від крипто-математичного PoV.
Крім того, якщо є додаткові вектори, які не враховувались, це теж чудово (див. Пункт @Dave Sherohman на декількох системах).
Окрім цього, якщо у вас є якась теорія, ідея чи найкраща практика - підкріпіть це будь-якими доказами, сценарієм нападу або емпіричними доказами. Або навіть обгрунтовані міркування щодо прийнятних компромісів ... Я знайомий з Передовою практикою (велика буква В) з цього питання, я хотів би довести, яку цінність це насправді надає.

РЕДАГУВАТИ: Тут є дійсно хороші відповіді, але я думаю, як каже @Dave, це зводиться до Веселкових таблиць для загальних імен користувачів ... і можливих менш поширених імен теж. Однак що, якщо мої імена користувачів є глобально унікальними? Не обов’язково унікальний для моєї системи, але для кожного користувача - наприклад, електронна адреса.
Не було б стимулу будувати RT для одного користувача (як підкреслював @Dave, сіль не тримається в таємниці), і це все одно запобігало б кластеризації. Єдина проблема полягала б у тому, що у мене можуть бути однакові адреси електронної пошти та пароль на іншому сайті - але сіль все одно не завадить цьому.
Отже, це зводиться до криптоаналізу - необхідна ентропія чи ні? (Зараз я думаю, що це не потрібно з точки зору криптоаналізу, а з інших практичних причин).

Сіль традиційно зберігається як префікс до хешованого пароля. Це вже робить це відомим будь-якому зловмиснику, який має доступ до хешу паролів. Використання імені користувача як солі чи ні не впливає на ці знання, а отже, це не вплине на безпеку однієї системи.

Однак використання імені користувача або будь-якого іншого контрольованого користувачем значення як солі зменшило б безпеку між системами, оскільки користувач, який мав одне і те ж ім'я користувача та пароль у кількох системах, що використовують один і той же алгоритм хешування паролів, в кінцевому підсумку отримав би один і той же хеш пароля. кожна з цих систем. Я не вважаю це суттєвою відповідальністю, оскільки я, як зловмисник, намагався би спробувати паролі, які цільовий обліковий запис раніше використовував в інших системах, перш ніж намагатися будь-яким іншим способом зламати обліковий запис. Ідентичні хеші лише заздалегідь повідомлять мені, що відомий пароль буде працювати, вони не полегшать фактичну атаку. (Однак зауважте, що швидке порівняння баз даних облікових записів дасть список цілей з більш високим пріоритетом, оскільки це повідомляє мені, хто є і хто не використовує повторно паролі.)

Більша небезпека від цієї ідеї полягає в тому, що імена користувачів часто використовуються повторно - майже на будь-якому веб-сайті, який ви бажаєте відвідати, буде обліковий запис користувача з ім'ям "Дейв", наприклад, а "адміністратор" або "root" ще більш поширені - що може зробити побудова райдужних таблиць, націлених на користувачів із цими загальними назвами, набагато простіша та ефективніша.

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

Відредаговано Додавати: Багато людей говорять про ентропію і про те, чи важлива ентропія в солі. Це так, але не з тієї причини, що більшість коментарів до нього, здається, думають.

Загальна думка така, що ентропія важлива для того, щоб зловмиснику було важко вгадати сіль. Це неправильно і, насправді, абсолютно неактуально. Як кілька разів вказували різні люди, атаки, на які впливатиме сіль, може здійснювати лише той, хто має базу даних паролів, а хтось із базою даних паролів може просто подивитися, що таке сіль кожного облікового запису. Чи можна це здогадатися чи ні, не має значення, коли ви можете тривіально шукати це.

Причина важливості ентропії полягає у тому, щоб уникнути кластеризації значень солі. Якщо сіль базується на імені користувача, і ви знаєте, що у більшості систем буде обліковий запис з іменем "root" або "admin", тоді ви можете скласти райдужну таблицю для цих двох солей, і це зламає більшість систем. Якщо, з іншого боку, використовується випадкова 16-бітна сіль і випадкові значення мають приблизно рівномірний розподіл, то вам потрібна райдужна таблиця для всіх 2 ^ 16 можливих солей.

Йдеться не про те, щоб запобігти зловмисникові знати, що таке сіль окремого облікового запису, а про те, щоб не дати їм велику жирну ціль однієї солі, яка буде використана на значній частині потенційних цілей.

Використання солі з високою ентропією є абсолютно необхідним для надійного зберігання паролів.

Візьміть моє ім'я користувача 'gs' і додайте його до мого пароля 'MyPassword' дає gsMyPassword. Це легко зламати, використовуючи райдужну таблицю, тому що, якщо ім’я користувача не має достатньої ентропії, можливо, це значення вже зберігається в райдужній таблиці, особливо якщо ім’я користувача коротке.

Іншою проблемою є атаки, коли ви знаєте, що користувач бере участь у двох або більше службах. Існує маса загальних імен користувачів, мабуть, найважливіші з них - це адміністратор та root. Якщо хтось створив райдужну таблицю, яка містить солі з найпоширенішими іменами користувачів, він міг би використовувати їх для компрометації облікових записів.

Раніше вони мали 12-бітну сіль . 12 біт - це 4096 різних комбінацій. Це було недостатньо безпечно, оскільки сьогодні стільки інформації можна легко зберегти . Те саме стосується 4096 найпоширеніших імен користувачів. Цілком ймовірно, що деякі з ваших користувачів виберуть ім’я користувача, яке належить до найбільш поширених імен користувачів.

Я знайшов цю перевірку паролів, яка розробляє ентропію вашого пароля. Наявність меншої ентропії в паролях (наприклад, за допомогою імен користувачів) значно полегшує райдужні столи, оскільки вони намагаються охопити принаймні всі паролі низькою ентропією, оскільки вони частіше трапляються.

Це правда, що одне лише ім’я користувача може бути проблематичним, оскільки люди можуть ділитися іменами користувачів на різних веб-сайтах. Але це мало б бути безпроблемно, якби користувачі мали різні імена на кожному веб-сайті. То чому б просто не зробити його унікальним на кожному веб-сайті. Хешуйте пароль приблизно так

хешфункція ("www.yourpage.com /" + ім'я користувача + "/" + пароль)

Це має вирішити проблему. Я не майстер криптоаналізу, але я впевнений, що той факт, що ми не використовуємо високу ентропію, зробив би хеш слабшим.

Мені подобається використовувати і те, і інше: високоентропійна випадкова сіль на запис, плюс унікальний ідентифікатор самого запису.

Незважаючи на те, що це не додає великого рівня захисту від атак на словники тощо, воно видаляє випадки, коли хтось копіює свою сіль та хеш в інший запис, маючи намір замінити пароль своїм.

(Слід визнати, що важко придумати обставину, коли це стосується, але я не бачу шкоди в ременях і брекетах, коли справа стосується безпеки.)

Якщо сіль відома або легко здогадається, ви не збільшили складність атаки за словником. Можливо, навіть можливо створити модифікований райдужний стіл, який враховує «постійну» сіль.

Використання унікальних солей підвищує складність атак зі словником BULK.

Ідеально мати унікальну, криптографічно сильну цінність солі.

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

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

Сила хеш-функції не визначається її введенням!

Використання солі, відомої зловмиснику, очевидно, робить побудову таблиці веселки (особливо для жорстко закодованих імен користувачів, таких як root ) більш привабливою, але це не послаблює хеш . Використання солі, яка невідома зловмиснику, ускладнить атаку системи.

Об’єднання імені користувача та пароля все ще може забезпечити запис для інтелектуальної райдужної таблиці, тому використання солі ряду псевдовипадкових символів, що зберігається з хешованим паролем, є, мабуть, кращою ідеєю. Для ілюстрації, якщо б я мав ім’я користувача „картопля” та пароль „пиво”, об’єднаним введенням для вашого хешу є „картопляне пиво”, що є розумним записом для райдужної таблиці.

Зміна солі щоразу, коли користувач змінює свій пароль, може допомогти перемогти тривалі атаки, як і застосування розумної політики щодо паролів, наприклад, змішаний регістр, пунктуація, мінімальна довжина, зміна після n тижнів.

Однак я б сказав, що ваш вибір алгоритму дайджесту є більш важливим. Наприклад, використання SHA-512 виявиться більшим болем для когось, хто створює райдужний стіл, ніж MD5, наприклад.

Сіль повинна мати якомога більше ентропії, щоб забезпечити, якщо дане вхідне значення буде хешовано кілька разів, отримане хеш-значення буде, як можна ближче, завжди різним.

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

Чим менше ентропії в солі, тим більше у вас шансів на генерування одного і того ж значення солі, оскільки, таким чином, більше шансів на генерування того самого хеш-значення.

Саме природа хеш-значення є "постійною", коли вхідні дані відомі, і "постійною", що дозволяє атакам словників або таблиць веселки бути настільки ефективними. Максимально змінюючи отримане значення хешу (використовуючи високі значення солі ентропії), гарантує, що хешування одного і того ж входу + випадкової солі дасть багато різних результатів хеш-значення, тим самим перемагаючи (або принаймні значно знижуючи ефективність) райдужну таблицю атаки.

Ентропія є точкою значення Солі.

Якщо за сіллю стоїть якась проста і відтворювана "математика", це все одно, що солі немає. Просто додавання значення часу повинно бути нормальним.