Еще раз.
Перед G должен стоять слеш, как в моем примере. Тогда вывод будет такой же, как в статье.
Примеры не исполняются. Таблицы city нет вообще. Можно догадаться что она просто в качестве иллюстрации, но все равно неаккуратно. Для приведенного же дампа запросы исполняются, но заявленный вывод не выдают — все останавливается на Impossible WHERE noticed after reading const tables.
Код в статье надо форматировать
Интересно, что в оригинале потерялся слеш перед G (похоже, на сайтпонте не умеют форматировать текст для SQL или HTML), а в переводе пропала и сама буква. А вместе с ней и самый первый запрос —
EXPLAIN SELECT * FROM categories\G
В итоге для многих может быть непонятно, откуда взялся вертикальный формат вывода результатов запроса.
И код в статье, вообще-то, желательно форматировать.
А сама статья неудачная. Объяснений очень мало, примеры я попробовал — не исполняются.
Лучше читать книгу или презентации svetasmirnova
Дело в том, что «обозначение вектора» — это шулерство.
ЕСЛИ БЫ в статье действительно рассматривалась атака только система «хакер — БД», то это была бы просто неполная и бесполезная статья.
Но, увы, стаья не ограничивает себя на самом деле рамками атаки на базу. Поскольку САМА ЖЕ вводит такую сущность, «атака на приложение». И это уже превращается в шулерство.
Автор говорит — «а вот предположим, что у нас есть приложение, которое никто не поломает. и тогда мы в него положим секретный ключ». Это уже чушь и обман читателей.
Это, конечно, замечательный способ писать статьи — выделить в защищаемом объекте условно «ломаемую» часть и условно «защищенную», возложить обязанности по защите на вторую — и вуаля! — проблема решена. Но объяснить хакеру, в отличие от незадачливых читателей, что «здесь я играю, а здесь — в домике» будет затруднительно.
Окна — неверная аналогия. Если есть возможность положить вещь в сейфовую ячейку, бронированную со всех сторон, то окон там не будет. И самообмана не будет.
А вот если делать, как автор статьи — ставить дверь, а про окна сказать «этаж у нас 22-й, никто не залезет» — это-то и будет самообман. Так понятнее?
Учитывая же отношение автора к сейфовой ячейке — сугубо негативное — статья получается и откровенно вредная.
Слабый не превращается в сильный.
Сильному превращаться в «очень сильный» не нужно. Да и не превращается он. Это самообман.
Про сферический вектор атаки я уже комментировал. Осталось злоумышленнику рассказать, что он обязан атаковать только БД, а остальное — ни-ни!
(Вы это — вообще понимаете, какую чушь сейчас несете, с этим своим «вектор атаки обозначен»? Пишем статью про защту от SQL инъекций и обозначаем вектор — атакуем только строки в запросе. польза от такой защиты и статьи — просто небывалая).
Для тех, кто решил поучаствовать в дискуссии, не понимая, о чем она: соль заранее считается скомпрометированной. Сам принцип использования соли предполагает это, он на этом основан. Тот же рекомендуемый в статье bccrypt кладёт её в одну строку с возвращаемым хэшем.
Частые вопросы о соли для новичков
— Где хранить соль? Не опасно ли хранить ее в открытом виде? Можно ли поместить соль в код и ее использовать для всех паролей?
— Все, что может быть украдено, будет украдено. Если вы уверены в защищенности кода, то свой алгоритм хеширования поможет лучше соли. Помните: соль не защищает один конкретный хеш от перебора, поэтому нет цели прятать соль — она хранится в открытом виде рядом с хешем. Задача соли — спасти набор украденных хешей, «удлиняя» пароль, а сделать она это может только в том случае, если у каждого хеша будет своя соль. Поэтому мы храним соль рядом с хешем и для каждого хеша генерируем свою уникальную последовательность символов соли.
Если пароль сильный, то необходимая сложность будет уже досигнута. И костыль не нужен.
Если пароль слабый — тогда костыль в виде «локального параметра» может с некоторой долей вероятности предотвратить утечку слабых паролей. Однако всякий, кто полагается на авось («авось не доломают до локального параметра») должен ясно представлять себе риски такого подхода. И оговаривать их в статье, если уж взялся поучать других.
Ещё раз. Мы десь не говорим об атаке на пароль. Оставьте голову пользователя в покое.
В данном топике обсуждается стойкость по определению доступных хакеру данных.
Речь о защите хэша, а не пароля.
Хороший хэш в костылях не нуждается. Он защищен сам по себе.
Локальный параметр — детский лепет «а вот мы спрячемся и никто нас не найдет». Вся защита строится на допущениях. Утверждение «чтобы получить локальный параметр, нужно иметь локальный доступ» ничем принципиально не отличается от утверждения «чтобы получить дамп базы, надо получить доступ к базе». И то и другое — допущения.
При анализе защиты всегда предполагается худший сценарий. Защита «локальным параметром» такую проверку не проходит. Защита стойким паролем — проходит. Это — принципиальная разница.
Если вы не в состоянии этого понять, то продолжать бесполезно.
В случае с электронной подписью не требуется никаких «секретных локальных параметров». Есть условная «голова пользователя» и открытый ключ. Всё. Даже «доступ к БД» не требуется, не говоря уже ни о каких «апп-серверах» — всё и так открыто.
Давайте вы сначала поучите всех операторов электронных подписей, как правильно организовывать безопасность — хранить открытый ключ в закрытой БД, а еще один дополнительный открытый ключ в ещё одной дополнительной БД. И если они согласятся, что да — так надёжнее — то мы вернёмся к этому вопросу.
Зависит. При стойком пароле локальный параметр не нужен. Его выдумали какие-то доморощенные «эксперты» и носятся с ним, как с писаной торбой. Нормально защищённая система в таких костылях не нуждается.
Я предлагаю на протяжении всего этого топика.
Для хэша, который не имеет заведомо слабых звеньев, весь этот детский лепет с «локальными параметрами», «повышающими» базопасность становится ненужным.
А «чтобы поломать нашу систему надо найти иголку, которая в яйце, яйцо в утке, утка в зайце, заяц в а… фиге» — это классическая 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. Тем более, что это совсем несложно.
Перед G должен стоять слеш, как в моем примере. Тогда вывод будет такой же, как в статье.
Примеры не исполняются. Таблицы city нет вообще. Можно догадаться что она просто в качестве иллюстрации, но все равно неаккуратно. Для приведенного же дампа запросы исполняются, но заявленный вывод не выдают — все останавливается на Impossible WHERE noticed after reading const tables.
Код в статье надо форматировать
В итоге для многих может быть непонятно, откуда взялся вертикальный формат вывода результатов запроса.
И код в статье, вообще-то, желательно форматировать.
А сама статья неудачная. Объяснений очень мало, примеры я попробовал — не исполняются.
Лучше читать книгу или презентации svetasmirnova
ЕСЛИ БЫ в статье действительно рассматривалась атака только система «хакер — БД», то это была бы просто неполная и бесполезная статья.
Но, увы, стаья не ограничивает себя на самом деле рамками атаки на базу. Поскольку САМА ЖЕ вводит такую сущность, «атака на приложение». И это уже превращается в шулерство.
Автор говорит — «а вот предположим, что у нас есть приложение, которое никто не поломает. и тогда мы в него положим секретный ключ». Это уже чушь и обман читателей.
Это, конечно, замечательный способ писать статьи — выделить в защищаемом объекте условно «ломаемую» часть и условно «защищенную», возложить обязанности по защите на вторую — и вуаля! — проблема решена. Но объяснить хакеру, в отличие от незадачливых читателей, что «здесь я играю, а здесь — в домике» будет затруднительно.
Окна — неверная аналогия. Если есть возможность положить вещь в сейфовую ячейку, бронированную со всех сторон, то окон там не будет. И самообмана не будет.
А вот если делать, как автор статьи — ставить дверь, а про окна сказать «этаж у нас 22-й, никто не залезет» — это-то и будет самообман. Так понятнее?
Учитывая же отношение автора к сейфовой ячейке — сугубо негативное — статья получается и откровенно вредная.
Сильному превращаться в «очень сильный» не нужно. Да и не превращается он. Это самообман.
Про сферический вектор атаки я уже комментировал. Осталось злоумышленнику рассказать, что он обязан атаковать только БД, а остальное — ни-ни!
(Вы это — вообще понимаете, какую чушь сейчас несете, с этим своим «вектор атаки обозначен»? Пишем статью про защту от SQL инъекций и обозначаем вектор — атакуем только строки в запросе. польза от такой защиты и статьи — просто небывалая).
Если пароль слабый — тогда костыль в виде «локального параметра» может с некоторой долей вероятности предотвратить утечку слабых паролей. Однако всякий, кто полагается на авось («авось не доломают до локального параметра») должен ясно представлять себе риски такого подхода. И оговаривать их в статье, если уж взялся поучать других.
В данном топике обсуждается стойкость по определению доступных хакеру данных.
Речь о защите хэша, а не пароля.
Хороший хэш в костылях не нуждается. Он защищен сам по себе.
Локальный параметр — детский лепет «а вот мы спрячемся и никто нас не найдет». Вся защита строится на допущениях. Утверждение «чтобы получить локальный параметр, нужно иметь локальный доступ» ничем принципиально не отличается от утверждения «чтобы получить дамп базы, надо получить доступ к базе». И то и другое — допущения.
При анализе защиты всегда предполагается худший сценарий. Защита «локальным параметром» такую проверку не проходит. Защита стойким паролем — проходит. Это — принципиальная разница.
Если вы не в состоянии этого понять, то продолжать бесполезно.
Давайте вы сначала поучите всех операторов электронных подписей, как правильно организовывать безопасность — хранить открытый ключ в закрытой БД, а еще один дополнительный открытый ключ в ещё одной дополнительной БД. И если они согласятся, что да — так надёжнее — то мы вернёмся к этому вопросу.
Для хэша, который не имеет заведомо слабых звеньев, весь этот детский лепет с «локальными параметрами», «повышающими» базопасность становится ненужным.
А «чтобы поломать нашу систему надо найти иголку, которая в яйце, яйцо в утке, утка в зайце, заяц в а… фиге» — это классическая security through obscurity.
Само наличие условий «чтобы… надо» — уже говорит о заведомой скомпрометированности подхода. В действительно защищенной системе нету никаких «если». И «повышать» её безопасность не требуется.
В то время как для случая элекстронной подписи никто не занимается такими детскими играми в секретики, внося в систему некий третий «локальный параметр», помимо собственно субъектов защиты — польователя и его данных.
Для системы хэширования паролей, у который все три составляющие не скомпрометированы —
1. медленный хэш против перебора
2. уникальная соль против радуги
3. сложный пароль против словаря и перебора
— эти детские игры, опять же, становятся не нужны.
Я, разумеется, согласен, что всякие «локальные параметры» — это tradeoff в пользу юзабилити. Но об этом надо прямо и честно заявлять, а не стыдливо прятать голову в песок, прикрываясь кучей ничего не значащих терминов, выдавая заведомо нестойкую систему за эквивалент заведомо стойкой.
И в этом контексте реакция местных завсеггдатаев меня поражает. Ну, то есть, понятно, что она-то как раз неудивительна. Но всё равно, всякий раз сталкиваясь со столь массовым невежеством и неумением отличить заведомо нестойкую систему, которой требуется «повышение» стойкости, от заведомо стойкой, которой такие костыли не нужны — как-то становится не по себе.
Нет — я всё понимаю. Беда больших сайтов, эффект толпы и всё такое. Но топик как бы тоже не про цену морковки на рынке. Предполагает некоторое умение концентрироваться на проблеме и логически мыслить. А не выхватывать из контекста одно-два слова и изливать в ответ набор банальностей.
Нигде я не писал, что известная атакующему соль равна отсутствующей в общем случае. Если дать себе труд прочесть переписку, которую взялся комментировать, там будет написано:
Ответ, рождённый работой мысли, а не бездумным повторением заученных мантр — нет. В базе John the Ripper пароль 12345 стоит на втором месте. Что означает практически полное отсутствие задержки при взломе. Перебор по всей базе в 3,5К также не будет медленнее перебора про радуге. Из чего можно сделать тот самый вывод, о котором я говорю с самого начала этой занимательной дискуссии — для паролей вида 12345 наличие соли не сказывается на стойкости.
Но если все ваши претензии сводятся к этому, то вы меня очень обяжете, если избавите от необходимости копаться в ваших фантазиях.
Особенно если внезапно! не две базы, а одна. И с солью.
Но сам неожиданный ход мысли мне понравился. Воображаем себе хакера в ресторане, где ему предлагают на выбор две базы — с солью и без. И на том основании, что он выберет ту из них, которая никак не относится к обсуждаемой теме, с блеском докажем несостоятельность доводов оппонента. Люблю когда у автора хорошо с фантазией.
«второй пароль» — это та же соль. Которая просто хранится отдельно. И её утеря, при соблюдении всех правил, никак не скажется на стойкости хэша.
Утеря же закрытого ключа гарантированно компрометирует все подписанные документы. Неужели даже в запале желания во что бы то ни стало уесть оппонента не видно разницы? Ну, жаль. Всё-таки, ололо побеждает разум.
Просто вместо password становится Hs(password, salt).
Если для входа на сервер нам надо знать не пароль, а хэш — то хэш теперь становится тем «паролем», зная который, можно войти на сервер. И в итоге этот «пароль» хранится на сервере в открытом виде.
Так что просто «никогда не подставлять в запросы непосредственно ничего». Точка.
А только через плейсхолдер или белый список.
И плюс ещё про Digest авторизацию (которая challenge-response) — она, увы, несовместима с хэшированием паролей. Поэтому — только SSL. Тем более, что это совсем несложно.
поэтому, чтобы не выбирать из двух зол — только шифрование канала.