Статья на хабре про хеширование паролей. Непонятны некоторые моменты. Поможете разобраться?

Question

[sorry_i_noob]

Здравствуйте. Разбираюсь вот с этой статьей:
https://habr.com/post/210760/
После прочтения возникло несколько вопросов.

1) При хешировании пароля нужно брать случайную соль? А при проверке делать цикл - хешировать проверяемый пароль через все соли из БД и проверять - не совпал ли хеш с тем, что в БД, верно?
3) Сколько должно быть солей в БД?
4) Если я случайно буду выбирать соль из БД все же может получиться так, что у пользователей с одинаковым паролем будет одинаковый хеш пароля? ведь случайность может быть выпасть на ту же самую соль. Разве это нормально?

5) Можно ли этот способ использовать для создания пароля / токена (чтобы восстановить пароль / подтвердить почтовый ящик)? Или это делает уязвимость для сайта? Вроде глупый вопрос, но в той же статье на хабре написано вот что:

Сразу определю какую задачу применения хешей буду рассматривать — аутентификация пользователей. Не токены восстановления паролей, не аутентификация запросов, не что-то еще. Это также не статья про защиту канала передачи данных, так что комментарии по challenge-response и SSL неуместны!

Answer 1

[Tyranron]

Отвечали уже не раз. Советую внимательно ознакомиться.

Также, на том же Хабре, есть более свежие вменяемы статьи:
Про хранение паролей в БД (обязательно читать комменты)
Правильные ответы по криптографии: 2018 год

Непосредственно по Вашим вопросам:

1. При создании хэша пароля генерировать случайную соль. Сохранять в БД хэш + соль. При проверке пароля выбирать из БД хэш + соль, хэшировать полученный пароль с солью, и сопоставлять результат с хэшом из БД.

3. Для каждого хранимого хэша пароля своя уникальная соль.

4. Соль генерируется достаточно случайной, потому что она должна быть сложно угадываемой. Это означает, что энтропия для этого дела берется достаточно большая, и Вы можете не переживать за то, что чисто теоретически у Вас может сгенерироваться 2 одинаковые соли. Вероятность подобного случая примерно сравнимая с вероятностью того, что все молекулы воздуха в Вашей комнате возьмут и соберутся в одном углу, то есть, крайне мала(с). И даже если Вы спустите весь запас удачи своей жизни на такой воистину уникальный случай, то ничего страшного и непоправимого при этом не случится - ну поймёт злоумышленник, что конкретно у этих 2х пользователей одинаковый пароль, ну и всё на этом, - пароли то всё ещё надо взламывать.

5. Да, можно. Хотя задача хэширования паролей и задача восстановления доступа по токену - это 2 разные задачи, с разными дано и целями, но первая задача является частью второй, ибо Вам нужно хранить в БД отпечаток секрета пользователя (коим временный токен восстановления и является). Алгоритм простой: генерируем случайный временный токен восстановления -> пишем в БД его отпечаток (хэш + соль) и время жизни -> отправляем токен пользователю -> пользователь переходит по ссылке с токеном -> проверяем валидность токена по его отпечатку и времени жизни -> заставляем пользователя ввести новый пароль. По сути, токен восстановления и являет собой одноразовый временный пароль, который предоставляет доступ для установки постоянного пароля.

Ну и традиционный совет: используйте для получения отпечатков секретов пользователей рекомендуемые алгоритмы (Argon2, Bcrypt, scrypt, и т.п.), а не собственные реализации. Там всё сделано под капотом как надо, ибо нюансов своих в этом деле тоже хватает (стоимость по времени, стоимость по памяти, constant time сравнения, и т.д.).

Comments

[sorry_i_noob]

хэш + соль

почему хеш + соль? это лучше, чем прибавить соль до вычисления хеша?

генерируем случайный временный токен восстановления

я видел в php функцию генерации случайных чисел. но вот случайных токенов - нет. что это за функция?

[sorry_i_noob]

