Чи безпечний SHA-1 для зберігання паролів?

Висновок: SHA-1 настільки ж безпечний, як будь-що проти попередніх атак, однак його легко обчислити, а значить, простіше встановити атаку грубої сили чи словника. (Це ж стосується таких наступників, як SHA-256.) Залежно від обставин, кращим вибором може стати хеш-функція, розрахована на обчислювальну дорогу (наприклад, bcrypt).

Деякі люди кидають багато зауважень на кшталт "SHA-1 зламаний" дуже багато, тому я намагаюся зрозуміти, що саме це означає. Припустимо, у мене є база даних хешей для паролів SHA-1, а зловмисник із найсучаснішим алгоритмом розбиття SHA-1 і ботнет із 100 000 машинами отримують доступ до нього. (Якщо мати контроль над домашніми комп'ютерами в 100 тисяч, це означає, що вони можуть робити близько 10 ^ 15 операцій в секунду.) Скільки часу їм знадобиться

1. дізнатися пароль будь-якого користувача?
2. дізнатися пароль заданого користувача?
3. дізнатися пароль усіх користувачів?
4. знайти спосіб увійти як один із користувачів?
5. знайти спосіб увійти як конкретний користувач?

Як це зміниться, якщо паролі засолені? Чи має значення спосіб засолювання (префікс, постфікс, або те, чи щось складніше, як xor-ing)?

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

• Якщо солі немає, райдужна атака негайно знайде всі паролі (крім надзвичайно довгих).
• Якщо є досить довга випадкова сіль, найефективнішим способом з’ясувати паролі є жорстока сила або атака словника. Ні зіткнення, ні попередні атаки не допомагають з’ясувати фактичний пароль, тому криптографічні атаки проти SHA-1 тут не допомагають. Навіть не важливо, який алгоритм використовується - можна навіть використовувати MD5 або MD4, і паролі були б настільки ж безпечними (є невелика різниця, оскільки обчислення хеша SHA-1 проходить повільніше).
• Щоб оцінити, наскільки безпечним є «так само безпечно», припустимо, що для одного запуску sha1 потрібно 1000 операцій, а паролі містять великі, малі та малі цифри (тобто 60 символів). Це означає, що зловмисник може протестувати 10 ¹⁵ * 60 * 60 * 24/1000 ~ = 10 ¹⁷ потенційних паролів на день. Для грубої атаки це означатиме тестування всіх паролів до 9 символів за 3 години, до 10 символів на тиждень, до 11 символів на рік. (На кожен додатковий символ потрібно 60 разів більше.) Атака словника набагато, набагато швидша (навіть зловмисник із одним комп’ютером міг би витягнути його за години), але знаходить лише слабкі паролі.
• Щоб увійти як користувач, зловмиснику не потрібно з’ясовувати точний пароль; достатньо знайти рядок, що призводить до того ж хешу. Це називається першою попередньою атакою. Наскільки я міг знайти, жодних попередніх атак проти SHA-1 немає. (Напад грубої сили зайняв би 2 ¹⁶⁰ операцій, а це означає, що нашому теоретичному зловмиснику знадобиться 10 ³⁰ років, щоб його зняти. Обмеження теоретичної можливості - це близько 2 ⁶⁰ операцій, при яких напад триватиме кілька років.) Є попередні атаки проти скорочених версій SHA-1 з незначним ефектом (для зменшеного SHA-1, який використовує 44 кроки замість 80, час нападу зменшується з 2 ¹⁶⁰ операцій до 2 ¹⁵⁷). Є атаки проти зіткнення проти SHA-1, які повністю знаходяться в теоретичній можливості ( найкраще, що я знайшов, приводить час з 2 ⁸⁰ до 2 ⁵² ), але вони марні проти хешей паролів, навіть без засолювання.

Коротше кажучи, зберігання паролів із SHA-1 видається абсолютно безпечним. Я щось пропустив?

Оновлення: Марсело вказав на статтю, в якій згадується другий попередній напад у 2 ¹⁰⁶ операціях . ( Редагувати: Як пояснює Томас , ця атака - це гіпотетична конструкція, яка не застосовується до сценаріїв реального життя.) Я все ще не бачу, наскільки це загрожує небезпекою для використання SHA-1 як ключової функції деривації. Чи є в цілому вагомі причини думати, що атака зіткнення або друга атака попереднього зображення можуть врешті-решт перетворитись у першу попередню атаку?

Коротка відповідь на ваше запитання: SHA-1 максимально безпечний. MD5 теж буде добре, навіть MD4; але це може змусити деяких інвесторів нервувати. Для зв’язків з громадськістю найкраще використовувати "кращу" хеш-функцію, наприклад, SHA-256, навіть якщо скоротити її вихід до 160 або 128 біт (щоб заощадити на вартості зберігання). Деякі з кандидатів SHA-3 в раунд-2 здаються швидшими, ніж SHA-1, але, мабуть, "більш безпечні"; але вони ще трохи нові, тому дотримуватися SHA-256 або SHA-512 було б зараз більш безпечним маршрутом. Це дозволило б вам виглядати професійно і обережно, що добре.

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

Про відомі атаки:

Відомі напади на MD4, MD5 та SHA-1 стосуються зіткнень, які не впливають на попередній опір. Було показано, що MD4 має кілька слабких місць, які можна (лише теоретично) використовувати при спробі зламати HMAC / MD4, але це не стосується вашої проблеми. 2 ¹⁰⁶ другого прообразу атака в роботі Kesley і Шнайер є родовим Компроміс , який поширюється тільки на дуже довгих входів (2 ⁶⁰ байт, що в мільйон терабайт - повідомлення , як 106 + 60 перевищує 160, то де ви бачите , що компроміс не має в цьому нічого магічного).

У решті цього повідомлення передбачається, що використовувана вами хеш-функція (наприклад, SHA-1) - це "чорна скринька", яка не має спеціальних властивостей, якими може скористатися зловмисник. Це те, що ви маєте зараз, навіть із "зламаними" хеш-функціями MD5 та SHA-1.

Про веселкові столи:

"Атака веселки" - це фактично розподіл витрат на словник або грубу силу. Це похідне від компромісу пам'яті часу, вперше описаного Hellman в 1980 році. Припустимо, що у вас є N можливих паролів (це розмір вашого словника, або 2 ^n, якщо ви вважаєте, що груба форсування хеш-функції з виходом n біт), відбувається атака обміну часом, в якій ви попередньо обчислюєте N хешованих паролів і зберігаєте їх у великій таблиці. Якщо ви сортуєте хеш-виходи, ви можете отримати свій пароль в одному пошуку. Стіл веселки розумний спосіб зберегти цю таблицю з великим кількістю зменшеному простору. Ви зберігаєте лише N / t хешованих паролів, і ви зламаєте паролі за допомогою O (t ² ) пошук. Таблиці веселки дозволяють практично обробляти попередньо обчислені таблиці набагато більше, ніж те, що ви реально можете зберігати.

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

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

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

Про солі:

Солі - це спосіб перемогти попередні обчислення. У вищеописаному описі сіль повертає зловмисника до етапу 1: засолювання запобігає зловмиснику розподілити вартість O ( N ) між кількома атакованими паролями. Попередньо обчислені таблиці, такі форми веселок fortiori , вже неможливі.

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

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

Також засолювання добре підходить для зв’язків з громадськістю.

Про вартість SHA-1:

Елементарна вартість SHA-1 - це хешування блоку на 64 байти. Ось так працює SHA-1: дані додаються, а потім розбиваються на 64-байтові блоки. Вартість обробки одного блоку становить близько 500 тактових циклів в системі Intel Core2, і це для одного ядра. MD5 та MD4 швидші, нараховують приблизно 400 та 250 циклів відповідно. Не забувайте, що більшість сучасних процесорів мають кілька ядер, тому множте відповідно.

Деякі схеми засолювання призначають величезні солі; наприклад, те, що входить в хеш-функцію - це фактично 40000 послідовних копій однієї 128-бітної солі з наступним самим паролем. Це робить хешування паролів дорожчим (на 10000 з мого прикладу), як для законного користувача, так і для зловмисника. Чи буде це гарна ідея, залежить від налаштування. Для входу в настільну систему це добре: користувач навіть не помітить, що для хешування свого пароля потрібно було 10 мс замість 1 мкс; але вартість для зловмисника зросла дуже помітним фактором 10000. На спільних серверах з тисячами клієнтів в секунду сукупна вартість може стати непосильною. Концептуально підняття планки на той самий фактор для законного користувача та зловмисника не є в кінцевому рахунку доброю безпекою; але це може бути корисною ідеєю в деяких конкретних ситуаціях.

Про онлайн-атаки:

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

Зазвичай для безпеки паролів окупається набагато більше, щоб організувати систему для заборони зловмиснику створювати офлайн-атаку. Ось що роблять системи Unix: хешовані паролі, які раніше були у світі, читає /etc/passwordфайл, тепер у /etc/shadowфайлі, захищеному від доступу для читання, за винятком кількох привілейованих програм. Припущення тут полягає в тому, що якщо зловмисник може читати /etc/shadow, він, ймовірно, має достатній контроль над системою, що йому справді вже не потрібні паролі ...

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

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

Коротше кажучи, вам слід використовувати лише найкращі інструменти для роботи. А SHA-1 дуже далеко не відповідає рівню техніки.

Для подальшого читання:

• /crypto/400/why-cant-one-implement-bcrypt-in-cuda
• http://codahale.com/how-to-safely-store-a-password/
• http://www.codinghorror.com/blog/2012/04/speed-hashing.html
• /security/4781/do-any-security-experts-recommend-bcrypt-for-password-storage/6415#6415

Ваш опис звучить точно для сучасного стану техніки.

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

Однак в ідеалі слід використовувати наявний примітив для зберігання паролів, наприклад описаний тут .

SHA1 - це дайджест повідомлень , він ніколи не був мав на увазі функцію хешування паролів (або виведення ключа). (Хоча це може бути використаний будівельний блок для KDF, наприклад, у PBKDF2 з HMAC-SHA1.)

Функція хешування паролів повинна захищати від атак на словники та таблиці веселок. Для досягнення цієї мети було розроблено кілька алгоритмів.

Наразі найкращим вибором є, мабуть, Argon2 . Ця сім'я функцій збору паролів перемогла у конкурсі злучення паролів у 2015 році.

Якщо Argon2 недоступний, єдиною іншою стандартизованою функцією хешування паролів або виведенням ключа є PBKDF2 , що є старовинним стандартом NIST. Інші варіанти, якщо використовувати стандарт не потрібно, включають bcrypt та scrypt .

У Вікіпедії є сторінки для цих функцій:

• https://en.wikipedia.org/wiki/Argon2
• https://en.wikipedia.org/wiki/Bcrypt
• https://en.wikipedia.org/wiki/Scrypt
• https://en.wikipedia.org/wiki/PBKDF2

У SHA-1 виявлено серйозні вразливості, які роблять пошук набагато швидшим, ніж груба сила. Це все ще значною мірою непереборно, але це, як очікується, не так вже й довше; параноїдні програмісти віддають перевагу чомусь із родини SHA-2.

З цієї статті щодо початкового результату 2005 року:

"Настав час ходити, але не бігати до пожежі. Ви не бачите диму, але пожежна сигналізація вимкнула".

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

Коротше кажучи, SHA-1 є безпечним прямо зараз, і, ймовірно, буде на якийсь час, але криптовалюта незручна з прогнозом.

З лютого 2017 року SHA-1 більше не слід вважати безпечним. Google повідомив про успіх у атаках зіткнення проти повного, не скороченого раунду SHA-1 ( посилання на звіт ). Для оголошення Google натисніть тут .

Редагувати: Як вказували інші, паролі не вразливі для атак хеш-зіткнень. Однак як загальне керівництво я не вибирав SHA-1 для застосувань, пов'язаних із безпекою. Є кращі альтернативи там.

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

Ось що говорить NIST :

Наразі результати, представлені на SHA-1, не ставлять під сумнів її безпеку. Однак, завдяки прогресу технологій, NIST планує припинити SHA-1 на користь більшого і сильного хеш-функцій (SHA-224, SHA-256, SHA-384 і SHA-512) до 2010 року.