Как лучше генерировать соль рандомно или по каким нибудь данным пользователя?

Question

[StynuBlizz]

Вопрос полностью сформулирован в названии.

Answer 1

[АртемЪ]

Для безопасности - без разницы.
Для удобства - смотрите как вам удобней.

Answer 2

[Пума Тайланд]

А в чем суть использования каких то данных пользователей? Добавить больше энтропии в рандом?
С хорошим рандомом будет без разницы.

Comments

[StynuBlizz]

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

[StynuBlizz]

Или я что-то непонимаю

[Пума Тайланд]

StynuBlizz: ну если вы генерите соль из юзерских данных то это не соль это просто пароль из пароля и юзерских данных, соль логично хранить отдельно.
Вопрос у вас 100% разграничено хранение бд и кода ?

[АртемЪ]

Пума Тайланд: Ну это явно не пароль.
Пароль это нечто известное только пользователю и более никому.
А тут просто допустим соль генерируется из логина - просто не надо тратить место в БД проще каждый раз ее сгенерировать, чем хранить.
В плане безопасности - совершенно одинаково.

[Пума Тайланд]

АртемЪ: одинаково или нет зависит от того как у вас все реализовано и разделено. У меня на секретный сервер с паролями в принципе сложно попасть, даже мне самому )

[АртемЪ]

Пума Тайланд: Одинаково это насчет соли - разницы нет храните ее или генерируете, на безопасность это никак не влияет.

А вот насчет секретного сервера с паролями не понял фразы, это что за зверь такой?

[АртемЪ]

Вы что там пароли на сервере храните?

[StynuBlizz]

Пума Тайланд: С чего вдруг это пароль а не соль. Хранить отдельно это где?

[Пума Тайланд]

StynuBlizz: ну на другом сервере, в коде, ну нельзя соль хранить в бд рядом с паролем это совсем уж )))

[StynuBlizz]

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

[StynuBlizz]

Что даже звучит как-то небезопасно)

[Юрий Чудновский]

Вы не можете использовать какие-то данные клиента в качестве соли. Собственно, единственные данные которые неизменны (а это требование для соли) - это логин пользователя (если его нельзя изменить пользователю), а это общедоступная информация и солью быть не может.

[StynuBlizz]

Юрий Чудновский: Тогда возникает вопрос где хранить данные сгенерированные рандомно?

[StynuBlizz]

вместо данных имел ввиду соль

[Юрий Чудновский]

StynuBlizz: соль обычно хранят в отдельном файле настроек. Чтобі получить соль, хакеру потребуется не просто получить доступ к базе, но и заиметь возможность записать свой файл (скрипт), который он смог бы запустить на сервере и через который он смог бы получить соль.

Советую почитать https://habrahabr.ru/post/210760/

[АртемЪ]

Пума Тайланд:

ну нельзя соль хранить в бд рядом с паролем это совсем уж

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

[Пума Тайланд]

АртемЪ: а где вы их предлагаете хранить, черт все нынче хранят из в бд

[АртемЪ]

Пума Тайланд: Нигде не хранить.
Собственно никто их и не хранит никогда.

[Пума Тайланд]

АртемЪ: ну и коту понятно что про их идет речь

[Юрий Чудновский]

Артём Петренков: Ну что поделать, статья не очень удачная в этом плане, но вы всё же могли заметить что там говорится "Это по сути «вторая соль» дописывается ко всем (паролям+соль) конструкциям, и является одинаковой для всех хешей в базе". Именно эта соль защищает от быстрого вскрытия паролей утёкшей базы. Первая соль только лишь маскирует одинаковые пароли, чтобы нельзя было вскрыв один хэш автоматически найти все аккаунты с таким же паролем. Возможно вы про "первую" соль говорите, а я говорил про "вторую".

[Юрий Чудновский]

Артём Петренков: Разумеется, если уж солить - то по максимуму, первая соль лишь заставляет брутфорсить все пароли, скрывая одинаковые, а вторая соль заставляет взломать сервак полностью. Вторая соль, следовательно, сильнее первой, поэтому маст хэв. Без неё слитая база бесполезна. Первая соль не настолько полезна, но паркуа бы не па.

