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

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

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

Після роздумів про це я просто не бачу справжнього підвищення безпеки від такого підходу. Зміна солі з акаунта на рахунок, все ще робить надзвичайно важким для когось спробу жорстокого застосування алгоритму хешування, навіть якщо зловмисник знав, як швидко визначити, що це за кожен рахунок. Це відбувається з припущенням, що паролі достатньо надійні. (Очевидно, що знайти правильний хеш для набору паролів, де вони всі дві цифри, значно простіше, ніж знайти правильний хеш паролів, який становить 8 цифр). Чи я неправильна у своїй логіці, чи є щось, чого мені не вистачає?

РЕДАКЦІЯ: Гаразд, ось ось причина, чому я думаю, що насправді суперечить шифрувати сіль. (леме знаю, чи я на правильному шляху).

Для наступного пояснення ми припустимо, що паролі завжди мають 8 символів, а сіль - 5, а всі паролі складаються з малих літер (це просто полегшує математику).

Наявність різної солі для кожного запису означає, що я не можу використовувати ту саму таблицю веселки (насправді технічно я міг би, якби мав достатній розмір, але давайте ігнорувати це на даний момент). Це справжній ключ до солі від того, що я розумію, тому що для того, щоб зламати кожен рахунок, я повинен винаходити колесо, так би мовити для кожного. Тепер, якщо я знаю, як застосувати правильну сіль до пароля, щоб генерувати хеш, я б це зробив, оскільки сіль насправді просто збільшує довжину / складність хеш-фрази. Таким чином, я б скоротив кількість можливих комбінацій, які мені потрібно створити, щоб "знати", у мене є пароль + сіль від 13 ^ 26 до 8 ^ 26, тому що я знаю, що таке сіль. Тепер це полегшує, але все-таки дуже важко.

Тож на шифрування солі. Якщо я знаю, що сіль зашифрована, я б не спробував розшифрувати (якщо припустити, що знаю, що у неї достатній рівень шифрування) її спершу. Я б ігнорував це. Замість того, щоб намагатися розібрати, як розшифрувати, повернувшись до попереднього прикладу, я просто створив би більшу таблицю веселки, що містить усі клавіші для 13 ^ 26. Незнання солі, безумовно, сповільнить мене, але я не думаю, що це додасть монументальної задачі спершу спробувати зламати шифрування солі. Тому я не думаю, що цього варто. Думки?

Ось посилання, що описує, як довго триматимуться паролі під жорстокою атакою: http://www.lockdown.co.uk/?pg=combi

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

Ховати сіль не потрібно.

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

З попередньої моєї відповіді :

Сіль допомагає запобігати попередньо обчисленим атакам словника.

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

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

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

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

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

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

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

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

... щось на зразок імені користувача або номера телефону, щоб солити хеш. ...

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

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

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

Прихована сіль - це вже не сіль. Це перець. Він має своє використання. Він відрізняється від солі.

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

Для отримання додаткової інформації про перець перевірте тут .

Дивіться також hmac .

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

Розглянемо наступну таблицю

UserId  UserName,   Password
     1  Fred       Hash1 =  Sha(Salt1+Password1)    
     2  Ted        Hash2 =  Sha(Salt2+Password2)    

Випадок 1, коли сіль 1 є такою ж, як сіль2 Якщо Hash2 замінити Hash1, користувач 2 може ввійти з паролем користувача 1

Випадок 2, коли сіль 1 не та сама сіль2 Якщо Hash2 замінено Hash1, то user2 не може ввійти з паролем користувачів 1.

Є дві методики з різними цілями:

• "Сіль" використовується для створення двох інакше рівних паролів, які шифруються по-різному. Таким чином, зловмисник не може ефективно використовувати атаку словника на весь список зашифрованих паролів.

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

Я схильний ховати сіль. Я використовую 10 шматочків солі, попередньо передбавляючи випадкове число від 1 до 1024 до початку пароля. Порівнюючи пароль, який користувач ввів із хешем, я перебираю цикл від 1 до 1024 і намагаюсь усі можливі значення солі, поки не знайду відповідність. Це займає менше 1/10 секунди. У мене з’явилася ідея зробити це саме з PHP password_hash та password_verify . У моєму прикладі "вартість" - 10 за 10 шматочків солі. Або з того, що сказав інший користувач, прихована «сіль» називається «перець». Сіль не зашифрована в базі даних. Це грубо витіснено. Це зробить таблицю веселки необхідною для повернення хешу в 1000 разів більше. Я використовую sha256, тому що це швидко, але все ще вважається безпечним.

Дійсно, це залежить від того, який тип атаки ви намагаєтеся захистити свої дані.

Мета унікальної солі для кожного пароля - запобігти атаці словника на всю базу даних паролів.

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

Marianne2ae85fb5d

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