Як допоможе сіль для паролів проти нападу веселки на стіл?

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

Я бачив багато навчальних посібників, які пропонують використовувати сіль як наступне:

$hash =  md5($salt.$password)

Обґрунтування полягає в тому, що хеш зараз не відповідає оригінальному паролю, а комбінації пароля та солі. Але скажіть $salt=fooі $password=barі $hash=3858f62230ac3c915f300c664312c63f. Тепер хтось із райдужною таблицею міг би змінити хеш і придумати вхідний "foobar". Потім вони могли спробувати всі комбінації паролів (f, fo, foo, ... oobar, obar, bar, ar, ar). Може знадобитися ще кілька мілісекунд, щоб отримати пароль, але не дуже багато іншого.

Інше використання, яке я бачив, є в моїй системі Linux. У тіні / etc / shadow хешовані паролі фактично зберігаються з сіллю. Наприклад, сіль «Foo» і паролем «бар» буде хеш для цього: $1$foo$te5SBM.7C25fFDu6bIRbX1. Якщо хакер якимось чином вдався до цього файлу, я не бачу, для чого служить сіль, оскільки, як te5SBM.7C25fFDu6bIRbXвідомо, зворотний хеш містить "foo".

Дякуємо за будь-яке світло, про який може пролитись кожен.

EDIT : Дякую за допомогу. Підсумовуючи те, що я розумію, сіль робить хешований пароль складнішим, таким чином, значно менше шансів існувати у попередньо розрахованій веселковій таблиці. Що раніше я неправильно зрозумів, це те, що я припускав, що райдужний стіл існує для ВСІХ хешей.

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

Загальнодоступна сіль робить дві речі: робить більш трудомістким зламати великий список паролів і робить нездійсненним використання веселкового столу.

Щоб зрозуміти перший, уявіть єдиний файл паролів, який містить сотні імен користувачів та паролів. Без солі я міг обчислити "md5 (спроба [0])", а потім просканувати файл, щоб побачити, чи з’являється цей хеш де-небудь. Якщо солі присутні, то я повинен обчислити "md5 (сіль [a]. Спроба [0])", порівняти з записом A, потім "md5 (сіль [b]. Спроба [0])" ", порівняти з записом B і т. д. Зараз у мене є nбагато разів роботи, де nкількість файлів імен і паролів, що містяться у файлі.

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

Але якщо файл пароля засолений, то таблиця веселки повинна містити попередньо хешеваний "сіль. Пароль". Якщо сіль досить випадкова, це дуже малоймовірно. Можливо, у моєму списку часто використовуваних попередньо хешованих паролів (таблиця веселки) у мене будуть такі речі, як "привіт" і "foobar" і "qwerty", але я не збираюся мати такі речі, як "jX95psDZhello" або Попередньо обчислюється "LPgB0sdgxfoobar" або "dZVUABJtqwerty". Це зробило б веселковий стіл непомірно великим.

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

Інші відповіді, схоже, не стосуються ваших непорозумінь у цій темі, тому ось що:

Дві різні способи використання солі

Я бачив багато навчальних посібників, які пропонують використовувати сіль як наступне:

$hash = md5($salt.$password)

[...]

Інше використання, яке я бачив, є в моїй системі Linux. У тіні / etc / shadow хешовані паролі фактично зберігаються з сіллю.

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

Захищеність хешу

Тепер хтось із райдужною таблицею міг би змінити хеш і придумати вхідний "foobar".

[...]

оскільки, як відомо, зворотний хеш te5SBM.7C25fFDu6bIRbX містить "foo".

Повернути хеш як такий (неможливо, принаймні). Хеш "foo" і хеш "salfoo" не мають нічого спільного. Зміна навіть одного біта на вході криптографічної хеш-функції повинна повністю змінити вихід.

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

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

Якість солі

Але скажи $salt=foo

"foo" був би надзвичайно поганим вибором солі. Зазвичай ви використовуєте випадкове значення, закодоване в ASCII.

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

Атака

Якщо хакер якимось чином вдався до цього файлу, я не бачу, якій цілі служить сіль,

Завжди потрібна атака райдужної таблиці /etc/passwd(або яка б база даних паролів не використовувалася), інакше як би ви порівняли хеші таблиці веселки з хешами фактичних паролів?

