Я не представляю, как путем реверс-инжениринга можно это высчитать, ну вот честно. Если что-то простое, то да. Но у нас алгоритмов криптографии даже не 5 или 10, а гораздо больше, причем у каждого из них есть еще внутри куча вариаций и подтипов, плюс надо перебирать поля из базы, чтобы понять комбинация из каких полей составляет случайную соль.
Реально ли это можно подобрать? Ибо, если честно, не особо верится.
Т.е. получается что мы бьемся за интервал времени разгадывания паролей — так или иначе, рано или поздно, злоумышленник получит их, но мы дадим больше времени, чтобы пользователь мог успеть сменить свой пароль?
По сути тогда надо использовать максимально медленный алгоритм, и при этом чтобы медленность его росла с увеличением числа знаков.
по п.1 — теоритически «случайную соль» можно высчитать, как узнать что она является вектором например в AESе или еще где-то? или еще чем-то, и не она сама, а md5( нее + что-то )?
Т.е. как узнать что используется за алгоритм вычисления хэша по хэшу?
А можно дурацкий вопрос?
При переборе человек будет предполагать по виду ключа, какой алгоритм использован, так?
т.е. bcrypt / md5 — это стандартные алгоритмы для генерации хэша, и т.е. на них первых и падет подозрение (ну и на другие стандартные).
1) если у взломщика есть только БД, но нет кода, лучше использовать любой нестандартный алгоритм, ну не знаю, md5( Rijndael( пароль + md5( времени регистрации на ресурсе ) + статическая соль, статический вектор, зашитый в код ) ) — мне кажется так просто «в лоб» подобрать такие комбинации весьма проблематично.
2) если у взломщика есть доступ до файлов / движка, защититься в принципе невозможно, и будет скомпромитированы все пользователи с простыми, словарными паролями, вычислить же чистым пароль, которого нет в словарях при таком алгоритме практически невозможно.
3) если операций авторизации у вас на ресурсе не огромное количество, то в качестве соли, для некомплементарных алгоритмов можно выбрать соль килобайт на 200, так что на быстродействии авторизации это практически не скажется, а вот подбор затруднит существенно.
4) ну и естественно попытки брута надо определять и дополнять счастье капчей + ограничением попыток в единицу времени.
PHP будет и дальше развиваться в сторону различного «сахара», думаю, что так-же обязательно будет точиться ООП в нем.
Возможно — и это очень бы хотелось — добавят strict режим, о котором уже просили разработчиков (чтобы не было проблем аля if ( «0x00» == 0 ) {} ) и т.д.
Но в любом случае, мне кажется, что язык будет идти в сторону большей строгости (типизация и т.д.)
Ну и судя по тенденциям, думаю, будут развиваться асинхронные возможности.
Я просто так понял, что код генератора как раз «зашит», т.е. не используется системный, ок, согласен.
Ну вот так, сходу, приходит на ум только сравнение двух закодированных одинаковых файлов (например исходного notepad и завирусованного его-же, либо одинаковых, но по разному завирусованных файлов), либо если только задетектить — хэш суммы, entry-point, сравнение эталонных длин файлов.
А вот чисто алгоритмическое решение сообразить не могу.
Если конечно вирус был заранее известен, то тогда, можно найти в нем какие-либо повторяющиеся байты на определенном расстоянии, к которым можно прицепится для детекта XOR — ибо какой бы «XOR число» не был использован — они так-же будут повторятся, хоть и будут иметь другие значения…
Используют, насколько я знаю.
Ботнеты это очень любят.
Но вообще это гораздо более сложный метод чем FTP / POST(GET) / SMTP ибо есть в системе практически все готовое.
Ну есть метод «в лоб» без разбирательств, если алгоритм генерации случайного числа встроен в вирь, я бы смотрел число «1103515245» в теле, или скомпилил функцию генерации и использовал ее в качестве сигнатуры, ибо это то, что требуется вирю в незашифрованном виде (если конечно не применено комбинирование или какая-то обфускация)
Ну а если по уму, то надо смотерть распределение, дающееся таким генератором ПСЧ, и смотреть варианты его взлома (а его точно давным-давно сломали) и на основе их, а так-же учитывая что XOR обратим, думать дальше :-) Как-то так. ИМХО.
И по опыту реально в лог сыпится куча РАЗНЫХ ошибок?
Просто было у нас, что валились десятки тысяч ошибок — виной тому стала библиотека, не подгружавшаяся с зависшего CDN-а.
Выдернуть из лога первую ошибку (потому как, чтобы понять как сыпется, надо начать с первой ошибки, т.к. остальные могут быть уже следствием) для каждого пользователся по таймстампу и уникальному тексту обычным регспом ушло 15 минут и дальше вместо 100000 строк лога у нас было 3 разных текстовых версии одной ошибки. Все.
Я не в коем случае не хочу сказать что сервис плох — хочу понять кто использует и зачем, чтиобы потом это применять в дальнейшем, если будет нужно.
Ну splunk, по моему опыту, ставится при очень сильной фрагментации (реализаций множество — например под разные системы win/linux/и т.д.) + когда функционал очень сложен, либо же, когда имеются множество систем, объедененных в одно целое.
Он позволяет сократить время на анализ среди кучи реализаций, или кучи систем, генерирующих абсолютно разные логи, каждая в своем формате.
Ошибки там ооочень часто привязаны именно к среде/железу/системе + он эффективен, когда вариантов множество, код сложен и т.д.
Здесь же все работает в рамках браузера — т.е. гораздо более узкая область.
Да, могут быть конечно ошибки связанные с системой (Android / PC / IOS), но это все очень легко детектится да и логика приложений в большинстве случаев достаточно проста, а реализация (JS/HTML/Server-side) обычно одна на все варианты + логи ошибок (как и ошибки) стандартны, хоть и могут отличаться «написанием».
Если в этом случае использовать такой вот «splunk» — это как из гаубицы по воробьям стрелять.
Хотя, быть может есть другой опыт у кого-либо — я не долго этот инструмент использовал.
А я всегда думал что фишка в том, что при падении ошибки в лог ее нужно смоделить и пофиксить и все.
И на красоту представления ошибок мне как-то фиолетово (ИМХО).
Главное — как можно быстрее пофиксить ее, поправить тесты, которые раньше ее не обнаруживали, еще раз их прогнать, проверить и выкатить новую пофиксенную версию в продакшн, чтобы не заставлять ждать конечного пользователя.
Я тоже не до конца понял. Версию браузера можно так-же скинуть в лог.
Потом отгрепать и понять че кого в конкретном браузере. Кроме того как бы не была описана ошибка — суть ее будет понятна — за бэкэндом же не робот сидит.
Ну или я действительно не понимаю…
И почему нельзя было сразу выключить апдейты, а потом заниматься разбором в чем проблема? Ведь понимание следствия — что именно после апдейта случался писец было доступно практически сразу?
основному == ведущему разработчику такое не простительно
Причем не ошибка — все могут ошибаться, а вот это «он вне плана внес изменения в инсталлер/деинсталлер приложения».
Ну и плюс от Яндекса самое главное — «список изменений» у Вас, гсопода, не из коммитов береться — это реально ахтунг! Ну результат на лицо.
Лояльность пользователей, которую вы так тяжко набирали в условиях гдрайва и дропбокса вы потеряли очень сильно. и виновность в этом вполовину лежит на Вашей любови «молчать».
И еще вопрос — как только Вы обнаружили проблему, как быстро Вы заблокировали сервер обновлений, чтобы ЯД перестал обновляться и, соответсвенно, сносить все подряд у пользователей?
Вроде бы как сейчас самый верный вариант, из того что смог посмотреть.
В PHP есть имплементация простая:
Реально ли это можно подобрать? Ибо, если честно, не особо верится.
По сути тогда надо использовать максимально медленный алгоритм, и при этом чтобы медленность его росла с увеличением числа знаков.
Какой из существующих алгоритмов для этого лучше?
Т.е. как узнать что используется за алгоритм вычисления хэша по хэшу?
При переборе человек будет предполагать по виду ключа, какой алгоритм использован, так?
т.е. bcrypt / md5 — это стандартные алгоритмы для генерации хэша, и т.е. на них первых и падет подозрение (ну и на другие стандартные).
1) если у взломщика есть только БД, но нет кода, лучше использовать любой нестандартный алгоритм, ну не знаю, md5( Rijndael( пароль + md5( времени регистрации на ресурсе ) + статическая соль, статический вектор, зашитый в код ) ) — мне кажется так просто «в лоб» подобрать такие комбинации весьма проблематично.
2) если у взломщика есть доступ до файлов / движка, защититься в принципе невозможно, и будет скомпромитированы все пользователи с простыми, словарными паролями, вычислить же чистым пароль, которого нет в словарях при таком алгоритме практически невозможно.
3) если операций авторизации у вас на ресурсе не огромное количество, то в качестве соли, для некомплементарных алгоритмов можно выбрать соль килобайт на 200, так что на быстродействии авторизации это практически не скажется, а вот подбор затруднит существенно.
4) ну и естественно попытки брута надо определять и дополнять счастье капчей + ограничением попыток в единицу времени.
Нет?
Это в случае Stateless просто, а здесь, пи#$$ц, извините.
Это надо писать балансер, который бы раскидывал нагрузку, ну или использовать готовый — по мне так это нифига не просто + куча подводных граблей.
Возможно — и это очень бы хотелось — добавят strict режим, о котором уже просили разработчиков (чтобы не было проблем аля if ( «0x00» == 0 ) {} ) и т.д.
Но в любом случае, мне кажется, что язык будет идти в сторону большей строгости (типизация и т.д.)
Ну и судя по тенденциям, думаю, будут развиваться асинхронные возможности.
Ну вот так, сходу, приходит на ум только сравнение двух закодированных одинаковых файлов (например исходного notepad и завирусованного его-же, либо одинаковых, но по разному завирусованных файлов), либо если только задетектить — хэш суммы, entry-point, сравнение эталонных длин файлов.
А вот чисто алгоритмическое решение сообразить не могу.
Если конечно вирус был заранее известен, то тогда, можно найти в нем какие-либо повторяющиеся байты на определенном расстоянии, к которым можно прицепится для детекта XOR — ибо какой бы «XOR число» не был использован — они так-же будут повторятся, хоть и будут иметь другие значения…
P.S. OMG, чем мы занимаемся в Пятницу :-D
Ботнеты это очень любят.
Но вообще это гораздо более сложный метод чем FTP / POST(GET) / SMTP ибо есть в системе практически все готовое.
Ну а если по уму, то надо смотерть распределение, дающееся таким генератором ПСЧ, и смотреть варианты его взлома (а его точно давным-давно сломали) и на основе их, а так-же учитывая что XOR обратим, думать дальше :-) Как-то так. ИМХО.
Просто было у нас, что валились десятки тысяч ошибок — виной тому стала библиотека, не подгружавшаяся с зависшего CDN-а.
Выдернуть из лога первую ошибку (потому как, чтобы понять как сыпется, надо начать с первой ошибки, т.к. остальные могут быть уже следствием) для каждого пользователся по таймстампу и уникальному тексту обычным регспом ушло 15 минут и дальше вместо 100000 строк лога у нас было 3 разных текстовых версии одной ошибки. Все.
Я не в коем случае не хочу сказать что сервис плох — хочу понять кто использует и зачем, чтиобы потом это применять в дальнейшем, если будет нужно.
Он позволяет сократить время на анализ среди кучи реализаций, или кучи систем, генерирующих абсолютно разные логи, каждая в своем формате.
Ошибки там ооочень часто привязаны именно к среде/железу/системе + он эффективен, когда вариантов множество, код сложен и т.д.
Здесь же все работает в рамках браузера — т.е. гораздо более узкая область.
Да, могут быть конечно ошибки связанные с системой (Android / PC / IOS), но это все очень легко детектится да и логика приложений в большинстве случаев достаточно проста, а реализация (JS/HTML/Server-side) обычно одна на все варианты + логи ошибок (как и ошибки) стандартны, хоть и могут отличаться «написанием».
Если в этом случае использовать такой вот «splunk» — это как из гаубицы по воробьям стрелять.
Хотя, быть может есть другой опыт у кого-либо — я не долго этот инструмент использовал.
И на красоту представления ошибок мне как-то фиолетово (ИМХО).
Главное — как можно быстрее пофиксить ее, поправить тесты, которые раньше ее не обнаруживали, еще раз их прогнать, проверить и выкатить новую пофиксенную версию в продакшн, чтобы не заставлять ждать конечного пользователя.
Потом отгрепать и понять че кого в конкретном браузере. Кроме того как бы не была описана ошибка — суть ее будет понятна — за бэкэндом же не робот сидит.
Ну или я действительно не понимаю…
Посмотрите на время моего, и на время того, что по ссылке.
И еще раз повторю — считать это официальным комментарием невозможно.
По фамилиям и никам я всех сотрудников Яндекса не знаю.
Кроме того, я так-же как и Вы, могу написать что «xxx-руководитель… ну не знаю… SIliconTits Valley» Это ни чего не значит.
Главное, что никто ничего не написал, ни официально, ни в блоге.
Спасибо vladimirrusinov, что он хоть как-то прокомментировал все это.
Но это не подход федеральной компании.
Это подход киоска, утаивающего, что его продукт просрочен.
Это грустно, ужасно нелепо и обидно (хотя бы потому, что срок годности написан на этом продукте) — надеюсь вы поймете мою метафору.
А если нет, то дам подсказку — я очень не люблю, когда меня считают бараном.
И почему нельзя было сразу выключить апдейты, а потом заниматься разбором в чем проблема? Ведь понимание следствия — что именно после апдейта случался писец было доступно практически сразу?
Причем не ошибка — все могут ошибаться, а вот это «он вне плана внес изменения в инсталлер/деинсталлер приложения».
Ну и плюс от Яндекса самое главное — «список изменений» у Вас, гсопода, не из коммитов береться — это реально ахтунг! Ну результат на лицо.
Лояльность пользователей, которую вы так тяжко набирали в условиях гдрайва и дропбокса вы потеряли очень сильно. и виновность в этом вполовину лежит на Вашей любови «молчать».