Какой тип данных использовать для поля хешированного пароля и какой длины?

Question

Какой тип данных использовать для поля хешированного пароля и какой длины?

224

Я не уверен, как работает хеширование паролей (будет выполняться позже), но теперь нужно создать схему базы данных.

Я подумываю ограничить пароли 4-20 символами, но, как я понимаю, после того, как шифрование хэш-строки будет иметь разную длину.

Итак, как хранить эти пароли в базе данных?

z-boss 29 окт. 2008, в 16:09

Источник

0

Также см. Фреймворк для хэширования паролей в PHP в PHP . Его портативный и защищенный от ряда распространенных атак на пароли пользователей. Парень, который написал фреймворк (SolarDesigner), тот же, кто написал Джона Потрошителя и является судьей в конкурсе хэширования паролей . Таким образом, он знает кое-что о атаках на пароли.
jww 12 окт. 2014, в 01:33
2

Пожалуйста, не устанавливайте верхний предел для ваших паролей. Вы их хешируете, для верхнего предела нет причины хранения. Если вы беспокоитесь о DoS-атаках с использованием хэша пароля, 1000 или 1024 - разумный верхний предел.
Iiridayn 15 фев. 2016, в 04:57
0

зачем ограничивать длину пароля? По крайней мере, позвольте пользователю создать 100-символьный пароль :)
Andrew 20 март 2016, в 19:33
0

4 символа - довольно опасная нижняя граница для паролей, так как они тривиальны для взлома. По крайней мере, используйте 8, но 14 или 16 гораздо лучше.
quikchange 20 нояб. 2016, в 01:50

Показать ещё 2 комментария

Теги:

mysql

types

hash

cryptography

passwords

9 ответов

14

Фактически вы можете использовать CHAR (length of hash) для определения вашего типа данных для MySQL, потому что каждый алгоритм хэширования всегда будет оценивать одинаковое количество символов. Например, SHA1 всегда возвращает шестнадцатеричное число из 40 символов.

Noah Goodrich 29 окт. 2008, в 16:53

8

Как строка с фиксированной длиной (VARCHAR (n), но MySQL вызывает ее). Хэш всегда имеет фиксированную длину, например, 12 символов (в зависимости от используемого алгоритма хеширования). Таким образом, пароль 20 char будет уменьшен до 12 char хэшей, а пароль 4 char также даст хеш 12 char.

Treb 29 окт. 2008, в 17:27

3

«или как MySQL называет это» - MYSQL называет это CHAR. Этот тип предназначен для фиксированной длины. Поэтому я думаю, что CHAR лучше, чем VARCHAR.
t298712383 13 окт. 2016, в 20:35

7

Вы можете найти эту статью в Википедии о том, чтобы солить стоящий. Идея состоит в том, чтобы добавить набор бит данных для рандомизации вашего значения хэша; это защитит ваши пароли от атак на словах, если кто-то получит несанкционированный доступ к хэшам паролей.

Dana the Sane 29 окт. 2008, в 16:08

2

Это действительно очень полезно (+1), но это не отвечает на вопрос! (-1)
Bill Karwin 29 окт. 2008, в 16:59
3

Да, но определенно актуально в этом контексте (+1)
Treb 29 окт. 2008, в 20:37
1

Хороший вопрос, но больше комментарий, чем ответ
MikeT 17 янв. 2017, в 12:01

Показать ещё 1 комментарий

3

Хэши - это последовательность бит (128 бит, 160 бит, 256 бит и т.д., в зависимости от алгоритма). Ваш столбец должен быть двоично-типизированным, а не текстовым или символьным, если это позволяет MySQL (тип данных SQL Server - binary(n) или varbinary(n)). Вы также должны солить хеши. Соли могут быть текстовыми или двоичными, и вам понадобится соответствующий столбец.

yfeldblum 29 окт. 2008, в 16:27

0

Справедливость здесь совершенно верна - MySQL будет хранить их в виде числовых значений и сделает поиск по этому столбцу намного более эффективным, чем сопоставление строк, однако соли не должны храниться в базе данных, кроме соленых данных, что исключает безопасность, которую обеспечивают соли ,
Tony Maro 20 сен. 2011, в 14:54
6

Соли не секрет. Единственный секрет - это пароль. Просто убедитесь, что каждый новый пароль получает новую соль. Каждый раз, когда пользователь меняет свой пароль, система должна генерировать новую соль для этого пароля. Соли должны быть длинными и случайными, например, 16 байтов, сгенерированных из криптографически безопасного PRNG.
yfeldblum 20 сен. 2011, в 15:31
1

@TonyMaro Не уверен, что соответствие строки пароля на уровне SQL является хорошей стратегией. Другими словами, вам не следует искать в вашей базе данных пароль, вместо этого извлекать пользователя на основе его имени пользователя и сравнивать пароли в коде, а не в SQL.
bart 25 июль 2017, в 22:27

