Информационный портал по безопасности

Друзья, 9-10 сентября в московском офисе Mail.Ru Group состоится самый ожидаемый фестиваль компьютерной графики CGSpace#6. Вас ждут два дня полезных и увлекательных лекций, воркшопов, общения и много приятных сюрпризов!
->

«В картах у нас есть такой сценарий: на ходу достать телефон, запустить приложение, быстро определить, где я нахожусь, сориентироваться по компасу, куда мне идти, и убрать телефон.



Похожих сценариев, когда приложение открывают ненадолго, много. Поэтому нам очень важно, чтобы приложение запускалось быстро. Недавно мы провели большую работу по оптимизации времени запуска. Этим опытом я и хочу с вами сейчас поделиться.»







В основу данного материала легло выступление Николая Лихогруда, руководителя разработки мобильных Яндекс.Карт для iOS, на конференции Mobius 2017.



likhogrud уже написал пост на эту тему в блоге Яндекса, но мы не могли не выпустить один из лучших докладов конференции. Здесь есть и видео, и текст под катом, смотрите, как вам удобнее.
->

Я расскажу о такой проблеме, как хеширование паролей в веб-сервисах. На первый взгляд кажется, что тут все «яснопонятно» и надо просто взять нормальный алгоритм, которых уже напридумывали много, написать чуть-чуть кода и выкатить все в продакшн. Но как обычно, когда начинаешь работать над проблемой, возникает куча подводных камней, которые надо обязательно учесть. Каких именно? Первый из них — это, пожалуй, выбор алгоритма: хоть их и много, но у каждого есть свои особенности. Второй — как выбирать параметры? Побольше и получше? Как быть с временем ответа пользователю? Сколько памяти, CPU, потоков? И третий — что делать с computational DoS? В этой статье я хочу поделиться некоторыми своими мыслями об этих трех проблемах, опытом внедрения нового алгоритма хеширования паролей в Яндексе и небольшим количеством кода.

Attacker & Defender

Прежде чем переходить к алгоритмам и построению схемы хеширования, надо вообще понять, от чего же мы защищаемся и какую роль в безопасности веб-сервиса должно играть хеширование паролей. Обычно сценарий таков, что атакующий ломает веб-сервис (или несколько веб-сервисов) через цепочку уязвимостей, получает доступ к базе данных пользователей, видит там хеши паролей, дампит базу и идет развлекаться с GPU (и, в редких случаях, с FPGA и ASIС).
->

На трансляции 1 сентября в 19:00 мы расскажем о наших образовательных проектах и о том, как вы можете развить свои навыки в различных областях IT вместе с нами. Трансляция будет доступна в проигрывателе выше.

Темы трансляции:

— Очное обучение в вузах с Mail.Ru Group

— Митапы и конференции в офисе

— YouTube-канал Технострим

— Онлайн-курсы на платформах Stepik и Coursera

— Онлайн-чемпионаты по программированию и не только

— Профориентация школьников

Ниже — чуть более подробный анонс, чтобы вы нашли что-то для себя. Также об образовательных проектах компании вы можете почитать в нашем обзоре, и тогда на вебинаре мы будем ждать уже конкретных вопросов об интересующих вас проектах!

->

17 августа 2017 года несколько контент-провайдеров и сетей доставки контента (CDN) подверглись масштабным атакам ботнета, получившего название WireX. Ботнет WireX включает в себя в основном Android-устройства и предназначен для создания DDoS-трафика. Несколько дней назад Google удалил сотни заражённых приложений, которые были доступны для скачивания в Play Маркет, и запустил процесс их удаления со всех устройств.



Исследователи из Akamai, Cloudflare, Flashpoint, Google, Oracle Dyn, RiskIQ, Team Cymru и других организаций сотрудничали, объединившись для борьбы с этим ботнетом. Доказательства указывают на то, что ботнет, возможно, был активен уже 2 августа, но именно атака 17 августа привлекла внимание. Эта статья включает в себя совокупные знания и описывает усилия исследователей, работающих над нейтрализацией ботнета. ->

Автор материала рассказывает об устройстве системы управления версий, которая реализована в компании Stripe.







Когда дело доходит до API, изменения — вещь непопулярная. В то время как многие разработчики ПО привыкли к работе в режиме частых и быстрых итераций, разработчики API теряют эту гибкость как только у них появляется хотя бы первый пользователь их интерфейса. Многие из нас знакомы с историей эволюции операционной системы Unix.



