Многие читатели Хабра слушали доклад Тима Мессершмидта, который отвечает за связи PayPal с разработчиками в странах Европы, Ближнего Востока и Африки на прошедшей недавно конференции MBLTDev. Речь шла об аутентификации и сложностях, с которыми сталкиваются специалисты, пытаясь защитить пользовательские данные. Технический директор Redmadrobot Артур Сахаров mc_murphy поймал Тима за кулисами мероприятия и поговорил с ним о безопасности, джейлбрейке и языках программирования.
В своем выступлении вы много говорили о том, что качество UX зачастую вступает в противоречие с безопасностью — в особенности, когда речь идет о “чувствительной” информации, как например, в банковских приложениях. Расскажите об этом, пожалуйста, поподробнее.
В PayPal мы применяем двухфакторную авторизацию: при подтверждении нового устройства используем его аппаратные идентификаторы и подтверждаем их одноразовыми кодами доступа, которые рассылаются через SMS. Когда пользователь регистрируется, ему по электронной почте также приходит письмо с просьбой подтвердить авторизацию. То есть мы предлагаем целый ряд решений в области безопасности помимо обычной регистрации и последующего входа по паролю.
Будем говорить откровенно: если у вас сложный пароль — это хорошо. Но надо понимать, что пароли большинства пользователей не отличаются надежностью. И потом — следует помнить о вероятности перебора возможных комбинаций для пароля, который отлично работает, так как большая часть юзеров использует одинаковые популярные пароли. Снизить риск атак можно, заставляя их придумывать длинные пароли. И мы действительно видим тенденцию: люди применяют более надежные пароли, когда понимают, что информация важная и требует защиты. Это банковские приложения, PayPal, Google, eBay, а также те сервисы, которые впоследствии предполагается использовать для Single Sign-On.
Можно придумать надежный пароль для какого-то сервиса, но он вряд ли обеспечит стопроцентную защиту. Ведь целью фишинговых атак часто становится электронная почта пользователя, а почтовый ящик содержит критически важную информацию и является «ключом» ко всем остальным сервисам. Получается, что если я использую банковское приложение в связке с имэйлом — это не особенно надежно.
Я, конечно, не рекомендую регистрацию или аутентификацию через имэйл в случае с банковскими приложениями. Я бы, пожалуй, сделал выбор в пользу аппаратного токена, поскольку при использовании программного токена данные все же могут уйти на сторону. Даже если вы получаете SMS с кодом на Android-смартфон, это не очень надежно — ведь другие приложения могут его перехватить.
Я знаю, что вам нравится Android. Давайте поговорим об Android и iOS в контексте безопасности. Чей подход более эффективен?
iOS — более закрытая система, в ней больше ограничений. И в некоторых случаях это большой плюс. Что касается Android, то тут в плане безопасности происходит много позитивных изменений. Система становится более надежной: злоумышленникам все сложнее получить доступ к Android-устройствам. Используется SELinux, где ядро защищено значительно лучше. Сейчас безбоязненно можно утверждать, что Android-приложения стали действительно защищенными, и Google подходит к безопасности в Google Play очень серьезно.
Тем не менее, это справедливо не для всех устройств, к тому же Google Play — не единственный источник приложений. Допустим, в Германии, как и во многих других странах, аппарат зачастую привязан к конкретному оператору, у которого тоже есть собственный магазин приложений. Их качество с точки зрения безопасности не обязательно соответствует уровню Google Play.
Здесь вряд ли можно винить исключительно Android, поскольку в отношении сторонних приложений там сейчас применяется та же система, что и в iOS: есть TestFlight, есть HockeyApp, разработчики могут подписывать код для распространения по тестировщикам без дополнительного контроля. Получается, что 3000 человек за раз [лимит на количество тестировщиков в TestFlight] могут получить вредоносное приложение.
Что скажете насчет джейлбрейка? Это ведь нешуточная угроза безопасности. Может, стоит вообще запретить его использование на стороне приложения? Или можно защитить владельцев аппаратов с джейлбрейком другими путями?
Эта тема мне близка и интересна! До прихода в PayPal я делал джейлбрейки во время написания диплома. С одной стороны, с джейлбрейком у пользователя больше свободы в управлении устройством: в некоторых ситуациях это может быть полезно, что следует учитывать. Тем не менее, разработчику довольно просто определить, есть ли на девайсе root-доступ и все запретить. Можно запустить что-то из-под sudo, можно проверить подписи кода приложения на наличие изменений. Существуют возможности все это узнать: Android вообще простая система. Впрочем, то же касается и iOS — можно, например, проверить, установлена ли Cydia и т.д.
Мы, разумеется, учитываем все это при разработке банковских приложений. Но некоторые пользователи упорно хотят джейлбрейк, хотят иметь root-доступ.
Да, для некоторых приложений джейлбрейк прямо-таки необходим. Например, если вы используете эмуляторы на iOS и другие подобные вещи. Думаю, в случае с банковскими приложениями все зависит от того, сколько пользователей используют root-доступ, а сколько нет. Возможно, придется поступиться той долей, которая его имеет, ради безопасности.
Что вы думаете о CAPTCHA и других методах выявления подбора пароля?
Технологии распознавания изображений стремительно улучшаются. Конечно, пока машина не в состоянии прочитать любую CAPTCHA, но сотни из них — уже вполне может. Поэтому таких способов защиты стоит избегать или использовать лишь в качестве дополнительной меры. Вообще, большинство пользователей CAPTCHA сильно фрустрирует, и зачастую, честно говоря, не оправдывает надежд, которые на нее возлагаются.
Соглашусь с вами. Едва ли можно считать надежным инструмент для проверки, который с каждым днем все проще взломать. А как вы относитесь к концепции “Security through obscurity"? Есть общеизвестные алгоритмы: SSL/TLS и т.п., но всегда можно добавить что-то свое. Вы рекомендуете применять подобные защиты в приложениях или нет?
Само собой. Во-первых, есть автоматизированные способы обфускации кода, например ProGuard. Во-вторых, можно использовать собственные сертификаты клиента при взаимодействии с сервером. Далее, есть шина сообщений EventBus, и если при их передаче использовать протоколы типа ProtoBuf, то эти данные в бинарном виде будет совсем непросто прочесть, потому что для расшифровки требуются спецификации классов. Если имплементировать все это, то система будет довольно сильно защищена.
Тем не менее, очевидно, что любой код можно декомпилировать, и даже самая сложная обфускация оставляет возможность понять, что происходит в коде. Поэтому обычно я просто советую делать код максимально сложным различными способами, но при этом помнить, что, к сожалению, почти всегда найдется кто-то умнее и поймет, что там к чему.
Партнерство с PayPal интересно многим. Какие существуют возможности его технической реализации?
Само собой, для разработчиков у нас есть SDK. Но если говорить об IT-отрасли, банках, крупных корпорациях, то возможности шире. Хороший пример здесь — Microsoft Xbox. PayPal интегрирован в Xbox Live напрямую через доступ к нашему API. Крупным партнерам мы готовы предоставлять доступ к API.
Расскажите, вы в PayPal используете язык Scala? Нет ли планов на него перейти?
Нет, мы используем native Java. Дело не в том, что Scala плохой язык. Нам проще найти квалифицированных инженеров, знающих Java. В свое время почти весь PayPal был написан на C++ и Java, сейчас мы используем Node.js и, конечно, JavaScript. В итоге наш бэкэнд довольно гибкий. PayPal — это SaaS-сервис, и значительная часть его инфраструктуры заточена под использование API. При желании команда может написать проект на Go — у нас в компании он активно используется — на Python, ELAN, Haskell, как пожелаете. Но для Android мы используем native Java.
Думаю, у Google есть веские причины, чтобы не продвигать Scala или другой альтернативный язык. У них есть Dart, у Microsoft, например, есть TypeScript. Но в Windows Phone нет поддержки TypeScript, равно как нет и поддержки Scala на Android. Думаю, дело в том, что эти языки еще не вполне зрелые. У меня нет уверенности в том, что Google вообще будет продвигать именно Scala. Да, его несомненный плюс в том, что он работает на JVM, но Dart — это все-таки их собственная разработка.
В данном случае компания Apple выглядит более уверенной в собственном языке и выборе его для платформы, так что, подводя итог, скажу: я бы скорее использовал Swift на iOS, чем Scala на Android.
