Мне интересно правильно ли я понимаю хеширование и соль, дайте

знать если я что-то говорю не так

1. Просто хешируя пароли ты подвергаешь себя опасности, того, что все твои хеши даже не нужно подбирать, они уже precomputed (raindow table)

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

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

? 4. Правильно ли я понимаю, что ещё лучшей идеей (в плане защиты) было бы динамически генерировать соль для каждого пользователя своим алгоритмом (например используя имя+возраст+дату регистрации в качестве соли). Таким образом соль не будет хранится в "доступном виде" в хеше и достать её будет ещё сложнее? И следовательно получить доступ к паролям.

3 пункт это как?

Это как делают в большинстве случаев, самый популярный метод?

Это первый пункт

2. Я бы уточнил, что тут проблема будет в том, что у пользователей с одинаковым паролем получается одинаковый хэш 4. Нет, это бесполезно, все равно понятно будет по коду, как именно получается соль. Более того, узнав это, ты узнаешь соль всех пользователей, даже не имея их хэша. Соль должна быть случайная. Ну и универсальное правило, если какое-то решение для безопасности перестанет работать, если твое приложение будет с открытым исходным кодом, то это решение совершенно не безопасное

Совершенно безопасно – это защищать свой уровень данных разделением на r/w реплики, с автоматизированным контролем доступов к «мордам». ДевОпс команда из ВК такую штуку сделала – вот там да, уровень секьюрности – моё почтение.

Это разве не любая девопс команда делает? 🤔 Только обсуждение про другое идёт. Разделение на реплики не связано с безопасностью

Алексей, Вы, я думаю, удивитесь, но не каждая ДевОпс команда делает ту же систему, что делали ребята из ВК. Там система добротная, а не «ключики храним тута, парольчики выключаем, впсочки в приватную сеточку»

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

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

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

Это в целом важный нюанс. В безопасности сокрытие метода защиты не является само по себе защитой. Получение доступа к исходному коду не тоже самое, что получение доступа к содержимому базы данных. Исходный код доступен: - Всем для опен сорс проектов - Всем разработчикам - Всем сисадминам, девопсам и тп - Владельцу провайдера сервера Содержимое базы данных - не должно быть доступно кому не нужно. > Насчёт того что узнается соль сразу всех. Ну в случае со случайной солью, то ситуация ведь идентична в плане того, что соль сразу можно узнать, она ведь сама в хеше то и хранится или ты знаешь какую-то другую реализацию? Дело не в том, как сложно узнать соль, а в том, что хэши получаются одинаковые. Есть Вася с паролем qwerty. С солью SALT получился хэш ABACABA. Есть Катя с паролем qwerty. Если у неё тоже соль SALT, то хэш тоже ABACABA. Если вдруг утечёт содержимое базы (это не только хакеры, но и недобросовестные сотрудники с доступом), то Катя теперь из-за своего пароля знает ВСЕХ у кого такой же.

Я знаю, я совсем не про это

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

твой алгоритм никому не известен пока не утечёт исходник

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

Генерируя соль на основе сенситив данных ты для сравнения хэшей должен будешь доставать эти сенсетив данные откуда-то. Например, на форме входа в сервис, предлагая ввести пароль ещё придётся: 1. запросить "имя+возраст+дату регистрации" 2. построить по ним соль 3. сделать хэш с солью 4. и вот только после этого сравнить хэши

Да, все правильно)

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

Согласен, но мне сейчас больше не юзабилити, а безопасность интересна

Предлагаю тогда, заменить сенситив данные ещё одним паролем 😅

Григорий, у меня всё ещё это в голове не укладывается, поясни если не затруднит, что всё таки безопаснее, как ты думаешь?

Из совсем простых проблем: 1. Если ты в соль добавляешь определённую часть, которая определяется изменяемыми данными - всё ломается при изменении. (Юзер поменял имя, соль сломалась). 2. Если там используется только общие не уникальные данные, то проблема с повторениями. (Юзеры с одинаковым именем в разных сервисах имеют одинаковую соль) То есть надо что-то, что не меняется никогда и при этом уникально, типа UUID юзера. 3. Проще делать rainbow таблицы и перебор. С солью в целом сложнее сделать rainbow таблицу. Но одно дело, если у тебя соль - это айдишник юзера, который условно от 0 до 1000 000 И другое, если соль - случайное число с овер9999 значений

Что если моя соль это дата регистрации пользователя + uuid под каким нибудь кастомным хешом + по желанию рандомная соль, будет ли это безопасней и есть ли у этого недостатки? Данные вроде не изменяются, rainbow table строить ещё сложнее из-за того, что соль не взять из хеша напрямую, что думаешь?)

Что значит "по желанию"?

^