Де ви зберігаєте свої соляні струни?

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

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

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

Чи є якісь рекомендовані рішення для цього?

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

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

Я забезпечу трохи інший погляд на це.

Я завжди зберігаю сіль, змішану з хешем соленого пароля.

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

Моє обґрунтування такого підходу:

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

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

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

Висновок до цього ..

1) Ніколи не зберігайте дані, які використовує ваша програма аутентифікації, у точно визначеному вигляді.

2) По можливості зберігайте таємницю логіки аутентифікації для додаткової безпеки.

Ідіть на крок далі ..

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

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

Наприклад, ви генеруєте випадкову сіль у 512 байт. Ви додасте сіль до свого пароля і отримаєте хеш SHA-512 вашого засоленого пароля. Ви також генеруєте випадкове ціле число 200. Потім ви зберігаєте перші 200 байт солі, а потім хеш солоного пароля, а потім решту солі.

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

Плюси цього підходу:

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

Мінуси цього підходу:

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

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

Цей підхід може бути реалізований різними способами і може бути ще більш безпечним, використовуючи солі змінної ширини та / або солі паролів.

Часто вони готуються до хешу і зберігаються в одному полі.

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

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

На основі розробки книги веб-додатків ASP.NET MVC 4 Вільяма Пенберті:

1. Отримання доступу до солей, що зберігаються в окремій базі даних, вимагає, щоб хакери зламали дві різні бази даних, щоб отримати доступ до солі та засоленому паролю. Збереження їх у тій самій таблиці, що і пароль, або навіть іншій таблиці тієї ж бази даних, означатиме, що коли хакери отримають доступ до бази даних, вони матимуть доступ як до солі, так і до хешу пароля. Оскільки безпека включає процес зробити злому в системі занадто дорогим або трудомістким, щоб того вартувати, подвоєння кількості доступу, який повинен отримати хакер, повинно зробити систему більш захищеною.
2. Простота використання є основною причиною збереження солей у тій самій базі даних, що і хешовані паролі. Вам не потрібно було б забезпечувати, щоб дві бази даних були доступні одночасно та завжди синхронізовані. Перевага наявності солі мінімальна, якщо кожен користувач має рандомізовану сіль, оскільки, хоча це може полегшити відкриття пароля, кількість сили, необхідна для зламування паролів загальної системи, буде високою. На такому рівні обговорення очікується саме таке: захистити паролі. Якщо хакери придбали копію бази даних, дані вашої програми вже порушені. На даний момент проблема полягає в зменшенні ризиків користувачів через потенціал спільних паролів.
3. Потреба у підтримці двох окремих пов'язаних баз даних є великою. Зрозуміло, це додає сприйняття безпеки, але єдина перевага, яку вона дає, - це те, що він захищає пароль, єдиний елемент даних. Якби кожне поле в базі даних було зашифровано індивідуально, і для цього була використана ця сама сіль, було б більше сенсу зберігати її окремо від даних, оскільки підвищена основна безпека вашої системи.

Сенс солі полягає в тому, щоб зробити всі веселкові столики марними і вимагати створення нового набору з них. Щоб відгадати рядок, потрібно зробити стільки ж часу, скільки зробити веселковий стіл. Наприклад, хеш SHA-256 "пароль" є 5e88 4898 da28 0471 51d0 e56f 8dc6 2927 7360 3d0d 6aab bdd6 2a11 ef72 1d15 42d8. Після додавання солі, такої як "badpassword", новий рядок, який слід хешувати, є "passwordbadpasspass", який завдяки лавинному ефекту різко змінює вихід, на 457b f8b5 37f1 802e f9c8 2e46 b8d3 f8b5 721b 7cbb d485 f0bb e523 bfbe 73e6 58d6.

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