Показать ещё 1 комментарий

2

для md5 vARCHAR (32) является подходящим. Для тех, кто использует AES лучше использовать varbinary.

Hare Srinivasa 29 май 2010, в 08:00

2

Это зависит от алгоритма хеширования, который вы используете. Длина пароля имеет мало общего с длиной хэша, если я правильно помню. Посмотрите спецификации на алгоритм хеширования, который вы используете, запустите несколько тестов и обрезайте чуть выше этого.

willasaywhat 29 окт. 2008, в 15:55

1

Я всегда тестировал, чтобы найти длину строки MAX зашифрованной строки и установить ее как длину символа типа VARCHAR. В зависимости от того, сколько записей у вас будет, это может реально помочь размеру базы данных.

Stephen Walcher 29 окт. 2008, в 16:05

0

Вы должны использовать TEXT (сохраняя неограниченное количество символов) для обеспечения прямой совместимости. Хеширующие алгоритмы (необходимость) становятся более прочными с течением времени, и поэтому этому полю базы данных потребуется поддержка большего количества символов с течением времени. Кроме того, в зависимости от вашей стратегии миграции вам может потребоваться сохранить новые и старые хэши в одном поле, поэтому не рекомендуется устанавливать длину одного типа хэшей.

bart 25 июль 2017, в 22:54

Ещё вопросы

Также см. Фреймворк для хэширования паролей в PHP в PHP . Его портативный и защищенный от ряда распространенных атак на пароли пользователей. Парень, который написал фреймворк (SolarDesigner), тот же, кто написал Джона Потрошителя и является судьей в конкурсе хэширования паролей . Таким образом, он знает кое-что о атаках на пароли.
Пожалуйста, не устанавливайте верхний предел для ваших паролей. Вы их хешируете, для верхнего предела нет причины хранения. Если вы беспокоитесь о DoS-атаках с использованием хэша пароля, 1000 или 1024 - разумный верхний предел.
зачем ограничивать длину пароля? По крайней мере, позвольте пользователю создать 100-символьный пароль :)
4 символа - довольно опасная нижняя граница для паролей, так как они тривиальны для взлома. По крайней мере, используйте 8, но 14 или 16 гораздо лучше.
«или как MySQL называет это» - MYSQL называет это CHAR. Этот тип предназначен для фиксированной длины. Поэтому я думаю, что CHAR лучше, чем VARCHAR.
Это действительно очень полезно (+1), но это не отвечает на вопрос! (-1)
Да, но определенно актуально в этом контексте (+1)
Хороший вопрос, но больше комментарий, чем ответ
Справедливость здесь совершенно верна - MySQL будет хранить их в виде числовых значений и сделает поиск по этому столбцу намного более эффективным, чем сопоставление строк, однако соли не должны храниться в базе данных, кроме соленых данных, что исключает безопасность, которую обеспечивают соли ,
Соли не секрет. Единственный секрет - это пароль. Просто убедитесь, что каждый новый пароль получает новую соль. Каждый раз, когда пользователь меняет свой пароль, система должна генерировать новую соль для этого пароля. Соли должны быть длинными и случайными, например, 16 байтов, сгенерированных из криптографически безопасного PRNG.
@TonyMaro Не уверен, что соответствие строки пароля на уровне SQL является хорошей стратегией. Другими словами, вам не следует искать в вашей базе данных пароль, вместо этого извлекать пользователя на основе его имени пользователя и сравнивать пароли в коде, а не в SQL.

Bill Karwin · Accepted Answer · 2008-10-29T17-55-00.000Z

357

Лучший ответ

Это зависит от используемого алгоритма хэширования. Хеширование всегда производит результат той же длины, независимо от ввода. Типично представлять двоичный хэш-результат в тексте, как ряд шестнадцатеричных цифр. Или вы можете использовать функцию UNHEX(), чтобы уменьшить длину шестнадцатеричных цифр наполовину.

MD5 генерирует 128-битное хэш-значение. Вы можете использовать CHAR (32) или BINARY (16)
SHA-1 генерирует 160-битное хэш-значение. Вы можете использовать CHAR (40) или BINARY (20)
SHA-224 генерирует 224-битное хэш-значение. Вы можете использовать CHAR (56) или BINARY (28)
SHA-256 генерирует 256-битное хэш-значение. Вы можете использовать CHAR (64) или BINARY (32)
SHA-384 генерирует 384-битное хэш-значение. Вы можете использовать CHAR (96) или BINARY (48)
SHA-512 генерирует 512-битное хэш-значение. Вы можете использовать CHAR (128) или BINARY (64)
BCrypt генерирует зависимое от реализации 448-битное хэш-значение. Вам может понадобиться CHAR (56), CHAR (60), CHAR (76), BINARY (56) или BINARY (60)

