Если пароль сильный, то необходимая сложность будет уже досигнута. И костыль не нужен.
Если пароль слабый — тогда костыль в виде «локального параметра» может с некоторой долей вероятности предотвратить утечку слабых паролей. Однако всякий, кто полагается на авось («авось не доломают до локального параметра») должен ясно представлять себе риски такого подхода. И оговаривать их в статье, если уж взялся поучать других.
Ещё раз. Мы десь не говорим об атаке на пароль. Оставьте голову пользователя в покое.
В данном топике обсуждается стойкость по определению доступных хакеру данных.
Речь о защите хэша, а не пароля.
Хороший хэш в костылях не нуждается. Он защищен сам по себе.
Локальный параметр — детский лепет «а вот мы спрячемся и никто нас не найдет». Вся защита строится на допущениях. Утверждение «чтобы получить локальный параметр, нужно иметь локальный доступ» ничем принципиально не отличается от утверждения «чтобы получить дамп базы, надо получить доступ к базе». И то и другое — допущения.
При анализе защиты всегда предполагается худший сценарий. Защита «локальным параметром» такую проверку не проходит. Защита стойким паролем — проходит. Это — принципиальная разница.
Если вы не в состоянии этого понять, то продолжать бесполезно.
В случае с электронной подписью не требуется никаких «секретных локальных параметров». Есть условная «голова пользователя» и открытый ключ. Всё. Даже «доступ к БД» не требуется, не говоря уже ни о каких «апп-серверах» — всё и так открыто.
Давайте вы сначала поучите всех операторов электронных подписей, как правильно организовывать безопасность — хранить открытый ключ в закрытой БД, а еще один дополнительный открытый ключ в ещё одной дополнительной БД. И если они согласятся, что да — так надёжнее — то мы вернёмся к этому вопросу.
Зависит. При стойком пароле локальный параметр не нужен. Его выдумали какие-то доморощенные «эксперты» и носятся с ним, как с писаной торбой. Нормально защищённая система в таких костылях не нуждается.
Я предлагаю на протяжении всего этого топика.
Для хэша, который не имеет заведомо слабых звеньев, весь этот детский лепет с «локальными параметрами», «повышающими» базопасность становится ненужным.
А «чтобы поломать нашу систему надо найти иголку, которая в яйце, яйцо в утке, утка в зайце, заяц в а… фиге» — это классическая security through obscurity.
Само наличие условий «чтобы… надо» — уже говорит о заведомой скомпрометированности подхода. В действительно защищенной системе нету никаких «если». И «повышать» её безопасность не требуется.
Хранение частей соли отдельно означает, что мы сознательно вносим в систему слабое звено — нестойкий пароль, а дальше занимаемся классической security through obscurity — начинаем выдумывать всякие способы для повышения стойкости нашей заведомо нестойкой системы.
В то время как для случая элекстронной подписи никто не занимается такими детскими играми в секретики, внося в систему некий третий «локальный параметр», помимо собственно субъектов защиты — польователя и его данных.
Для системы хэширования паролей, у который все три составляющие не скомпрометированы —
1. медленный хэш против перебора
2. уникальная соль против радуги
3. сложный пароль против словаря и перебора
— эти детские игры, опять же, становятся не нужны.
Я, разумеется, согласен, что всякие «локальные параметры» — это tradeoff в пользу юзабилити. Но об этом надо прямо и честно заявлять, а не стыдливо прятать голову в песок, прикрываясь кучей ничего не значащих терминов, выдавая заведомо нестойкую систему за эквивалент заведомо стойкой.
И в этом контексте реакция местных завсеггдатаев меня поражает. Ну, то есть, понятно, что она-то как раз неудивительна. Но всё равно, всякий раз сталкиваясь со столь массовым невежеством и неумением отличить заведомо нестойкую систему, которой требуется «повышение» стойкости, от заведомо стойкой, которой такие костыли не нужны — как-то становится не по себе.
Количество фантазёров, беседующих сами с собой, уже начинает напрягать.
Нет — я всё понимаю. Беда больших сайтов, эффект толпы и всё такое. Но топик как бы тоже не про цену морковки на рынке. Предполагает некоторое умение концентрироваться на проблеме и логически мыслить. А не выхватывать из контекста одно-два слова и изливать в ответ набор банальностей.
Нигде я не писал, что известная атакующему соль равна отсутствующей в общем случае. Если дать себе труд прочесть переписку, которую взялся комментировать, там будет написано:
Сказывается ли наличие соли на стойкости паролей вида 12345,
Ответ, рождённый работой мысли, а не бездумным повторением заученных мантр — нет. В базе John the Ripper пароль 12345 стоит на втором месте. Что означает практически полное отсутствие задержки при взломе. Перебор по всей базе в 3,5К также не будет медленнее перебора про радуге. Из чего можно сделать тот самый вывод, о котором я говорю с самого начала этой занимательной дискуссии — для паролей вида 12345 наличие соли не сказывается на стойкости.
Я не знаю, КАК надо читать, чтобы "известная атакующему соль" прочесть как "отсутствующая".
Но если все ваши претензии сводятся к этому, то вы меня очень обяжете, если избавите от необходимости копаться в ваших фантазиях.
Ответ: Не сказывается. Станет. Чтобы понять — почему, надо понять разницу между брутфорсом и перебором по словарю. Это не так сложно.
Особенно если внезапно! не две базы, а одна. И с солью.
Но сам неожиданный ход мысли мне понравился. Воображаем себе хакера в ресторане, где ему предлагают на выбор две базы — с солью и без. И на том основании, что он выберет ту из них, которая никак не относится к обсуждаемой теме, с блеском докажем несостоятельность доводов оппонента. Люблю когда у автора хорошо с фантазией.
Это ерунда, а не аналог второго пароля.
«второй пароль» — это та же соль. Которая просто хранится отдельно. И её утеря, при соблюдении всех правил, никак не скажется на стойкости хэша.
Утеря же закрытого ключа гарантированно компрометирует все подписанные документы. Неужели даже в запале желания во что бы то ни стало уесть оппонента не видно разницы? Ну, жаль. Всё-таки, ололо побеждает разум.
Это хождение по кругу.
Просто вместо password становится Hs(password, salt).
Если для входа на сервер нам надо знать не пароль, а хэш — то хэш теперь становится тем «паролем», зная который, можно войти на сервер. И в итоге этот «пароль» хранится на сервере в открытом виде.
про «введённое пользователем» — это тоже лишнее, и ведёт к инъекциям.
Так что просто «никогда не подставлять в запросы непосредственно ничего». Точка.
А только через плейсхолдер или белый список.
И плюс ещё про Digest авторизацию (которая challenge-response) — она, увы, несовместима с хэшированием паролей. Поэтому — только SSL. Тем более, что это совсем несложно.
Существует несколько общепринятых объяснений.
Одно из них — болшинство хомячков имеет один и тот же пароль подо все сервисы => можно уводить мыло, твиттер и пр.
Или, авторизовавшись можно получить доступ на запись, а слив мог быть произведён только через чтение — и пр.
Эм. Что мы имеем в виду под «всеми» компонентами?
Грубо, закрытый ключ — это аналог пароля. Если он известен атакующему, то все остальное становится ненужным. Мы говорим о взломе или о чём?
Если не устраивает ответ, то тогда стоит конкретизировать вопрос.
К сожалению, вы не поняли обсуждаемого вопроса.
Точно так же я могу задать встречный вопрос — «Есть хэши, но соль неизвестна. Предлагаю размяться».
Или — «есть база, пароли лежат в открытом виде». Узнайте пароли.
При анализе уязвимости надо всегда предполагать худший сценарий. Тот факт, что я не откадаю пароль в вашей задачке, никак не поможет человеку, у которого скомпрометированным окажется «секретный» параметр.
А игры «отгадай число, которое я задмуал» стоит оставить для детского сада.
Если пароль слабый — тогда костыль в виде «локального параметра» может с некоторой долей вероятности предотвратить утечку слабых паролей. Однако всякий, кто полагается на авось («авось не доломают до локального параметра») должен ясно представлять себе риски такого подхода. И оговаривать их в статье, если уж взялся поучать других.
В данном топике обсуждается стойкость по определению доступных хакеру данных.
Речь о защите хэша, а не пароля.
Хороший хэш в костылях не нуждается. Он защищен сам по себе.
Локальный параметр — детский лепет «а вот мы спрячемся и никто нас не найдет». Вся защита строится на допущениях. Утверждение «чтобы получить локальный параметр, нужно иметь локальный доступ» ничем принципиально не отличается от утверждения «чтобы получить дамп базы, надо получить доступ к базе». И то и другое — допущения.
При анализе защиты всегда предполагается худший сценарий. Защита «локальным параметром» такую проверку не проходит. Защита стойким паролем — проходит. Это — принципиальная разница.
Если вы не в состоянии этого понять, то продолжать бесполезно.
Давайте вы сначала поучите всех операторов электронных подписей, как правильно организовывать безопасность — хранить открытый ключ в закрытой БД, а еще один дополнительный открытый ключ в ещё одной дополнительной БД. И если они согласятся, что да — так надёжнее — то мы вернёмся к этому вопросу.
Для хэша, который не имеет заведомо слабых звеньев, весь этот детский лепет с «локальными параметрами», «повышающими» базопасность становится ненужным.
А «чтобы поломать нашу систему надо найти иголку, которая в яйце, яйцо в утке, утка в зайце, заяц в а… фиге» — это классическая security through obscurity.
Само наличие условий «чтобы… надо» — уже говорит о заведомой скомпрометированности подхода. В действительно защищенной системе нету никаких «если». И «повышать» её безопасность не требуется.
В то время как для случая элекстронной подписи никто не занимается такими детскими играми в секретики, внося в систему некий третий «локальный параметр», помимо собственно субъектов защиты — польователя и его данных.
Для системы хэширования паролей, у который все три составляющие не скомпрометированы —
1. медленный хэш против перебора
2. уникальная соль против радуги
3. сложный пароль против словаря и перебора
— эти детские игры, опять же, становятся не нужны.
Я, разумеется, согласен, что всякие «локальные параметры» — это tradeoff в пользу юзабилити. Но об этом надо прямо и честно заявлять, а не стыдливо прятать голову в песок, прикрываясь кучей ничего не значащих терминов, выдавая заведомо нестойкую систему за эквивалент заведомо стойкой.
И в этом контексте реакция местных завсеггдатаев меня поражает. Ну, то есть, понятно, что она-то как раз неудивительна. Но всё равно, всякий раз сталкиваясь со столь массовым невежеством и неумением отличить заведомо нестойкую систему, которой требуется «повышение» стойкости, от заведомо стойкой, которой такие костыли не нужны — как-то становится не по себе.
Нет — я всё понимаю. Беда больших сайтов, эффект толпы и всё такое. Но топик как бы тоже не про цену морковки на рынке. Предполагает некоторое умение концентрироваться на проблеме и логически мыслить. А не выхватывать из контекста одно-два слова и изливать в ответ набор банальностей.
Нигде я не писал, что известная атакующему соль равна отсутствующей в общем случае. Если дать себе труд прочесть переписку, которую взялся комментировать, там будет написано:
Ответ, рождённый работой мысли, а не бездумным повторением заученных мантр — нет. В базе John the Ripper пароль 12345 стоит на втором месте. Что означает практически полное отсутствие задержки при взломе. Перебор по всей базе в 3,5К также не будет медленнее перебора про радуге. Из чего можно сделать тот самый вывод, о котором я говорю с самого начала этой занимательной дискуссии — для паролей вида 12345 наличие соли не сказывается на стойкости.
Но если все ваши претензии сводятся к этому, то вы меня очень обяжете, если избавите от необходимости копаться в ваших фантазиях.
Особенно если внезапно! не две базы, а одна. И с солью.
Но сам неожиданный ход мысли мне понравился. Воображаем себе хакера в ресторане, где ему предлагают на выбор две базы — с солью и без. И на том основании, что он выберет ту из них, которая никак не относится к обсуждаемой теме, с блеском докажем несостоятельность доводов оппонента. Люблю когда у автора хорошо с фантазией.
«второй пароль» — это та же соль. Которая просто хранится отдельно. И её утеря, при соблюдении всех правил, никак не скажется на стойкости хэша.
Утеря же закрытого ключа гарантированно компрометирует все подписанные документы. Неужели даже в запале желания во что бы то ни стало уесть оппонента не видно разницы? Ну, жаль. Всё-таки, ололо побеждает разум.
Просто вместо password становится Hs(password, salt).
Если для входа на сервер нам надо знать не пароль, а хэш — то хэш теперь становится тем «паролем», зная который, можно войти на сервер. И в итоге этот «пароль» хранится на сервере в открытом виде.
Так что просто «никогда не подставлять в запросы непосредственно ничего». Точка.
А только через плейсхолдер или белый список.
И плюс ещё про Digest авторизацию (которая challenge-response) — она, увы, несовместима с хэшированием паролей. Поэтому — только SSL. Тем более, что это совсем несложно.
поэтому, чтобы не выбирать из двух зол — только шифрование канала.
Одно из них — болшинство хомячков имеет один и тот же пароль подо все сервисы => можно уводить мыло, твиттер и пр.
Или, авторизовавшись можно получить доступ на запись, а слив мог быть произведён только через чтение — и пр.
Грубо, закрытый ключ — это аналог пароля. Если он известен атакующему, то все остальное становится ненужным. Мы говорим о взломе или о чём?
Если не устраивает ответ, то тогда стоит конкретизировать вопрос.
Точно так же я могу задать встречный вопрос — «Есть хэши, но соль неизвестна. Предлагаю размяться».
Или — «есть база, пароли лежат в открытом виде». Узнайте пароли.
При анализе уязвимости надо всегда предполагать худший сценарий. Тот факт, что я не откадаю пароль в вашей задачке, никак не поможет человеку, у которого скомпрометированным окажется «секретный» параметр.
А игры «отгадай число, которое я задмуал» стоит оставить для детского сада.
— В контексте моей модели задача решена не для скачек вообще, а для случая сферического коня в вакууме.
=)