[Юрий Чудновский]

Артём Петренков: как раз первая соль - security by obscurity, так как утечка базы автоматически её раскрывает (при хранении в той же базе). При хранении первой соли не в базе - она всё равно не сильнее второй, так как взлом сервера полностью (с доступом к файлам скриптов, конфигам и т.п.) раскрывает обе соли.

[Юрий Чудновский]

Артём Петренков: Понимаю. При получении доступа к базе скрипткидсами/ботом брутфорс паролей не получится, но человек который увидит что в базе есть ещё и соль, забрутит пароли ничуть не медленней чем без неё, в первом приближении (т.е. без учёта одинаковых паролей). Это и есть security by obscurity.

[Юрий Чудновский]

Артём Петренков: Ошибаюсь или нет, но вторая соль, всегда хранимая отдельно от базы и без которой забрутить пароли невозможно, никак не может быть security by obscurity.

[Юрий Чудновский]

Артём Петренков: Это даже не спор. Я свою позицию обосновываю, а вы просто делаете ничем не подтверждаемые утверждения.

[Юрий Чудновский]

Артём Петренков: Ваши рассуждения неверны. Соль в базе (первая по терминологии статьи на хабре) всего лишь заставляет брутить все пароли, но никак не усложняет сам брутфорс. Если пароли не повторяются, то эта соль вообще бесполезна, она в таком случае просто ничего не делает. Поэтому это и есть security by obscurity.
Вторая соль, которая хранится отдельно, защищает пароли от брутфорса в случае утечки базы. Взлом сервера для получения доступа к этой соли - гораздо более сложная процедура, чем нахождение банальной sql injection уязвимости или аналогичной. Без получения второй соли брутфорс слитой базы просто бесполезен. Поэтому такая соль - НЕ security by obscurity.

[Юрий Чудновский]

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

Фактически, вы утверждаете что пароли - security by obscurity, ведь "стойкость аутентификации зависит от компрометации этого пароля", но я надеюсь что хоть на этот раз абсурдность утверждения вам будет очевидна.

[Юрий Чудновский]

Артём Петренков: Хорошо, раз аналогия с паролем вам не понятна, то заменим пароли на приватную часть SSL сертификатов.
"Приватный ключ сертификата SSL является, по сути, частью алгоритма хеширования (верно). Соответственно, степень защищённости системы зависит от дополнительного секрета (т.е. приватного ключа), то есть такая схема (SSL) реализует концепцию "безопасность через неясность" - security by obscurity (неверно)"
Эта ваши слова, в которых я заменил "дополнительный секрет" (статичную соль в конфиге) на "приватный ключ сертификата SSL".
Теперь вы видите, что вы фактически, утверждая одно, утверждали и логически то же самое другое - "SSL/пароли/итд - security by obscurity"?
Если всё ещё не очевидно это вам, то можем рассмотреть аналогию с сейфом и ключами к нему. По-вашему получится, что любой сейф это security by obscurity, если к нему есть где-то ключ, ведь ключ можно сп..., ну, сейф не надёжнее чем способ хранения ключа. Но ведь если ключ хорошо защищён, то сейф надёжен, так? Тогда получится, возвращаясь к нашей базе, где база - сейф с паролями, ключ - соль в конфиге, то база защищена настолько, насколько защищён ключ, то есть конфиг. И поскольку грамотно настроенный админами сервер довольно надёжен, получаем что соль в конфиге достаточно надёжно защищает пароли от взлома даже в случае утечки базы из-за ошибки программистов. Что и требовалось доказать.

[Юрий Чудновский]

