Який тип / довжину стовпця я повинен використовувати для зберігання хешованого пароля Bcrypt у базі даних?

Я хочу зберігати хешований пароль (за допомогою BCrypt) у базі даних. Який був би хороший тип для цього, а яка була б правильна довжина? Чи завжди хешовані паролі з BCrypt завжди однакової довжини?

EDIT

Приклад хешу:

$2a$10$KssILxWNR6k62B7yiX0GAe2Q7wwHlrzhF3LqtVvpyvHZf0MwvNfVu

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

EDIT 2

Вибачте, що не згадуєте про реалізацію. Я використовую jBCrypt .

Модульний формат крипт для bcrypt складається з

• $2$, $2a$Або $2y$ідентифікації алгоритму хешування і формат
• двозначне значення, що позначає параметр вартості, за яким слідує $
• 53 - символів базового 64-кодоване значення (вони використовують алфавіт ., /, 0- 9,A - Z, a- , zщо відрізняється від стандартної бази 64 кодування алфавіту) , що складається з:
  • 22 символи солі (фактично лише 128 біт із 132 розшифрованих шматочків)
  • 31 символ зашифрованого виводу (фактично лише 184 біти з 186 розшифрованих бітів)

Таким чином, загальна довжина становить 59 або 60 байт відповідно.

Під час використання формату 2a вам знадобиться 60 байт. Таким чином, для MySQL я рекомендую використовувати CHAR(60) BINARYабоBINARY(60) ( для інформації про різницю див . _Bin та бінарні Collations ).

CHARне є бінарним безпечним і рівність не залежить тільки від байтового значення, але і від фактичного зіставлення; в гіршому випадку Aтрактується як рівний a. Див і Collations для отримання додаткової інформації._binbinary

Хеш-код Bcrypt може зберігатися у BINARY(40)стовпці.

BINARY(60), як підказують інші відповіді, - це найпростіший і найприродніший вибір, але якщо ви хочете досягти максимальної ефективності зберігання, ви можете заощадити 20 байт, без втрат деконструюючи хеш. Я детальніше це задокументував у GitHub: https://github.com/ademarre/binary-mcf

Хеши криптовалют слідують за структурою, що називається модульним форматом крипт (MCF). Двійкові MCF (BMCF) декодує ці текстові хеш-подання до більш компактної бінарної структури. У випадку Bcrypt отриманий бінарний хеш становить 40 байт.

Gumbo зробив гарну роботу, пояснивши чотири компоненти хеша Bcrypt MCF:

$<id>$<cost>$<salt><digest>

Розшифровка до BMCF відбувається так:

1. $<id>$ може бути представлений у 3 бітах.
2. <cost>$, 04-31, можна представити у 5 бітах. Складіть їх разом на 1 байт.
3. Сіль з 22 символами є (нестандартним) базовим 64-представленням 128 біт. Розшифровка Base-64 дає 16 байт.
4. 31-символьний хеш-дайджест може бути базовим - 64 декодовані до 23 байтів.
5. Зберіть все це на 40 байт: 1 + 16 + 23

Ви можете прочитати більше за посиланням вище або переглянути мою реалізацію PHP , також на GitHub.

Якщо ви використовуєте PHP password_hash()з PASSWORD_DEFAULTалгоритмом для генерування хеш-файлів bcrypt (я вважаю, що це великий відсоток людей, які читають це запитання), не забудьте пам’ятати, що в майбутньому password_hash()може використовуватися інший алгоритм як за замовчуванням, і це може тому впливають на довжину хешу (але це може бути не обов'язково довше).

З сторінки керівництва:

Зауважте, що ця константа призначена для того, щоб змінюватись з часом, оскільки до PHP додаються нові і сильніші алгоритми. З цієї причини тривалість результату від використання цього ідентифікатора може змінюватися з часом. Тому рекомендується зберігати результат у стовпці бази даних, яка може розширюватися за рамки 60 символів (255 символів було б хорошим вибором).

Використовуючи bcrypt, навіть якщо у вас є 1 мільярд користувачів (тобто ви зараз змагаєтесь з facebook) для зберігання 255 байтових хешей паролів, це буде лише ~ 255 ГБ даних - приблизно розміром невеликого жорсткого диска SSD. Надзвичайно малоймовірно, що зберігання хеша пароля буде вузьким місцем у вашій програмі. Однак, з випадковою можливістю, що місце для зберігання дійсно є проблемою з якихось причин, ви можете PASSWORD_BCRYPTзмусити password_hash()використовувати bcrypt, навіть якщо це не за замовчуванням. Просто не забудьте бути в курсі будь-яких уразливостей, виявлених у bcrypt, та переглядайте нотатки до випуску щоразу, коли виходить нова версія PHP. Якщо алгоритм за замовчуванням колись змінюється, було б добре переглянути, чому і прийняти обгрунтоване рішення, використовувати новий алгоритм чи ні.

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

Я думаю, що найкраще зробити це - зберігати його так, CHAR(60)як це завжди 60 символів