я прочил про Bcrypt. он уже использует соль. таким образом, дополнительно солить перед использованием этой функции не надо?

[Tyranron]

sorry_i_noob,

почему хеш + соль? это лучше, чем прибавить соль до вычисления хеша?

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

Грубо говоря, смысл следующий (не делать так в коде!):

// Установка пароля
$salt = generate_random();
$footprint = md5($_POST['password'].$salt).$salt;
save_to_database($footprint);

// Проверка пароля
$footprint = get_from_db();
$expectedHash = substr($footprint, 0, 32);
$salt = substr($footprint, 32);
$actualHash = md5($_POST['password'].$salt);
$is_valid = hash_equals($actualHash, $expectedHash);

я видел в php функцию генерации случайных чисел. но вот случайных токенов - нет. что это за функция?

Токен - это просто термин. В данном случае имеется в виду строка состоящая из случайных символов, либо просто набор случайных байт.
random_bytes()

я прочил про Bcrypt. он уже использует соль. таким образом, дополнительно солить перед использованием этой функции не надо?

Да, не надо. Он сам генерирует как надо случайную соль и присобачивает её к результирующему отпечатку.

Вам, по сути, остаётся только:

// Установка пароля
$footprint = password_hash($_POST['password'], PASSWORD_BCRYPT);
save_to_db($footprint);

// Валидация пароля
$footprint = get_from_db();
$is_valid = password_verify($_POST['password'], $footprint);

Вообще, читайте официальную документацию больше, там всё разжевано тоже.

Answer 2

[sim3x]

1. Нет. Соль можно хранить рядом с хешем в таблице
Можно использовать единую для всех паролей соль, но очень длинную
Если не достаточно, то можно присоединять к соли неизменяемый параметр учетной записи пользователя типа даты создания
3. Или все, или ниодной
4. Соль не случайна. Соль (или часть соли) однозначно привязана к записи пользователя
5. Проще использовать связку UUID + email пользователя с сохранением UUID в записи пользователя и проверкой ее

Автор статьи перебдел, тк видимо сам является безопасником
Уточню, что статья довольно старая и скорости перебора хешей лучше не принимать на веру

Comments

[sorry_i_noob]

А можно пример с UUID + email?
Что такое UUID вообще? Чем плох метод создания хеша, который используется и для создания пароля?

[sim3x]

sorry_i_noob,
вызываем uuid.uuid4() и вставляем в сессию юзера

https://www.google.com.ua/search?q=UUID

Плох тем что злоумышленник получает доп информацию через апи, вызов которого вы не будете контролировать. Кто в здравом уме обратит внимание на 10М писем с восстановлением паролей?

Да и просто KISS

[sorry_i_noob]

Плох тем что злоумышленник получает доп информацию через апи, вызов которого вы не будете контролировать. Кто в здравом уме обратит внимание на 10М писем с восстановлением паролей?

Не понимаю. Можно вот тут по-подробнее?

[sorry_i_noob]

вызываем uuid.uuid4() и вставляем в сессию юзера

Почему в сессию, а не в БД?

[sim3x]

sorry_i_noob, можете сохранять в БД, не забывая очищать

Не понимаю. Можно вот тут по-подробнее?

не имея доступа к коду бека, но формируя много сообщений о восстановлении, злоумышленник может понять как формируется хеш и при наличии большого колличества сообщений и короткой общей соли он может ее пробрутфорсить

[sorry_i_noob]

sim3x, а куда лучше - в сессию или в БД? я новичок просто, не знаю. Я слышал, что сессию можно перехватить. И это проще, чем получить доступ к БД.

[sim3x]

sorry_i_noob,

Сессия, чаще всего удаляется самостоятельно без вашего вмешательства, в БД придется думать самому

Сессию можно перехватить, если у вас зловред на бекенде. Тут уже ничего не сделать
Пользовательскую куку с его идентификатором могут утащить если есть xss

Answer 3

[АртемЪ]

