Інтерв'ю: Тім Мессершмідт, голова PayPal в країнах Європи, Близького Сходу і Африки

image
Багато читачів Хабра слухали доповідь голови 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? Немає планів на нього перейти?
Ні, ми використовуємо Java native. Справа не в тому, що Scala поганий мову. Нам простіше знайти кваліфікованих інженерів, які знають Java. У свій час майже весь PayPal був написаний на C++ і Java, зараз ми використовуємо Node.js і, звичайно, JavaScript. У підсумку наш бекенда досить гнучкий. PayPal — це SaaS-сервіс, і значна частина його інфраструктури заточена під використання API. При бажанні команда може написати проект на Go — у нас в компанії він активно використовується — на Python, ELAN, Haskell, як побажаєте. Але для Android ми використовуємо Java native.
Думаю, у Google є вагомі причини, щоб не просувати Scala або інший альтернативний мову. У них є Dart, у Microsoft, наприклад, є TypeScript. Але в Windows Phone немає підтримки TypeScript, так само як немає і підтримки Scala на Android. Думаю, справа в тому, що ці мови ще не цілком зрілі. У мене немає впевненості в тому, що Google взагалі буде просувати саме Scala. Так, його безсумнівний плюс в тому, що він працює на JVM, але Dart — це все-таки їх власна розробка.
В даному випадку компанія Apple виглядає більш впевненою у власній мові і виборі його для платформи, так що, підбиваючи підсумок, скажу: я б швидше використовував Swift на iOS, ніж Scala на Android.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.