Солити свій пароль: кращі практики?

Мені завжди було цікаво ... Що краще, коли солить пароль для хешування: префікса чи постфікса? Чому? Або це має значення, поки ви солите?

Для пояснення: Ми всі (сподіваємось) до цього часу знаємо, що нам слід посолити пароль, перш ніж ми його хешимо для зберігання в базі даних [ Редагувати: Таким чином, ви можете уникнути таких речей, як те, що відбулося нещодавно з Джеффом Етвудом ]. Зазвичай це робиться шляхом об'єднання солі з паролем перед передачею через алгоритм хешування. Але приклади різні ... Деякі приклади солі перед паролем. Деякі приклади додають сіль після пароля. Я навіть бачив деяких, які намагаються покласти сіль в середину.

То який кращий метод, і чому? Чи існує метод, який зменшує ймовірність хеш-зіткнення? Мій Google не знайшов гідного аналізу з цього приводу.

Редагувати: Чудові відповіді, люди! Вибачте, що міг вибрати лише одну відповідь. :)

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

Слід розглянути ці три речі:

1. Сіль має бути різною для кожного пароля, який ви зберігаєте. (Це досить поширене непорозуміння.)
2. Використовуйте криптографічно захищений генератор випадкових чисел.
3. Вибирайте досить довгу сіль. Подумайте про проблему з днем ​​народження.

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

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

Той факт, що саме там, має перемогти веселкові столи.

Модель загрози, на яку я натякав, буде сценарієм, коли противник може додавати до пароля райдужні таблиці звичайних солей. (Скажіть АНБ) Ви здогадуєтесь, що вони або додали його, або попередньо, але не обидва. Це нерозумно, і це погана здогадка.

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

Як я вже сказав. Це семантика. Виберіть іншу сіль для пароля, довгу сіль та додайте до неї непарні символи, як символи та коди ASCII: © ¤¡

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

HMAC - кращий підхід, але навіть тоді, якщо ви використовуєте щось на зразок SHA-1, ви вже вибрали алгоритм, непридатний для хешування паролів через його дизайн для швидкості. Використовуйте щось на кшталт bcrypt або, можливо, scrypt, і виймайте проблему з ваших рук цілком.

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

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

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

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

Перш за все, термін "райдужний стіл" послідовно вживається. Стіл «веселка» - це просто особливий вид таблиці пошуку, який дозволяє стиснути певний вид даних на клавішах. Торгуючи обчисленнями простору, таблицю пошуку, яка займе 1000 ТБ, можна стиснути в тисячу разів, щоб її можна було зберігати на меншому накопичувачі.

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

@ onebyone.livejournal.com:

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

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

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

Більше того, алгоритми хешування паролів, такі як PBKDF, складають свою хеш-функцію кілька разів (рекомендується повторити PBKDF-2 мінімум 1000 разів, кожна ітерація, застосовуючи SHA-1 двічі), що робить цю атаку вдвічі непрактичною.

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

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