Сіль (криптографія)

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

Приклад створення хешу з сіллю на PHP:

  $password = 'password';            // Безпосередньо пароль
  $hash1 = md5($password);           // Хешуємо первісний пароль
  $salt = 'sflprt49fhi2';            // Сіль
  $saltedHash = md5($hash1 . $salt); // Додаємо до гешу первісного паролю сіль, і це об'єднання знов хешуємо

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

Приклад використання функції crypt на мові PHP, зберігання гешу пароля та його солі:

$salt = rand();
$hashed_password = crypt('password', $salt);  // crypt генерує сіль і хешує, використовуючи алгоритм за умовчанням
  // зберігаємо $hashed_password та $salt

Перевірка вказаного пароля по його гешу та солі:

if ( $hashed_password == crypt($user_input, $salt) ) {
   echo "Пароль правильний!";
}

Приклад результатів застосування солі із хешуванням SHA256.

Для початку у нас є дані Користувачів з певними іменами та Паролями:

Код додає сіль до паролю, створюючи більш унікальний хеш:

Якщо значення паролів для різних користувачів однакові — хеш рядки для різних користувачів теж є однаковими:

При несанкціонованому доступі до бази даних або вдалій SQL-ін'єкції зловмисник отримає дані доступу одного або декількох користувачів. Якби паролі зберігалися в первісному вигляді, зловмисник міг би спробувати використовувати їх для доступу до інших ресурсів (таким чином відбувається захист користувача сайту від злому профілів в інших системах — у нього буде час на зміну паролів, поки зловмисник зайнятий підбором.)

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

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

У більшості UNIX-систем в якості односторонньої функції використовується системна бібліотека crypt(3). Спочатку ця бібліотека використовувала хеш-функцію на базі алгоритму DES. При цьому пароль був обмежений 8 символами (по 7 біт на символ, тобто 56 біт), і використовувалася 12-бітна сіль[1].

1994 року Поуль-Геннінґ Камп на основі MD5 створив новий алгоритм хешування паролів, який дозволяв використовувати паролі будь-якої довжини і використовував тисячу ітерацій MD5[2][3]. Результатом роботи функції став рядок, що містить мітку алгоритму хешування (версію), сіль і власне хеш.

В ті часи, час обчислення такого хешу виглядав достатнім для ефективного протистояння знаходженню пароля повним перебором. Однак по мірі зростання обчислювальних потужностей час знаходження MD5 сильно зменшився. Це призвело до появи в crypt обчислювально більш складних алгоритмів та управління числом ітерацій[4].

Зараз бібліотека підтримує кілька хеш-функцій на базі алгоритмів: MD5, SHA-256, SHA-512, Blowfish (у деяких дистрибутивах Linux, OpenBSD і деяких інших UNIX-подібних системах)[5]. Результатом роботи функції є рядок, що містить мітку алгоритму хешування, сіль, власне хеш і, опціонально, інші дані (наприклад, число раундів хеш-функції).

У 2012 році Poul-Henning Kamp закликав повністю відмовитися від створеного ним алгоритму md5crypt, який не забезпечує, в сучасних умовах, відчутного збільшення часу обчислення хешу, а як наслідок не захищає від повного перебору[6].

• PBKDF2
• scrypt

• Robert Morris, Ken Thompson. Password security: a case history. — ACM New York, NY, USA, 1979. — Т. 22, № 11. — С. 594—597.
• B. Kaliski (September 2000). PKCS #5: Password-Based Cryptography Specification Version 2.0 (англ.). Архів оригіналу за 2 липня 2012. Процитовано 13 червня 2012.