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

128

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

encryption  hash  salt 
— Девід
джерело
10
Я не маю рекомендацій щодо довжини солі, але відповіді, що з’являються тут, містять багато поганої інформації. Ваша сіль обов'язково повинна бути: - бути випадковою - бути таємною (не одне значення зберігається у вашому зображенні програми чи файлі конфігурації). Сіль не є криптографічним секретом, тому зберігати її у своєму столі не проблема. Єдина мета солі - гарантувати, що коли різні екземпляри одного і того ж предмета хешируються (або шифруються), ви отримуєте інший результат.
— Майкл Берр
2
Для тих, хто не знає, що таке сіль: <a href=" en.wikipedia.org/wiki/Salt_(cryptography)"> Сіль (криптографія) </a> у Вікіпедії
— Девід Коелл
1
Або якщо існує оптимальне відношення довжини солі до довжини виходу хешу? 8-байтної солі може бути достатньо для HMAC-SHA-256, але може не бути HMAC-SHA-512.
— Кренд Кінг,
1
Криптографічно випадкова сіль такого ж розміру, що і вихід функції хешування, означає, що атака "спробувати всі можливі солі" (плюс словник пароля) вимагає стільки ж зусиль, скільки "спроба всіх можливих хеш-результатів" - що є стандартною грубою силою . Більш коротка сіль означає, що у вас може бути словник солі плюс словник паролів як груба атака.
— Річард Ґадсден
-1 Зізнається, навіть не намагається відповісти на запитання.
— користувач359996

Відповіді:

70

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

Солі потрібно лише бути досить довгими, щоб сіль кожного користувача була унікальною. Випадкові 64-бітні солі навряд чи повторяться навіть з мільярдом зареєстрованих користувачів, тому це повинно бути добре. Одноразово повторювана сіль - відносно незначна проблема безпеки, вона дозволяє зловмиснику шукати два акаунти одночасно, але в сукупності не прискорить пошук у всій базі даних. Навіть 32-бітні солі прийнятні для більшості цілей, це в гіршому випадку прискорить пошук нападника приблизно на 58%. Вартість збільшення солі понад 64 біт не висока, але для цього немає жодних причин безпеки.

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

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

— SecurityJoe
джерело
16
Користь солей є непередбачуваною. Передбачувану сіль можна передбачити і використовувати в атаці хеш-таблиці. Наприклад, якщо ваша сіль - це лише ідентифікатор користувача, тоді таблиця хеш-простого простого альфа-файлу, яка є достатньо довгою, буде включати не просто всі паролі, але всі комбінації імені користувача + паролі.
— Річард Ґадсден
6
Зауважте, що стосовно останнього пункту, якщо ви використовуєте сіль для всього веб-сайту, це має бути саме так: на всьому сайті. Не в масштабах програми, тобто кожен новий встановлений вами додаток повинен генерувати нову сіль для всіх сайтів. Наприклад, якщо Windows використовувала ту саму сіль у кожній базі даних автентифікації Windows, тоді варто було б створити таблицю веселки для цієї солі, але якщо кожна установка Windows генерувала нову сіль, вона не буде.
— Річард Ґадсден
5
Справа не в тому, що сіль потрібно важко здогадатися. Зловмисникові не потрібно вгадувати сіль: кожен, хто має доступ до хешу, вже має сіль. Проблема полягає в тому, що якщо ваші солі дуже поширені (наприклад, імена користувачів), вони можуть бути такими ж, як і на інших сайтах, і в цей момент для зловмисника потрібен набагато менший набір райдужних таблиць, щоб зробити атаки можливими. Саме тому згадується ідея солі на місці, щоб уникнути подібного зіткнення з іншими сайтами.
— Nate CK
3
Коротка примітка: Якщо використовувати імена користувачів як сіль, це може бути проблемою, якщо змінити імена користувачів. Практично, (незважаючи на те, що сказано в проектних документах замовника), я виявив, що користувачі часто хочуть змінювати імена користувачів.
— SilentSteel
5
@ NateC-K, Ідея солі на сайті, про яку ви говорите, називається перець.
— Печер'є
35

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

Звичайно, слід дотримуватися належної криптографічної допомоги для створення дійсно випадкової солі.

— Девід Шмітт
джерело
6
Характер дещо погано визначений. Ви повинні сказати байт .
— CodesInChaos
10
@CodesInChaos Я вважаю, ви маєте на увазі октет ;-)
— користувач2864740
1
Привіт! Здається, що стаття вікіпедії змінена - можливо, вам слід посилатися на en.wikipedia.org/wiki/PBKDF2 чи щось?
— Борис Треухов
5
— Борис Треухов
24

Редагувати: моя нижченаведена відповідь відповідає на запитання як відповідь, але "справжня" відповідь: просто використовуйте bcrypt , scrypt або Argon2 . Якщо ви задаєте подібні запитання, ви майже напевно використовуєте інструменти на занадто низькому рівні.

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

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

— Стівен Тусет
джерело
10
Це не така вже й велика справа; користувач ледь помітить різницю між хешем мілісекунди та півтори секунди, плюс хешування паролів насправді повинно зайняти більше часу, щоб уповільнити грубі сили атаки - хоча типові три удари, зафіксовані на 15 хвилин, краще. Ви "витрачаєте" цикли процесора для цього? Так, як би там не було. Процесор витрачає більше часу в режимі очікування, ніж на більшості веб-сайтів, так чи інакше це має значення? Якщо у вас виникли проблеми з продуктивністю, масштабуйте їх.
— Рандольфо
14
Солі захищають від веселкових столів. 512-бітна сіль з 256-бітним хешем все ще призведе до лише 256 біт ентропії в остаточному паролі.
— Стівен Тусет
8
Повільне хешування - це особливість, а не помилка.
— outis
7
Якщо у вас є 3-бітний хеш, ваша 9999-бітна сіль як і раніше буде лише хешувати до 3 можливих біт ентропії. Таблиця веселки повинна знаходити лише три солі для кожного пароля, що призводить до різного виходу, який є постійним мультиплікативним фактором і, таким чином, відкидається від великого O.
— Стівен Тузет
2
.................................................. .................................... конкретна система. Призначення солей - зупинити попередні атаки, щоб хеші не могли шукати та негайно перетворити на відкритий текст . З 9999-бітною сіллю ваш пароль залишається таємницею , тоді як з 3-бітною сіллю ваш пароль тепер відомий усьому світу (і вони можуть використовувати його для входу в інші ваші облікові записи, оскільки багато людей часто використовують паролі). Мені здається забавним, що 5 людей тут відкликали ваш коментар через слово "ентропія" в ньому.
— Печер'є
7

Вікіпедія :

Методи криптовалют і криптовалют SHA2 - використовувані в Linux, BSD Unixes і Solaris - мають солі 128 біт. Ці більші значення солі роблять передбачувані атаки майже будь-якої довжини пароля неможливими для цих систем в осяжному майбутньому.

128-бітної (16-байтної) солі буде достатньо. Ви можете представити це як послідовність 128 / 4 = 32шістнадцяткових цифр.

— Андрій Немченко
джерело
Мені здається, що приклад використання інших захищених систем є чудовим прикладом того, що найкраща практика.
— cjbarth
1
@ mklement0 Спасибі, я оновив відповідь.
— Андрій Немченко
2

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

Наприклад, якщо ви збираєтесь використовувати SHA-512, використовуйте 256 бітну сіль, оскільки захист, що надається SHA-512, становить 256 біт.

— Роберто Мартеллоні
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.