Ну, вообще-то, github — это синоним слова «поменять». Весь смысл гитхаба — это возможность одной кнопкой сделать форк и менять в нём всё, что только заблагорассудится. Потом можно дать ссылку на свой репозиторий с исправленной версией.
Да, это был у меня косяк при импорте. Этот вопрос снимается.
Но наличие индексов в учебном дампе, при том что в примерах требуется сначала база без индексов, а самой статье приведен код для их создания — это всё равно неприемлемо для обучающего материала.
Это идеальные крылья от дорожного велосипеда, подходят для любой погоды.
А те размахайки, которые висят на расстоянии пол-метра от колеса на современных «байках» функцию несут чисто декоративную.
Снег набивается везде, не только под крылья. Но так же легко и сбивается. Как автомобиль не встаёт из-за снега в арках, так и велосипеду это совсем не так страшно, как кажется диванным теоретикам. Двигаться из-за трения чуть сложнее, но никто больше 15-и по такому покрытию и не гоняет.
Надо добавлять \G, а не /G
Запрос надо помещать не в блок code, а в блок source. С соответствующим языком:
EXPLAIN SELECT * FROM
orderdetails d
INNER JOIN orders o ON d.orderNumber = o.orderNumber
INNER JOIN products p ON p.productCode = d.productCode
INNER JOIN productlines l ON p.productLine = l.productLine
INNER JOIN customers c on c.customerNumber = o.customerNumber
WHERE o.orderNumber = 10101
Код, языка для которого не находится — помещать в любой подходящий. Например — HTML
EXPLAIN SELECT * FROM categories
********************** 1. row **********************
id: 1
select_type: SIMPLE
table: categories
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4
Extra:
1 row in set (0.00 sec)
Получается гораздо читабельнее.
Запросы до дампа — это ерунда. Хотя тоже не красит автора.
но проблема в том, что и после дампа вывод эксплейнов не соответствует запросам. И дело совсем не в наличии индексов. Хотя это, опять же — необъяснимая тупость автора. А точнее — лень.
Но дело, повторюсь, не в индексах, а в самом дампе. Запросы не находят данных.
Я, когда готовлю статью, вылизываю исходные данные до последней запятой, перепроверяю по 10 раз. А этот индус тяп-ляп набросал — разбирайтесь сами.
Даже понимая, как должен работать его код, я не буду тратить время на поиск и исправление опечаток. А человек, который, как предполагается, будет изучать explain, вряд ли пройдёт этот квест вообще.
Тщательнее надо подходить к выбору статей для перевода.
А перед написанием статьи на хабр желательно сначала изучить средства форматирования.
Еще раз.
Перед 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 наличие соли не сказывается на стойкости.
Я не знаю, КАК надо читать, чтобы "известная атакующему соль" прочесть как "отсутствующая".
Но если все ваши претензии сводятся к этому, то вы меня очень обяжете, если избавите от необходимости копаться в ваших фантазиях.
Ответ: Не сказывается. Станет. Чтобы понять — почему, надо понять разницу между брутфорсом и перебором по словарю. Это не так сложно.
Особенно если внезапно! не две базы, а одна. И с солью.
Но сам неожиданный ход мысли мне понравился. Воображаем себе хакера в ресторане, где ему предлагают на выбор две базы — с солью и без. И на том основании, что он выберет ту из них, которая никак не относится к обсуждаемой теме, с блеском докажем несостоятельность доводов оппонента. Люблю когда у автора хорошо с фантазией.
Но наличие индексов в учебном дампе, при том что в примерах требуется сначала база без индексов, а самой статье приведен код для их создания — это всё равно неприемлемо для обучающего материала.
А те размахайки, которые висят на расстоянии пол-метра от колеса на современных «байках» функцию несут чисто декоративную.
Снег набивается везде, не только под крылья. Но так же легко и сбивается. Как автомобиль не встаёт из-за снега в арках, так и велосипеду это совсем не так страшно, как кажется диванным теоретикам. Двигаться из-за трения чуть сложнее, но никто больше 15-и по такому покрытию и не гоняет.
Запрос надо помещать не в блок code, а в блок source. С соответствующим языком:
Код, языка для которого не находится — помещать в любой подходящий. Например — HTML
Получается гораздо читабельнее.
Запросы до дампа — это ерунда. Хотя тоже не красит автора.
но проблема в том, что и после дампа вывод эксплейнов не соответствует запросам. И дело совсем не в наличии индексов. Хотя это, опять же — необъяснимая тупость автора. А точнее — лень.
Но дело, повторюсь, не в индексах, а в самом дампе. Запросы не находят данных.
Я, когда готовлю статью, вылизываю исходные данные до последней запятой, перепроверяю по 10 раз. А этот индус тяп-ляп набросал — разбирайтесь сами.
Даже понимая, как должен работать его код, я не буду тратить время на поиск и исправление опечаток. А человек, который, как предполагается, будет изучать explain, вряд ли пройдёт этот квест вообще.
Тщательнее надо подходить к выбору статей для перевода.
А перед написанием статьи на хабр желательно сначала изучить средства форматирования.
Перед 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 наличие соли не сказывается на стойкости.
Но если все ваши претензии сводятся к этому, то вы меня очень обяжете, если избавите от необходимости копаться в ваших фантазиях.
Особенно если внезапно! не две базы, а одна. И с солью.
Но сам неожиданный ход мысли мне понравился. Воображаем себе хакера в ресторане, где ему предлагают на выбор две базы — с солью и без. И на том основании, что он выберет ту из них, которая никак не относится к обсуждаемой теме, с блеском докажем несостоятельность доводов оппонента. Люблю когда у автора хорошо с фантазией.