1

Допустим пользователь регистрируется => я должен сохранить его логин и пароль.

Хранить пароль, как строку- это плохо => я должен воспользовать какой-нибудь HASH-функцией.

Хранить голый HASH- это тоже плохо, так как могут воспользоваться радужной таблицей и все такое => нужно добавить соль.

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

Теперь вопрос:

А где обычно хранят эту соль? Просто, в отдельной колонке таблицы рядом с паролем?

SolidSnake
  • 11
  • рядом с паролем, соль играет немного иную роль =) она не позволяет подобрать по словарю(т.к. есть словари вида hash -> значение) солить нужно пароль а не хэш... т.е. вы сначала солите пароль, потом делаете хэш этой комбинации. плюсом нужно использовать медленные хэш функции – Владимир Клыков Jan 23 '20 at 15:38
  • Ну... Я видел, как брали хеш от соли, потом хеш от пароля, а потом хеш(хешсоль+хешпароль) и это было итогом. – SolidSnake Jan 23 '20 at 15:43
  • Не изобретайте никаких солей, а используйте уже существующие реализации, подготовленные умными людми (PBKDF2, bcrypt, scrypt, Argon2) – andreymal Jan 23 '20 at 15:50
  • @andreymal т.е этим хеш-функциям можно передавать пароль и хранить результаты этих функций в БД для последующего сравнения и не нужны никакие соли? – SolidSnake Jan 23 '20 at 15:56
  • @SolidSnake да, они всё сами солят – andreymal Jan 23 '20 at 15:57
  • Хм... А соль, как я понимаю они генерят как-то на основании исходного пароля? – SolidSnake Jan 23 '20 at 15:58
  • @andreymal Вы обратили внимание, что алгоритмы которые вы перечислили все равно берут соль как параметр ? т.е. ваша рекомендация ни как не отвечает на вопрос "откуда брать соль" ? – Mike Jan 23 '20 at 15:58
  • @SolidSnake Чаще всего соль пишут как часть итогового хеша в то же поле с хешированным паролем. Алгоритм проверки пароля: берем из таблицы значение, делим его на соль и собственно хеш. Применяем к паролю требуемую функцию, с той солью, которую получили. Сверяем хеш. При первичной генерации пароля соль генериться как случайное число. Обратите внимание, в вашем языке вполне может быть функция/библиотека, которая проделывает это сама, например функции password_hash/password_verify в php – Mike Jan 23 '20 at 16:01
  • Вот например "хеш" который я взял из своего shadow, и который сгенерен системной crypt $6$nao1qxaz$de6Ebjfe8..... они сейчас все такие, после первого $ видимо код алгоритма, потом соль, до следующего $, потом пошел собственно хеш – Mike Jan 23 '20 at 16:05
  • @Mike большинство известных мне реализаций упомянутых алгоритмов умеют генерировать соль самостоятельно, поэтому вопроса «откуда брать соль» передо мной не стояло – andreymal Jan 23 '20 at 16:08
  • @andreymal Вот именно, что "реализаций", а перечислили вы алгоритмы, которые сами об этом не заботятся ... P.S. И лично я стараюсь этот вопрос контролировать самостоятельно, потому что если утечет БД, которая сгенерена такими реализациями, то есть небольшая вероятность ее взлома. Я же предпочитаю, что бы соль состояла из двух частей: того, что храниться в хеше и константы, которая известна только на самом сервере. – Mike Jan 23 '20 at 16:12
  • @Mike я предложил воспользоваться существующими реализациями алгоритмов, а не реализовывать их самостоятельно :) Если вы можете контролировать это самостоятельно, то вы молодец, а для людей вроде топикстартера безопаснее доверять существующим решениям) – andreymal Jan 23 '20 at 16:19
  • @Mike ну т.е вы предлагаете хранить в одной колонке БД: Соль+Пароль с учетом соли. – SolidSnake Jan 23 '20 at 17:11
  • А это как вам нравится. Я лишь сказал как обычно принято делать. Можно и отдельной колонкой – Mike Jan 23 '20 at 18:37

0 Answers0