В 1994 году была издана книга «Настольное пособие Unix-ненавистника» (Unix-Haters Handbook), в которой затрагивался целый список самых разных острых тем, от имен оптимизированных под телетайпы команд с совершенно непонятной историей происхождения до необратимого удаления данных, непонятных интуитивно программ с избытком опций. Более 20 лет спустя, подавляющее большинство этих жалоб по-прежнему актуальны несмотря на все многообразие доступные сегодня систем-наследников и ответвлений. Unix стал настолько широко популярен, что изменение его поведения может привести к далеко идущим последствиям. Хорошо это или плохо, но между ним и его пользователями уже сложились определенные договоренности, определяющие поведение Unix-интерфейсов.



Похожим образом и API представляет собой коммуникационный договор, изменить который без значительной доли сотрудничества и усилий со стороны обеих сторон не представляется возможным. Многие бизнесы полагаются на Stripe как поставщика инфраструктуры и поэтому мы думаем над этими этим видом взаимодействия с самого начала деятельности нашей компании. В настоящее время нам удалось сохранить поддержку каждой версии нашего API с момента появления компании в 2011 году. В этой статье, мы бы хотели поделиться с вами, как нам в Stripe удается организовать работу с версиями API.
->

Недавно мы делились с вами материалом об эволюции Linux. Сегодня, в честь недавнего 26-го дня рождения ядра операционной системы, публикуем рассказ о том, с чего всё начиналось.



->

При написании различных программ для работы с сетью, особенно p2p систем, время от времени возникает необходимость узнать внешний IP своего компьютера из программы (тот адрес, по которому Ваш компьютер доступен из Большого Интернета). Часто возникает искушение пойти легким путем и использовать внешние WEB-сервисы, которые по http возвращают Вам IP, или самому развернуть таковой. Хотя такой способ решения задачи и работоспособен, он тем не менее, имеет ряд недостатков:

• При использовании собственного сервера – нужно где-то его держать и поддерживать, заодно и c соответствующим доменным именем. В случае выхода его из строя, или принудительного отзыва домена, вся Ваша p2p сеть выходит из строя.


• При использовании внешнего сервера – Вы вводите зависимость своей системы как от его работоспособности, так и от формата ответов, который вообще никак не стандартизирован, и который владелец сервера может поменять в любой момент. С теми же последствиями для вашей сети.


• http, которым советуют пользоваться – базируется на tcp, то есть протокол сравнительно тяжеловесный, требующий установки соединения и тп. В общем, пользоваться можно, но перерасход ресурса как компьютера, так и сети налицо.

->

Статья рассчитана на широкий круг читателей и требует лишь базовых знаний PHP и javascript. Если вы занимались программированием и вам знакома аббревиатура API, то вы по адресу.

Изначально статья предполагала лишь описание отличительных особенностей GraphQL и RESTful API, с которыми мы столкнулись на практике, но в итоге она вылилась в объемный туториал на несколько частей.

Как показывает статистика, ежедневно количество угроз стремительно растет. Так, например, по аналитике, проведенной антивирусной лабораторией Pandalabs в компании Panda Security за 1 квартал 2017 года, количество новых типов угроз ежедневно увеличивается на 350 000.

Атаки и компрометации могут осуществляться за минуты, а процесс Атака -> Компрометация -> Утечка данных -> Обнаружение инцидента -> Реагирование и Устранение занимает дни, недели и даже месяцы. И чаще всего это происходит уже после того, как злоумышленник скомпрометировал данные. При этом согласно ежегодному отчету по информационной безопасности Cisco специалисты по безопасности в течение своего рабочего дня способны обработать лишь 56% поступающих сообщений об угрозах, а среди этих оповещений об угрозах обоснованным признается только каждое второе (т.е. 28%). Таким образом, 44% инцидентов остаются без внимания!



При этом на рынке критически не хватает не только ресурсов, позволяющих обработать все инциденты, но и общей системы, благодаря которой стало бы возможным реагировать на них на ранних стадиях кибератак — в идеале до эксплуатации, а также накапливать распределенные знания об угрозах, обмениваться полученными данными, расследовать причины угроз и мгновенно реагировать на них. Для более быстрого накопления информации о возможных угрозах следует стремиться к совместному использованию полезных данных от широкого круга источников. При этом важно, чтобы эта информация была стандартизирована, то есть стандарты и протоколы передачи и предоставления данных были определены заранее.
->