NIST рекомендует использовать SHA-256 или выше для паролей. Малые алгоритмы хеширования имеют свои применения, но они известны как трещины.

Перед применением функции хэширования вы должны salt ваши пароли. Солить пароль не влияет на длину результата хэша.

Bill Karwin 29 окт. 2008, в 17:55

0

Соление может быть сделано путем добавления уникального значения (например, имени пользователя) к каждому паролю. Вот статья, которая объясняет, почему это необходимо: codinghorror.com/blog/2007/09/rainbow-hash-cracking.html . Короче говоря, это помогает предотвратить попытки взлома паролей, использующие метод радужной атаки.
AbdullahC 15 сен. 2010, в 18:15
37

@Hippo: Пожалуйста, не используйте имя пользователя в качестве соли. Генерация случайной соли для каждого пользователя.
Bill Karwin 15 сен. 2010, в 18:38
3

Хранится ли случайно сгенерированная соль в той же строке таблицы?
AbdullahC 16 сен. 2010, в 05:59
11

Да, нет причин не хранить его в одном ряду. Даже если злоумышленник получит доступ к вашей базе данных, он должен будет построить свою радужную таблицу на основе этой соли. И это такая же работа, как и угадывание пароля.
Bill Karwin 16 сен. 2010, в 07:14
0

@ Билл Карвин: То есть, вы говорите, что нужно просто задать соль как x символов, добавленных к паролю? Когда пользователь вводит свой пароль для входа, как вы узнаете, какую случайную соль вы использовали, чтобы получить эквивалентный хеш?
SgtPooki 14 окт. 2011, в 03:23
5

@SgtPooki: Вам нужен еще один столбец, чтобы хранить соль в открытом виде. Затем вы можете хэшировать пароль пользователя с той же солью, когда он вводит его, и сравнивать результат с хэш-дайджестом, хранящимся в таблице.
Bill Karwin 14 окт. 2011, в 06:23
0

@ Билл Карвин: Если бы я взламывал базу паролей, которую я свободно признаю, что не смог бы сделать, я бы наверняка попробовал какое-то неопознанное поле в качестве соли. Я немного разбираюсь в радужных таблицах, но, возможно, этого недостаточно, чтобы думать, что кто-то сможет написать сценарий обходного пути / соли, и просто применить каждый столбец в таблице паролей как соль, а затем запустить радужную таблицу. Таким образом, вместо одной радужной таблицы для таблицы без солей, у вас будет число столбцов с радужной таблицей для каждой строки? Я в замешательстве? или хакер слишком много беспокоится о столбце row * для всех пользователей?
SgtPooki 19 окт. 2011, в 03:44
1

@SgtPooki: Имейте в виду, что создание радужного стола для данной соли требует много работы и много места. На самом деле может быть проще угадать пароль с помощью исчерпывающего поиска, даже если вы знаете соль.
Bill Karwin 19 окт. 2011, в 05:10
11

Если вы храните соль в той же таблице (или в любом другом месте с такими же правами доступа), нет причин не использовать имя пользователя в качестве соли, поскольку оно будет уникальным для каждого пользователя. Однако любая известная соль делает хеш криптографически слабее, чем если бы не было известной соли. Соль только добавляет ценность, если это также неизвестно.
fijiaaron 18 май 2012, в 13:39
0

Кроме того, это неправда, что младшие битовые хэши более взломаны. Возможностей меньше, так что взломать методом «грубой силы» более выполнимо, но хотя есть способы имитировать хэш MD5 или SHA1, их алгоритмы по-прежнему не имеют проверенных недостатков. Простая проверка strlen () делает дублирование хэша пароля невозможным. Не то чтобы я говорил, что MD5 или SH1 - полностью безопасное решение, просто педантичное.
fijiaaron 18 май 2012, в 13:51
9

Я не понимаю сделку с известной солью против неизвестной. Если вы внедряете сайт - соль должна быть известна странице входа / script / sevice, которая проверяет пароль. Итак, вы - «неизвестные» сторонники соли - вы предполагаете, что код для входа в систему неизвестен злоумышленнику? В противном случае - не будет ли злоумышленник всегда знать соль, случайную, уникальную, хранимую вместе с хешированным паролем или отдельно?
mattstuehler 04 янв. 2013, в 19:31
0

Я не совсем понимаю, почему для CHAR вам понадобится вдвое больше, например, CHAR (64), когда длина символа составляет всего один байт, не могли бы вы разместить 256-битное значение в CHAR (32)?
Sean_A91 22 июль 2015, в 22:31
1

