Tyranron: Секретом является приватный ключ сертификата, и по сути он ничем не отличается от пароля. Имея публичную часть сертификата, злоумышленник может попробовать забрутфорсить приватную часть, проблема его лишь в том, что этот процесс достаточно длительный. Именно потому, что этот процесс не является невозможным принципиально, время жизни сертификатов ограничено, как правило, одним-двумя годами - считается, что за это время злоумышленники не успеют забрутить сертификат. Со временем производительность компьютеров возрастает, и это приводит к уменьшению времени брутфорса. Поэтому постепенно увеличивают длину ключей (благо сложность брутфорса возрастает экспоненциально, а мощность компьютеров растёт квадратично) или вводят другие, более трудоёмкие системы криптографии.
Артём Петренков: Вот, разговор уже обретает конструктивную форму.
Как вы понимаете, даже защищённый паролем приватный ключ, если утёк, рано или поздно будет забрутфорсен.
Писать собственный код без ошибок или проводить аудит безопасности после каждого деплоя - фантастика.
Провести один раз аудит безопасности после поднятия сервера или даже просто нанять грамотного админа - гораздо реалистичнее, поэтому на динамичном развивающемся проекте можно априори считать, что рано или поздно программистами БУДЕТ допущена ошибка приводящая к утечке базы, в то время как вероятность взлома сервера с полным контролем со стороны хакеров - маловероятное событие. Именно поэтому соль в базе не защищает от утечки паролей, соль в отдельном файле даёт ступень защиты, которая в грамотном исполнении позволит сохранить пароли пользователей в тайне даже после ошибки программистов.
В случае взлома сервера целиком, никакие меры не защитят ничего, поэтому этот вариант развития событий и нечего рассматривать - тут уж хоть действительно пароли в открытом виде, разницы не будет кроме как время от взлома до публикации взломщиками паролей.
suid не является какой-то магией. Когда вы запускаете бинарник, его запускает система, и она обрабатывает этот бит. Когда же вы запускаете скрипт, система запускает интерпретатор, от имени пользователя, передавая ему параметром скрипт на исполнение.
Что может запущенный интерпретатор, работая с правами пользователя, даже если он "видит" suid бит на файле скрипта? Ничего кроме как продолжить его выполнять от текущего пользователя.
Артём Петренков: Хорошо, раз аналогия с паролем вам не понятна, то заменим пароли на приватную часть SSL сертификатов.
"Приватный ключ сертификата SSL является, по сути, частью алгоритма хеширования (верно). Соответственно, степень защищённости системы зависит от дополнительного секрета (т.е. приватного ключа), то есть такая схема (SSL) реализует концепцию "безопасность через неясность" - security by obscurity (неверно)"
Эта ваши слова, в которых я заменил "дополнительный секрет" (статичную соль в конфиге) на "приватный ключ сертификата SSL".
Теперь вы видите, что вы фактически, утверждая одно, утверждали и логически то же самое другое - "SSL/пароли/итд - security by obscurity"?
Если всё ещё не очевидно это вам, то можем рассмотреть аналогию с сейфом и ключами к нему. По-вашему получится, что любой сейф это security by obscurity, если к нему есть где-то ключ, ведь ключ можно сп..., ну, сейф не надёжнее чем способ хранения ключа. Но ведь если ключ хорошо защищён, то сейф надёжен, так? Тогда получится, возвращаясь к нашей базе, где база - сейф с паролями, ключ - соль в конфиге, то база защищена настолько, насколько защищён ключ, то есть конфиг. И поскольку грамотно настроенный админами сервер довольно надёжен, получаем что соль в конфиге достаточно надёжно защищает пароли от взлома даже в случае утечки базы из-за ошибки программистов. Что и требовалось доказать.
Артём Петренков: В том-то и дело, что согласно этому принципу знание того, что где-то на сервере лежит статичная соль, никак не меняет сложности взлома сервера. А без взлома сервера невозможно расшифровать базу. Никакие знания о алгоритме хэширования, типе файловой системы, на котором лежит конфиг с солью, или цвета трусов админа вам никак не помогут в брутфорсе базы.
Фактически, вы утверждаете что пароли - security by obscurity, ведь "стойкость аутентификации зависит от компрометации этого пароля", но я надеюсь что хоть на этот раз абсурдность утверждения вам будет очевидна.
Артём Петренков: Ваши рассуждения неверны. Соль в базе (первая по терминологии статьи на хабре) всего лишь заставляет брутить все пароли, но никак не усложняет сам брутфорс. Если пароли не повторяются, то эта соль вообще бесполезна, она в таком случае просто ничего не делает. Поэтому это и есть security by obscurity.
Вторая соль, которая хранится отдельно, защищает пароли от брутфорса в случае утечки базы. Взлом сервера для получения доступа к этой соли - гораздо более сложная процедура, чем нахождение банальной sql injection уязвимости или аналогичной. Без получения второй соли брутфорс слитой базы просто бесполезен. Поэтому такая соль - НЕ security by obscurity.
Артём Петренков: Ошибаюсь или нет, но вторая соль, всегда хранимая отдельно от базы и без которой забрутить пароли невозможно, никак не может быть security by obscurity.
Артём Петренков: Понимаю. При получении доступа к базе скрипткидсами/ботом брутфорс паролей не получится, но человек который увидит что в базе есть ещё и соль, забрутит пароли ничуть не медленней чем без неё, в первом приближении (т.е. без учёта одинаковых паролей). Это и есть security by obscurity.
Артём Петренков: как раз первая соль - security by obscurity, так как утечка базы автоматически её раскрывает (при хранении в той же базе). При хранении первой соли не в базе - она всё равно не сильнее второй, так как взлом сервера полностью (с доступом к файлам скриптов, конфигам и т.п.) раскрывает обе соли.
Артём Петренков: Разумеется, если уж солить - то по максимуму, первая соль лишь заставляет брутфорсить все пароли, скрывая одинаковые, а вторая соль заставляет взломать сервак полностью. Вторая соль, следовательно, сильнее первой, поэтому маст хэв. Без неё слитая база бесполезна. Первая соль не настолько полезна, но паркуа бы не па.
Артём Петренков: Ну что поделать, статья не очень удачная в этом плане, но вы всё же могли заметить что там говорится "Это по сути «вторая соль» дописывается ко всем (паролям+соль) конструкциям, и является одинаковой для всех хешей в базе". Именно эта соль защищает от быстрого вскрытия паролей утёкшей базы. Первая соль только лишь маскирует одинаковые пароли, чтобы нельзя было вскрыв один хэш автоматически найти все аккаунты с таким же паролем. Возможно вы про "первую" соль говорите, а я говорил про "вторую".
StynuBlizz: соль обычно хранят в отдельном файле настроек. Чтобі получить соль, хакеру потребуется не просто получить доступ к базе, но и заиметь возможность записать свой файл (скрипт), который он смог бы запустить на сервере и через который он смог бы получить соль.
Вы не можете использовать какие-то данные клиента в качестве соли. Собственно, единственные данные которые неизменны (а это требование для соли) - это логин пользователя (если его нельзя изменить пользователю), а это общедоступная информация и солью быть не может.
Конкретно, вот эта строчка: "try_files $uri $uri/ /index.php?q=$uri&$args" сперва пробует указанный браузером урл, затем то же с добавлением слеша в конец, и если ни то ни другое не действительно, то вызывается index.php с параметром в виде урла.