Соль нужна для исключения подбора пароля по таблице.
Ее задача увеличить длину пароля, чтобы исключить вероятность нахождения его в таблице.
Хэш для пароля qwerty и для пароля 3fg%S c довольно высокой вероятностью найдется в таблице.
Если к этим паролям присобачить соль вроде - "ijlkhUoiUUGy;iu*&^t89uJbYF&^98HnbTtfjbkjbVhgcjnjbhjvtftbjb", то в таблице ее хэша гарантированно не будет.

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

Соль не является секретной информацией, нет никакой необходимости в ее защите.

Comments

[sorry_i_noob]

На википедии написано, что длина соли - это 10-20 символов:
https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%BB%D...

Если же мы «посолим» пароль, то есть соединим строчку из 10—20 случайных символов с паролем и уже от этой строчки найдём MD5, — стандартные таблицы не будут работать, так как они не рассчитаны на поиск такой длинной строки.

А у вас целых 58.
Какой длины должна быть соль? И как ее лучше составлять?

[АртемЪ]

sorry_i_noob,

Какой длины должна быть соль?

Основной параметр соли - ее длина.
Именно для увеличения длинны пароля она и нужна.
На википедии написано все правильно - длина соли в 10-20символов вполне достаточна в наше время, при существующих вычислительных мощностях. И на это есть смысл ориентироваться.
Меньше - не стоит, больше можно, но особого смысла в этом нет, только впустую увеличите нагрузку на свой сервер, так что без фанатизма.
Я просто набил строчку для примера не считая количества символов.

И как ее лучше составлять?

Как угодно.
Главные требования - длина, и желательно но не обязательно - уникальность для каждого пользователя.
Других требований нет.
Если у вас соль будет "1111111111111" это ничем не хуже чем скажем "hu89u7yG7^67f^7F6" - важна только длина, а не содержание.
Можете банально в качестве соли использовать какие-то данные пользователя - его ник, идентфикатор в базе, дату его рождения, или генерировать случайно и просто хранить в БД рядом с хэшем пароля. Только если используете какие то пользовательские данные для соли - подумайте не будут ли они меняться, иначе будут проблемы.

[АртемЪ]

Соль в основном защищает от взлома аккаунты пользователей с короткими паролями.
Если у пользователя пароль в 20-30 символов его и без всякой соли в радужных таблицах не найдешь.
Поэтому хоть соли, хоть не соли - ничего не поменяется.

А вот если у пользователя пароль в пять символов, его хэш вероятнее всего уже есть в таблицах, и взлом займет секунды - банальный поиск по таблице, даже если пароль вполне себе сложный вроде H4c&u
Добавим к нему соль - и все, поиск по таблице исключается, остается только перебор.

[sorry_i_noob]

Если у вас соль будет "1111111111111" это ничем не хуже чем скажем "hu89u7yG7^67f^7F6" - важна только длина, а не содержание.

Что-то совсем не верится. А можно какие-нибудь доказательства?

[АртемЪ]

sorry_i_noob, Ну я вроде довольно доходчиво объяснил для чего нужна соль - исключительно для увеличения длины пароля.
Соль "1111111111111" так же эффективно увеличить длину пароля как и любая другая соль такой же длины.
И как следствие хэш пароля будет отсутствовать в радужных таблицах.
Какие еще вам доказательства нужны?
Соль не является секретной информацией, можете смело сообщать соль злоумышленнику - хуже от этого не будет.

[sorry_i_noob]

АртемЪ, я и в исходниках других проектов видел соли. И они, как правило, из разных символов. А не просто одни и те же символы, но разное количество.
Для чего-то ведь сделали именно разные символы.

[АртемЪ]

sorry_i_noob, А я вот литературу читаю, там тоже слова из разных символов - не знаете почему?
Для чего-то же сделали слова из разных символов?

[Tyranron]

АртемЪ либо лукавит, либо не до конца разобрался в вопросе.