Артём Петренков: Вот, разговор уже обретает конструктивную форму.
Как вы понимаете, даже защищённый паролем приватный ключ, если утёк, рано или поздно будет забрутфорсен.
Писать собственный код без ошибок или проводить аудит безопасности после каждого деплоя - фантастика.
Провести один раз аудит безопасности после поднятия сервера или даже просто нанять грамотного админа - гораздо реалистичнее, поэтому на динамичном развивающемся проекте можно априори считать, что рано или поздно программистами БУДЕТ допущена ошибка приводящая к утечке базы, в то время как вероятность взлома сервера с полным контролем со стороны хакеров - маловероятное событие. Именно поэтому соль в базе не защищает от утечки паролей, соль в отдельном файле даёт ступень защиты, которая в грамотном исполнении позволит сохранить пароли пользователей в тайне даже после ошибки программистов.
В случае взлома сервера целиком, никакие меры не защитят ничего, поэтому этот вариант развития событий и нечего рассматривать - тут уж хоть действительно пароли в открытом виде, разницы не будет кроме как время от взлома до публикации взломщиками паролей.

[Tyranron]

Юрий Чудновский: извините, но Ваши аналогии в корне не верны.

Не корректно сравнивать SSL и password hashing. Это 2 разные криптографические задачи, хотя бы потому, что в password hashing не предполагается передачи зашифрованной информации обратно на клиент. Также, разное кол-во секретов в схеме, да и цели банально разные.

Задача password hashing состоит не в том, чтобы положить пароль в сейф на замок и спрятать, а в том, чтобы получить уникальный цифровой отпечаток пароля, по которому бы можно было проверить валидность предоставляемого пароля, и который не раскрывает какой-либо информации о самом пароле. Сам по себе отпечаток не является секретом, и Вы можете вывесить его хоть на главную страницу сайта.

Конечно же, Вам ничего не мешает потом этот отпечаток дополнительно зашифровать/захэшировать ещё раз, с использованием приватный ключей/секретных параметров/чего угодно. Но это уже действия вне рамок задачи password hashing, и с точки зрения самой задачи - бессмысленны, так как раскрытие отпечатка пароля не несет угрозы самому паролю.

[Юрий Чудновский]

Tyranron: Секретом является приватный ключ сертификата, и по сути он ничем не отличается от пароля. Имея публичную часть сертификата, злоумышленник может попробовать забрутфорсить приватную часть, проблема его лишь в том, что этот процесс достаточно длительный. Именно потому, что этот процесс не является невозможным принципиально, время жизни сертификатов ограничено, как правило, одним-двумя годами - считается, что за это время злоумышленники не успеют забрутить сертификат. Со временем производительность компьютеров возрастает, и это приводит к уменьшению времени брутфорса. Поэтому постепенно увеличивают длину ключей (благо сложность брутфорса возрастает экспоненциально, а мощность компьютеров растёт квадратично) или вводят другие, более трудоёмкие системы криптографии.

[Tyranron]

Юрий Чудновский: спасибо, что посвятили меня в тему сертификатов.

Любой шифр можно забрутфорсить обладая неограниченным ресурсом времени. Исключением является лишь одноразовый блокнот. Потому условие, что секрет нельзя подобрать за разумное время, и является решением почти всех криптографических задач. В этом задачи SSL и password hashing похожи, да. Но это не делает эти задачи эквивалентными нисколько.

Приватный ключ сертификата отличается от пароля в разрезе рассматриваемой схемы хотя бы тем, что приватным ключом сертификата обладает сервер, а паролем - клиент. У задач разные наборы секретов, и разные цели.

Answer 3

[Иван Филатов]

Соль не может быть рандомной! Иначе вы не сможете данные проверить, сгенерировать такую же соль.
Привязываться к данным пользователя тоже плохая идея. Он сменит что-либо, соль уже будет другая - а пароль генерировался от прошлой соли. Снова не совпадет ничего.

Вообще почитайте что такое Соль. Она может быть рандомной в самом начале, придумывании. Но потом она остается константой и прячется глубоко в backend системе. Если стоит задача сменить соль - то вначале вы должны расшифровать данные с помощью старой соли - и зашифровать на новую. И подменить на новую константу.

Comments

[StynuBlizz]

Ну я это и имел ввиду говоря рандомное)А поповоду хранения глубоко в беке,это где ?

[StynuBlizz]

А про генерацию по данным все просто,при смене имени пользователя соль заменяеться так-же как вы это и описали

