Здавалося б, чим швидше працює хеш-функція, тим краще. Але для хешування паролів усе навпаки: швидкість — це вразливість, а не перевага. Bcrypt навмисно спроєктований повільним, і саме в цьому його сила.
Чому швидкість шкодить безпеці паролів
Якщо зловмисник викрав базу хешів паролів, він намагається підібрати оригінальний пароль перебором. Зі швидкою функцією на кшталт SHA-256 сучасне обладнання може перевіряти мільярди варіантів за секунду. Якщо ж хешування одного пароля навмисно займає, скажімо, 100 мілісекунд, перебір стає на порядки повільнішим і дорожчим.
Що таке cost factor
Bcrypt має параметр "cost" (або "work factor"), що визначає кількість внутрішніх ітерацій — і, відповідно, скільки часу займе одне хешування. Що вищий cost factor, то повільніша функція, і його можна збільшувати з роками, компенсуючи зростання обчислювальної потужності обладнання.
Вбудована сіль
Bcrypt автоматично генерує й вбудовує в результат унікальну випадкову "сіль" для кожного пароля. Це означає, що два однакові паролі дадуть різні хеші, і зловмисник не може заздалегідь порахувати таблицю хешів для поширених паролів (rainbow table) — доведеться атакувати кожен хеш окремо.
Навіщо це потрібно
- Правильно зберігати паролі користувачів у базі даних застосунку.
- Розуміти, чому SHA-256 чи MD5 — поганий вибір для хешування паролів.
- Тестувати чи мігрувати систему автентифікації, що використовує bcrypt.
Прихована межа: 72 байти
Bcrypt обробляє лише перші 72 байти пароля — усе, що довше, просто відкидається без попередження. Це означає, що паролі "дуже-довгий-пароль-1" і той самий пароль з дописаним випадковим текстом після 72-го байта дадуть однаковий хеш. На практиці це рідко проблема (72 байти — це вже дуже довгий пароль), але варто знати про це обмеження, особливо при роботі з не-ASCII паролями, де один символ може займати кілька байтів.