Соль нужна не "исключительно для увеличения длины пароля". Основной задачей соли является исключение вероятности попадания результирующего хэша в радужные таблицы, а для этого соль должна быть сложно угадываемой, то есть генерироваться случайным и непредсказуемым образом. Соответственно и длину она должна иметь достаточно большую, дабы её невозможно было легко угадать/перебрать.

Соль 1111111111111 плохая, ибо вероятность того, что в радужных таблицах есть хэши для строки qwerty1111111111111 все ещё достаточно велика.

[АртемЪ]

Tyranron,

Основной задачей соли является исключение вероятности попадания результирующего хэша в радужные таблицы

Именно об этом я и сказал.

Соответственно и длину она должна иметь достаточно большую, дабы её невозможно было легко угадать/перебрать.

Именно так.

а для этого соль должна быть сложно угадываемой, то есть генерироваться случайным и непредсказуемым образом.

Нет. Никаких требований к сложности и непредсказуемости для соли нет, это вы к паролю такие требования можете предъявлять. А для соли достаточно длины.

Соль 1111111111111 плохая, ибо вероятность того, что в радужных таблицах есть хэши для строки qwerty1111111111111 все ещё достаточно велика.

Не выше, чем для строки qwertyFd4^hLJI*f6

[Tyranron]

АртемЪ,

Не выше, чем для строки qwertyFd4^hLJI*f6

Ну, это спорное, и необоснованное утверждение. Но представим, что это так. Тогда просто соль Fd4^hLJI*f6 тоже плохая, недостаточно энтропии.

Нет. Никаких требований к сложности и непредсказуемости для соли нет, это вы к паролю такие требования можете предъявлять. А для соли достаточно длины.

Слушайте, если Ваша соль содержится в радужных таблицах как часть строк, то это абсолютно бесполезная соль.
Соли вида 1111111111111, 000000000000, my super super super salt ever - это всё словарные варианты, а значит вероятность их попадания в радужную таблицу высока.

[АртемЪ]

Tyranron, Ну да, немного перегнул палку, совсем словарные уж ставить не стоит.
Но тем не менее каких то особых требований к сложности там вообще нет, главное длина.
Словарные выражения попадают в таблицы, но там тоже без фанатизма, Ибо их достаточно много, это не слова, которые можно без проблем все разом запихать в таблицу.
Я в своих проектах зачастую в качестве соли использовал хэш от ID пользователя.
Сорок символов с приличной энтропией, хотя это и не слишком актуально, и в базе хранить не надо.

[Tyranron]

АртемЪ, ну кто его знает какие злые гении и как генерирую эти радужные таблицы =)

Я бы, например, пихал все возможные словари + результаты их простейших хэшей и их комбинации. С радужными таблицами дело такое, что Вы не ограничены временем, а за 10-15 лет чего можно только туда не напихать.

Потому, перестраховаться криптографически стойкой случайностью не будет лишним. Более того, это ведь совсем не сложно с современными инструментами. Те же Bcrypt и Argon2 делаю это за Вас.

[АртемЪ]

Tyranron,

С радужными таблицами дело такое, что Вы не ограничены временем, а за 10-15 лет чего можно только туда не напихать.

В принципе да. Основная проблема это объем. Хэши то места прилично занимают, и не сжимаются в принципе. Пока объем гигабайты- еще можно качать, перемещать, когда террбайты уже сложнее, а когда идут петабайты - там уже серьезный ЦОД нужен ради такого дела, а это дорого.

[Tyranron]

АртемЪ, немного поправочка: хранятся не столько хэши, сколько plain text, а хэши выступают ключами. И за счет того, что хэш-функции обеспечивают достаточно неплохое равномерное распределение, у Вас все plain text'ы будут размазаны по ключам достаточно равномерно, что фактически идеально для шардинга, и Вы по хэшам можете легко масштабироваться на миллионы серверов, хоть в одном ЦОДе, хоть в разных.

А кем уже это спонсируется - вопрос отдельный вопрос. Во-первых, заинтересованные лица всегда найдутся (привет, АНБ!), а во-вторых, и на добровольной основе может работать (распределенная БД).