Что ж там такого неидеального с т.з. веб-разработки? :)
А я не говорил ничего про линь и веб-разработку :-D
У меня такое впечатление складывается, что Вы или не читаете или не понимаете что я пишу, или то и другое вместе :-D
Ну или Вы тролль :-D
Линукс в качестве десктопа пока все еще на айс — увы.
Вот мои слова, тут нет ни слова о веб-разработке. «в качестве декстопа» по моему вполне понятно что говорится о GUI, не?
Точно! То что такого пакета нет под виндой виноват программер!
Не, реально, остыпьте мне того, чего употребляете :-D Этож как надо было исказить то, что я писал ))))
Ну что делать, разжую «Если программист использовал костыль вместо проверенного и уже существующего решения из-за того, что данное решение не работает на его системе».
Ну это примерно как если-б Вы сидели под линуксом и не смогли пакет PCRE собрать и установить (хотя абсолютно понятно что именно он Вам нужен) — ну не получилось, забили и написали свою машину регулярных выражений :-D
За велосипеды я бью очень больно и это правильно.
Потому что если что-то у вин-пхпхера не идет на машине, ему доступна настроенная опытным линуксоидам песочница под дебианом с доступом прямо из JB PHPStorm-а по SSL. Как раз для таких случаев.
Но мы то не про это совсем разговаривали )
Надеюсь, донес. Мне страшно за тех людей, которые дают Вам работу — если Вы ТЗ также витеевато интерпретируете — это пи#$ц, простите :-D
Некоторые инструменты — да, некоторые модули — да.
Основные — отлично работают.
nginx под виндой в качестве продакта не айс, в качестве энвиромента — вполне гуд.
Это все вовсе не означает, что веб-программер, работающий на линуксе гораздо лучше работающего на винде, как и наоборот.
Я вот это все пытаюсь донести, но видимо не судьба )))
Юзать можно все, что угодно. Дело привычек и все такое. Многим не нравятся некоторые особенности — даже в этой теме народ отписывался.
Еще раз повторю — как десктоп Линь все еще далеко не идеален.
Юзать можно, да.
Я могу программить вообще в консоли, юзая лишь nano/ed/vim/mc и вполне буду себя комфортно при этом ощущать :-D
Но это ни говорит ни о моей продвинусти, ни о моем качестве кода.
Еще раз — Линух и Винда никак не сказывается на качестве решаемой задачи веб-программером, как и на его продвинутости.
Если человек долбо#$ — то он будет им вне зависимости на чем сидит :-D
Как и наоборот.
Вот если программер упрется в то, что под виндой не ставится какой-то пакет и вместо этого он напишет костыль — то тогда да, пипец.
Но, опять-же, тут дело в человеке и в ничем более.
Линукс в качестве десктопа пока все еще на айс — увы.
OpenNet Вам в помошь — там много по этому поводу воды расписано.
IOS да.
Если проекты на уровне сайта-визитки то да, конечно выбор ОСи — второстепенно.
ОСи разработки имелось ввиду, а не где крутиться будет :-)
От ОСи разработки не зависит продукт точно.
Совершенные инструменты тоже не завязаны на ОСь — они завязаны на человека, который их юзает как и технологии.
А то по-вашему если человек на винде сидит, то ему и новые технологии никакие в программировании не доступны ))) Насмешили.
А по поводу убеждения — зачастую старые дядьки более опытны — не рассматривали такой вариант? :-D
Вот если человек факты и аргументы — это да, пипец.
А насчет чуши — ну например в этой статье я чуши не вижу никакой.
Я еще раз попробую донести до Вас то, что Вы так упорно игнорируете — от выбора системы навыки программиста как и его код не зависят (во всяком случае в данном контексте).
Продавать себя на фриласне и заниматься продажами продукта уровня энтерпрайз или чуть ниже — две ааабсолютно большие разницы — поговорите с знакомыми продакт-менеджерами — они Вам расскажут :-D
Большинство этих программеров могут поднять и настроить Апач и мускл под дебианом — это осилили? :)
Но работать им привычней под виндой — свои утилиты и инструменты, к которым они прикипели, и которые заточили как им удобно, да ипросто привычная парадигма системы. Я не навязываю им выбор среды разработки.
Этих, как Вы называете «чудаков» весьма немало. И я среди них встречал очень и очень нехилых профи. Качество кода не зависит от операционной системы — поверьте :)
На продакте действительно стоит линь, но например я не встречался с какими-либо проблемами работы кода что под PHP / Python, за исключением того что под линь оно быстрее и дольше робит ну и незначительные различия :)
И еще одно — умейте уважать чужое мнение, и людей, его имеющих.
Здесь все — грамотные и уважаемые технари.
Потому что то, как Вы пишите и что Вы пишите делает Вас похожим на типичную школоту.
И опять-же возвращаясь к чудакам — у меня в ведении несколько серваков под Debian / FBSD. Настраивал их я.
На работе у меня две системы — Kubunta и W7.
Дома W7, на серваки захожу из под нее же.
И за плечами у меня как минимум 3 энтерпрайс проекта и веб программинг с 1990 года — это я не хвастаюсь — просто констатирую факты.
И, не поверите, я предпочитаю win для написания кода!
Потому что я старый динозавр, привык бля к винде :-D
Однако по Вашему я чудак, ни на что не спосбный :-D
Будьте терпимей к другим — это убережет Вас от кучи ошибок и сохранит Вам зубы и морду в трогательной девственной красоте ;)
Че-то я Вас не понимаю, То Вы пишите, что продажами занимаетесь, то — что разработчик.
Вы вообще смотрели статью то? И Что в сборке?
Там нет никакой солянки, там набор стандартных пакетов типа Apache / MySQL / Python под вонь и несколько cmd-шников, которые патчат их инишки и ВСЕ.
По поводу адекватных разработчиков не загоняйтесь —
у меня в конторе из 13 веб-программеров 10 сидят под виндой, и мне например эта сборка очень приглянулась — ибо работает с пол пинка.
А автора Вы пытались учить продажам кстати и отношению к клиентам (причем еще и абсолютно неправильным вещам) — от по этому он Вас про продажи спрашивал :-D
Я не представляю, как путем реверс-инжениринга можно это высчитать, ну вот честно. Если что-то простое, то да. Но у нас алгоритмов криптографии даже не 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» — это как из гаубицы по воробьям стрелять.
Хотя, быть может есть другой опыт у кого-либо — я не долго этот инструмент использовал.
А я всегда думал что фишка в том, что при падении ошибки в лог ее нужно смоделить и пофиксить и все.
И на красоту представления ошибок мне как-то фиолетово (ИМХО).
Главное — как можно быстрее пофиксить ее, поправить тесты, которые раньше ее не обнаруживали, еще раз их прогнать, проверить и выкатить новую пофиксенную версию в продакшн, чтобы не заставлять ждать конечного пользователя.
Ну да зато я хоть поржал, люблю неадекватов :-)
И заметь, пиво мы с Вами не пили, так что тыкай друзьям своим. Вежливость никто не отменял.
А я не говорил ничего про линь и веб-разработку :-D
У меня такое впечатление складывается, что Вы или не читаете или не понимаете что я пишу, или то и другое вместе :-D
Ну или Вы тролль :-D
Вот мои слова, тут нет ни слова о веб-разработке. «в качестве декстопа» по моему вполне понятно что говорится о GUI, не?
Не, реально, остыпьте мне того, чего употребляете :-D Этож как надо было исказить то, что я писал ))))
Ну что делать, разжую «Если программист использовал костыль вместо проверенного и уже существующего решения из-за того, что данное решение не работает на его системе».
Ну это примерно как если-б Вы сидели под линуксом и не смогли пакет PCRE собрать и установить (хотя абсолютно понятно что именно он Вам нужен) — ну не получилось, забили и написали свою машину регулярных выражений :-D
За велосипеды я бью очень больно и это правильно.
Потому что если что-то у вин-пхпхера не идет на машине, ему доступна настроенная опытным линуксоидам песочница под дебианом с доступом прямо из JB PHPStorm-а по SSL. Как раз для таких случаев.
Но мы то не про это совсем разговаривали )
Надеюсь, донес. Мне страшно за тех людей, которые дают Вам работу — если Вы ТЗ также витеевато интерпретируете — это пи#$ц, простите :-D
Некоторые инструменты — да, некоторые модули — да.
Основные — отлично работают.
nginx под виндой в качестве продакта не айс, в качестве энвиромента — вполне гуд.
Это все вовсе не означает, что веб-программер, работающий на линуксе гораздо лучше работающего на винде, как и наоборот.
Я вот это все пытаюсь донести, но видимо не судьба )))
Юзать можно все, что угодно. Дело привычек и все такое. Многим не нравятся некоторые особенности — даже в этой теме народ отписывался.
Еще раз повторю — как десктоп Линь все еще далеко не идеален.
Юзать можно, да.
Я могу программить вообще в консоли, юзая лишь nano/ed/vim/mc и вполне буду себя комфортно при этом ощущать :-D
Но это ни говорит ни о моей продвинусти, ни о моем качестве кода.
Еще раз — Линух и Винда никак не сказывается на качестве решаемой задачи веб-программером, как и на его продвинутости.
Если человек долбо#$ — то он будет им вне зависимости на чем сидит :-D
Как и наоборот.
Вот если программер упрется в то, что под виндой не ставится какой-то пакет и вместо этого он напишет костыль — то тогда да, пипец.
Но, опять-же, тут дело в человеке и в ничем более.
Линукс в качестве десктопа пока все еще на айс — увы.
OpenNet Вам в помошь — там много по этому поводу воды расписано.
IOS да.
ОСи разработки имелось ввиду, а не где крутиться будет :-)
От ОСи разработки не зависит продукт точно.
Совершенные инструменты тоже не завязаны на ОСь — они завязаны на человека, который их юзает как и технологии.
А то по-вашему если человек на винде сидит, то ему и новые технологии никакие в программировании не доступны ))) Насмешили.
А по поводу убеждения — зачастую старые дядьки более опытны — не рассматривали такой вариант? :-D
Вот если человек факты и аргументы — это да, пипец.
А насчет чуши — ну например в этой статье я чуши не вижу никакой.
Я еще раз попробую донести до Вас то, что Вы так упорно игнорируете — от выбора системы навыки программиста как и его код не зависят (во всяком случае в данном контексте).
Большинство этих программеров могут поднять и настроить Апач и мускл под дебианом — это осилили? :)
Но работать им привычней под виндой — свои утилиты и инструменты, к которым они прикипели, и которые заточили как им удобно, да ипросто привычная парадигма системы. Я не навязываю им выбор среды разработки.
Этих, как Вы называете «чудаков» весьма немало. И я среди них встречал очень и очень нехилых профи. Качество кода не зависит от операционной системы — поверьте :)
На продакте действительно стоит линь, но например я не встречался с какими-либо проблемами работы кода что под PHP / Python, за исключением того что под линь оно быстрее и дольше робит ну и незначительные различия :)
И еще одно — умейте уважать чужое мнение, и людей, его имеющих.
Здесь все — грамотные и уважаемые технари.
Потому что то, как Вы пишите и что Вы пишите делает Вас похожим на типичную школоту.
И опять-же возвращаясь к чудакам — у меня в ведении несколько серваков под Debian / FBSD. Настраивал их я.
На работе у меня две системы — Kubunta и W7.
Дома W7, на серваки захожу из под нее же.
И за плечами у меня как минимум 3 энтерпрайс проекта и веб программинг с 1990 года — это я не хвастаюсь — просто констатирую факты.
И, не поверите, я предпочитаю win для написания кода!
Потому что я старый динозавр, привык бля к винде :-D
Однако по Вашему я чудак, ни на что не спосбный :-D
Будьте терпимей к другим — это убережет Вас от кучи ошибок и сохранит Вам зубы и морду в трогательной девственной красоте ;)
Вы вообще смотрели статью то? И Что в сборке?
Там нет никакой солянки, там набор стандартных пакетов типа Apache / MySQL / Python под вонь и несколько cmd-шников, которые патчат их инишки и ВСЕ.
По поводу адекватных разработчиков не загоняйтесь —
у меня в конторе из 13 веб-программеров 10 сидят под виндой, и мне например эта сборка очень приглянулась — ибо работает с пол пинка.
А автора Вы пытались учить продажам кстати и отношению к клиентам (причем еще и абсолютно неправильным вещам) — от по этому он Вас про продажи спрашивал :-D
Вроде бы как сейчас самый верный вариант, из того что смог посмотреть.
В 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» — это как из гаубицы по воробьям стрелять.
Хотя, быть может есть другой опыт у кого-либо — я не долго этот инструмент использовал.
И на красоту представления ошибок мне как-то фиолетово (ИМХО).
Главное — как можно быстрее пофиксить ее, поправить тесты, которые раньше ее не обнаруживали, еще раз их прогнать, проверить и выкатить новую пофиксенную версию в продакшн, чтобы не заставлять ждать конечного пользователя.