Comments 12
Ссылки на источники можно оформить красивее, используя редактор Хабра.
Браузер(клиент) <-https-> сервер(php, go) + база(postgres)
В базе храним два столбца: хеш('qwerty') и индив.соль(48бит).
Во время аутентификации входной пароль также хешируется алгоритмом MD5 на стороне клиента аналогичным образом ...
Это на клиенте javascript_кодом, чтобы на сервер никогда (даже при регистрации) не попадал 'qwerty'?
Какой сейчас самый разумный кейс защиты (при авторизации и аутентификации), например, для крупного торгового сайта, bcrypt пользуют?
В порядке убывания предпочтения: argon2 scrypt bcrypt
Но это не значит, что bcrypt использовать нельзя. Для большинства сайтов bcrypt является оптимальным решением.
Если хранить одну соль на все пароли, но в защищенном месте (файле), то её могут 'вскрыть', предварительно зарегистрировавшись на сайте. С другой стороны, если хранить разные соли к паролям в базе, — то они уже на виду. Как правильно
усложнить взлом и укрепить защиту?
Как написано в статье — задача соли закрыть возможность перебора по радужным таблицам, а так же (вроде не написано) предотвратить появление одинаковых хешей в базе при одинаковых паролях. Для второй цели как раз важно, что бы соль была разная для каждого пароля. Причем, генерация соли — достаточно важный элемент вашего кода, что бы не потерять заложенную в соли энтропию. Стоит использовать криптографически надежные генераторы случайных данных для генерации соли.
Секретная соль — это немного другое, это вообще солью не стоит называть. Некий ключ, который усложняет подбор. На практике не используется, насколько я знаю, ибо любой ключ, который нельзя сменить — рано или поздно утекает.
Если уж говорить, о попытках защитить базу от офлайн подбора после ее утечки, то скорее стоит использовать симметричное шифрование хешированных паролей. При этом ни на йоту не ослабляя само хеширование. Ибо слой шифрования зависит от его компрометации. Но нормальная система шифрования — это несколько больше, чем несколько строчек кода и ключ в конфиге. Это определенные действия по защите ключа и системы ротации этого ключа с перешифрованием всей базы. Обычно затраты на эти действия считаются не оправданными по сравнению с вероятностью, что ваша база утекла, а до ключей шифрования не добрались.
то скорее стоит использовать симметричное шифрование хешированных паролей. При этом ни на йоту не ослабляя само хеширование.
т.е. в базе данных хранить два столбца:
индивид.соль(48бит) и argon2(пароль + соль) _?
просто не силён с термином: симметричное шифрование хешированных паролей…
Стоит использовать криптографически надежные генераторы случайных данных для генерации соли
в статье указывают на 48 бит, Вы не подскажете свой вариант, пример…
Кстати, для web-сервиса, насколько обременительны такие защиты для
быстродействия, например, если важна скорость отклика на клиенте, а
все запросы делать с проверкой 'от кого'.
Нет практики, не подскажете, где ждать грабли. Спасибо за помощь.
т.е. в базе данных хранить два столбца:
индивид.соль(48бит) и argon2(пароль + соль) _?
Нужно смотреть реализацию. Если реализация возвращает хеш в формате MCF (Modular Crypt Format) то там уже хранится все что нужно включая соль. Выглядит это как-то так $argon2i$v=19$m=1024,t=2,p=2$YzJBSzV4TUhkMzc3d3laeg$zqU/1IN0/AogfP4cmSJI1vc8lpXRW9/S0sYY2i2jHT0 — т.е. в самом начале алгоритм, потом параметры алгоритма, потом соль (YzJBSzV4TUhkMzc3d3laeg) и потом хеш.
просто не силён с термином: симметричное шифрование хешированных паролей…
Здесь я говорил о варианте, когда вы получаете хеш как обычно, а потом используете симметричное шифрование с ключом точно так же, как если бы шифровали любую другую строку. Но я бы не советовал вам пока с этим связываться.
в статье указывают на 48 бит, Вы не подскажете свой вариант, пример
Тут вопрос не только в размере, а в том, как эта строка генерируется. Опять же, нужно смотреть чем вы пользуетесь, какие там возможности. Например, у php password_hash сам генерирует соль и вам не нужно заботится об этом.
Кстати, для web-сервиса, насколько обременительны такие защиты для
быстродействия, например, если важна скорость отклика на клиенте, а
все запросы делать с проверкой 'от кого'.
Проверка пароля и проверка "от кого" — это совершенно разные вещи. Пароль вы проверяете один раз и после этого используете сессию для аутентификации.
Какую сложность выбрать для хеша (как долго он будет считаться) — в целом достаточно спорная тема, и могу лишь дать такую ссылку https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#work-factors
Хеши MD5 больше не считаются безопасными, и их не рекомендовано использовать для криптографической аутентификации.
А какие хэш алгоритмы сейчас рекомендуются для применения вместо MD5?
Секунду. Вывод о небезопасности хранения паролей в md5 сделан только на основе уязвимости md5 к поиску коллизий?
Анализ безопасности хранения и хеширования паролей при помощи алгоритма MD5