Щодо мети: скажімо, зловмисник хоче створити таблицю веселки для 100 000 загальновживаних англійських слів та типових паролів (подумайте "секретно"). Без солі їй доведеться нарахувати 100 000 хешей. Навіть з традиційною сіткою UNIX, що складається з 2 символів (кожен із них є 64 варіантами [a–zA–Z0–9./]) : їй доведеться обчислити та зберігати 4 096 000 000 хешів ... цілком вдосконалення.

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

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

Ще одне чудове запитання, з багатьма дуже продуманими відповідями - +1 ТАК!

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

Чому це важливо?

Уявіть базу даних паролів у великій компанії з програмного забезпечення на північному заході США. Припустимо, він містить 30 000 записів, з яких 500 мають екран блюз-екрана . Припустимо, що хакер вдається отримати цей пароль, скажімо, прочитавши його в електронному листі від користувача до ІТ-відділу. Якщо паролі несолоні, хакер може знайти хешоване значення в базі даних, а потім просто узгодити його, щоб отримати доступ до інших 499 акаунтів.

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

Я шукав хороший метод застосування солей і знайшов цю чудову статтю з кодом зразка:

http://crackstation.net/hashing-security.htm

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

Щоб зберегти пароль:

• Утворіть довгу випадкову сіль за допомогою CSPRNG.
• Додайте сіль до пароля і хешуйте її за допомогою стандартної криптографічної хеш-функції, наприклад, SHA256.
• Збережіть і сіль, і хеш у записі бази даних користувача.

Щоб підтвердити пароль:

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

Причина, по якій сіль може призвести до невдачі нападу веселкового столу, полягає в тому, що для n-шматочків солі стіл веселки повинен бути в 2 ^ n рази більшим за розмір столу без солі.

Ваш приклад використання "foo" як солі може зробити райдужний стіл у 16 ​​мільйонів разів більшим.

Враховуючи приклад Карла з 128-бітною сіллю, це робить таблицю в 2 ^ 128 рази більшою - тепер це велика - або кажучи іншим способом, за скільки часу хтось має такий великий портативний накопичувач?

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

Такі атаки неефективні у випадку, коли паролі містять набагато більше символів і не відповідають загальним форматам на основі слів. Користувач із сильним паролем, з якого слід почати, не буде вразливим до цього стилю атаки. На жаль, багато людей не вибирають хороших паролів. Але є компроміс, ви можете вдосконалити пароль користувача, додавши до нього випадкові сміття. Тож замість "hunter2" їх пароль міг би стати ефективно "hunter2908! Fld2R75 {R7 /; 508PEzoz ^ U430", що є набагато сильнішим паролем. Однак, оскільки вам зараз доведеться зберігати цей додатковий компонент пароля, це знижує ефективність більш міцного складеного пароля. Як виявляється, така схема все ще є корисною, оскільки тепер кожен пароль, навіть слабкий, більше не вразливі до тієї ж попередньо обчисленої хеш-таблиці веселки. Натомість, кожен хеш-запис пароля вразливий лише до унікальної хеш-таблиці.

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

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

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

Одна мета засолювання - перемогти попередньо обчислені хеш-таблиці. Якщо у когось є список мільйонів попередньо обчислених хешей, вони не зможуть шукати $ 1 $ foo $ te5SBM.7C25fFDu6bIRbX1 у своїй таблиці, хоча вони знають хеш і сіль. Їм все одно доведеться жорстоко змусити це.

Ще одна мета, як згадує Карл S, - зробити грубішим форсування списку хешей дорожче. (дайте їм всі різні солі)

Обидві ці цілі все ще досягнуті, навіть якщо солі є загальнодоступними.

Наскільки мені відомо, сіль призначена для посилення атак на словники.

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

Тож хакер міг би використати це на свою користь замість того, щоб застосовувати лише грубу силу. Він не буде шукати такі паролі, як aaa, aab, aac ... а натомість використовувати слова та загальні паролі (як, наприклад, лорд кілець імена!;))

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

Сподіваюся, що це допомагає!

Я припускаю, що ви використовуєте функцію PHP --- md5 () та змінні $, що передують ---, тоді ви можете спробувати переглянути цю статтю Shadow Password HOWTO Особливо 11-й абзац.

Крім того, ви боїтеся використовувати алгоритми дайвінгу повідомлень, ви можете спробувати реальні алгоритми шифрування, такі як ті, які надає модуль mcrypt , або більш сильні алгоритми перебору повідомлень, такі, які надають модуль mhash (sha1, sha256 і інші).

Я думаю, що більш сильний алгоритм перебору повідомлень є необхідним. Відомо, що у MD5 та SHA1 виникають проблеми зіткнення.