@ Sja91, да, если вы хотите сохранить 0x00-0xFF в одном байте, используйте BINARY (). Это строковый тип данных без набора символов. Но если вы читаете непечатаемые двоичные строки напрямую, это приводит к тому, что ваш экран сходит с ума. Вы бы использовали CHAR (), если хотите хранить дружественные для отображения строки шестнадцатеричных цифр. Но для представления значений в диапазоне 0x00-0xFF требуется два шестнадцатеричных символа.
Bill Karwin 23 июль 2015, в 00:29
0

Какой тип данных использовать при хранении зашифрованных паролей PBKDF2? Похоже, что nvarchar(max) имеет проблему с производительностью, что, по вашему мнению, может использовать длину 128, изменится ли длина?
stom 13 янв. 2016, в 11:27
1

@stom, да, длина 128 может содержать хеш SHA512, так что этого будет достаточно.
Bill Karwin 13 янв. 2016, в 16:59
4

В ответ на @fijiaaron, «нет причин не использовать имя пользователя в качестве соли», см. Security.stackexchange.com/a/41618/2572 . Соль должна быть уникальной во всем мире , как и во всем Интернете. Хранение соли в базе данных вместе с паролем в порядке. Использование имени пользователя в качестве соли ослабляет его.
Iiridayn 15 фев. 2016, в 05:06
0

@mattstuehler ваша страница входа никогда не должна выполнять тестирование пароля, вы можете сделать предварительный хэш на странице входа, если вы не используете SSL, но фактический хэш пароля никогда не должен покидать хранилище, поэтому вы передаете данные входа на сервер затем он возвращается, если это было успешно или нет,
MikeT 17 янв. 2017, в 11:49
0

@Iiridayn, это тот случай, когда вы оба правы, уникальная соль всегда будет лучше, чем имя пользователя, но если вы не оставите соль неизвестной, уровень защиты значительно снизится, пока не сравнится, но все же лучше, чем использование имени пользователя.
MikeT 17 янв. 2017, в 11:57
1

@MikeT вы можете эффективно вычислять радужные таблицы с именами пользователей в качестве солей для общих имен пользователей. Предотвращение атак до вычислений повышает безопасность. См. Security.stackexchange.com/a/5506/2572 и owasp.org/index.php/… , в котором рекомендуется 32 или 64 случайных байта. Имена пользователей предсказуемы и коротки.
Iiridayn 18 янв. 2017, в 19:04
0

@Iiridayn, и вы можете предварительно вычислить с известной солью, так что если вы знаете, что сайт X использует соль 123 для вычисления паролей, то вы предварительно вычислите свой список паролей с солью, поскольку результирующие таблицы не могут использоваться между сайтами, то есть незначительное улучшение по сравнению с именем пользователя, но не так много, если учесть, что злоумышленник, вероятно, нацелен на 1 сайт сразу, поэтому не рекомендуется использовать известные соли
MikeT 18 янв. 2017, в 19:23
1

@MikeT, вы думаете, что каждый пользователь на данном сайте использует одну и ту же соль? Нет - используйте случайную соль для каждого пользователя . Затем для каждого пользователя должна быть создана отдельная радужная таблица, что делает ее не менее дорогой (вероятно, более дорогой, учитывая хранилище), чем угадывание паролей.
Bill Karwin 18 янв. 2017, в 19:27
0

@BillKarwin, нет счета, я говорю, что если вы не используете соли правильно, они не намного лучше, чем просто использование имени пользователя, некоторые системы хешируют пароли с общей или предопределенной солью, это распространенная ошибка, которая создает небезопасную система, это означает, что вы должны держать соли неизвестными как путем создания новых паролей для каждого пароля, так и для хранения солей вне общественного достояния. В идеале ни хэш пароля, ни соль никогда не должны покидать ваш сервер, и если ваш сервер скомпрометирован, вы должны требовать все логины, чтобы изменить пароль и создать новую соль, когда они делают
MikeT 18 янв. 2017, в 19:35
0

это означает, что если fijiaaron сравнивает использование имени пользователя в качестве Известной соли и любой другой известной соли, то они совершенно корректны, разница невелика, однако, если вы говорите о правильно используемой неизвестной соли, то Iiridayn правильный, а имя пользователя бесполезное
MikeT 18 янв. 2017, в 19:49
0

Да, нет причин, чтобы соль была публичной. Я не думаю, что кто-то предлагает сделать это. Код на стороне сервера должен запросить соль соответствующего пользователя, затем использовать его для хеширования ввода пользователя, а затем сравнить этот результат с хешированной версией пароля, ранее сохраненного в базе данных. Значение соли никогда не покидает сервер и не становится общедоступным.
Bill Karwin 18 янв. 2017, в 20:05

Показать ещё 22 комментария