[Иван Филатов]

1. Напишите микросервис, службу, которая знает про соль и умеет расшифровывать данные. Про него никто не знает, ну кроме сайта вашего. Сайт ходит на него используя ключи, сертификаты и т.д.
2. Сайт или сервис смотрит наружу. Про него знают все. Если его украдут, вместе с базой - то не смогут добраться до вашей службы с солью. Ключи хранить на флешке например, воткнутой в сервер ) или в защищенном хранилище сертификатов.

Главное не зашивать его в код жестко. Это проблема и безопасности и обновления/обслуживания.

[Иван Филатов]

StynuBlizz: соль обычно делают одну на всех. нет смысла усложнять.

[Иван Филатов]

StynuBlizz: у вас будет 1 000 000 пользователей - вы будете хранить 1 000 000 значений соли - зачем? где будете хранить? в БД ? ее украдут и пиши пропало.
Микросорвис станет узкозаточенным под ваш сайт - знающий 1 000 000 значений соли, а также связи с реальным человеком из БД. так не делают

[StynuBlizz]

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

[StynuBlizz]

Бутфорс будет делатья конкретно для одного человека а не всех,вот для чего

[StynuBlizz]

делаться*

[StynuBlizz]

Артём Петренков: Где рандомные соли хранить?В бд рядом с хэшем?

[Иван Филатов]

StynuBlizz: понял. Ну хорошо, делайте рандом соль. Но все равно надо выделять микросервис, отдельную БД под это дело. И желательно на сервер отдельный.
Как говориться, не хранить яйца в одной корзине.

А сама БД сайта - будет хранить только хеш и uid пользователя.
uid, пароль и hash шлем в микросервис, он там находит соль, делает шифрование - сравнивает - отдает ответ.

[Денис Загаевский]

Если стоит задача сменить соль - то вначале вы должны расшифровать данные с помощью старой соли - и зашифровать на новую. И подменить на новую константу.

Wat? Сразу видно, что вы "спец" по безопасности. Вся эта каша изначально заваривается для того, чтобы нельзя было расшифровать пароль. Криптографические хеш-функции, соль, вот это всё. Без смены пароля соль сменить нельзя. Можно изменить алгоритм генерации - плюсонуть к уже имеющемуся хешу новую соль и применить к этому ещё раз хеш-функцию. Соль хранить в БД рядом с хешем можно и нужно.

[Иван Филатов]

Денис Загаевский: ой прастите, гуру, великий, яндекс.
я имел в виду тот случай когда соль 1 шт. зашивают в код backend константой.

[Денис Загаевский]

Иван Филатов: перечитай ещё раз мой комментарий не зацикливаясь на месте моей работы. Какая разница, куда ты зашиваешь соль?

Answer 4

[Андрей]

Для безопасности "соль" генерируют рандомно и хранят рядом с паролем в базе. Можно дополнительно усложнить алгоритм добавив секретную величину - "перец", которая хранится отдельно.

Answer 5

[Tyranron]

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

Потому данные пользователя - так себе соль. Лучше не морочиться и сгенерировать случайную строку вменяемой длинны. Хранить вместе с хэшом.

Для каждого пароля - своя отдельная соль.

Все это уже реализовано в том же алгоритме хэширования паролей Bcrypt.

Подробный ответ на вопрос о хэшировании паролей давался уже в этом вопросе:
Как лучше всего шифровать пароли для сохранения в БД?
Вопрос соли там разобран тоже.

Comments

[StynuBlizz]

Зачем тогда соль должна быть сложно угадываемой?Она должна быть индивыдумально (ну и длины соотв-й) большего от неё не требуеться

[StynuBlizz]

индивидуальной

[Tyranron]

StynuBlizz: чтобы она гарантированно не входила в существующие радужные таблицы.
В ответе, на который, я сослался, разобран пример с солью "111", и детально расписано почему она плоха, будь она хоть 1000 раз индивидуальной.

[Tyranron]

StynuBlizz: соль из 20 единиц практически ничем не лучше соли из 3х единиц, если что.