Яндекс.АккаунтМенеджер - mobius 2015
TRANSCRIPT
Разделяй и властвуй
Управление учетными записями пользователей
С чего все начиналось…
Мобильные приложения Яндекса когда-то
› Были сделаны самодельные системы аутентификации для Фоток и Карт
› Изначально использовались токены
4
Мобильные приложения Яндекса сейчас
› 31 приложение для Android
› 24 приложения для iOS
› Более 20 приложений используют учетные записи
5
Способы аутентификации
› Пароли
› Cookie
› Длинные пароли
› Токены (OAuth 2.0 токены)
6
7
Почему выбрали OAuth 2.0?
› Удобен для реализации на стороне клиента
› Есть возможности для разграничения доступа
› Легко прикрутить к HTTP API
› Является стандартом (RFC6749, RFC6750)
8
Проблемы OAuth 2.0
Как работает наш OAuth
› https://tech.yandex.ru/oauth/doc/dg/concepts/about-docpage/
10
11
oauth.yandex.ruЗапуск приложения
Запрос разрешения
GET/ authorize?client_id=<id приложения>
Разрешаю
Приложение
<код подтверждения>
<токен для доступа к API>
POST /token? client_secret=<пароль приложения>
Основные проблемы
› Проблема client_id и client_secret
› Проблема с распределением грантов
› Необходимость строгого использования TLS
12
13
Распределение грантов
Одно приложение = один грант
14
N приложений c M API-вызовами?
Как появился XToken
16
client_idи client_secret
access_token
oauth.yandex.ruЛогин и пароль
Разрешение: API Яндекс.Диск
API Яндекс.Диск
17
client_id_D и client_secret_D
x_tokenAPI Яндекс.Диск
Логин и пароль
access_token_YD
access_token_YPРазрешение:
Получение токенов
oauth.yandex.ru
API Яндекс.Парковки
Плюсы XToken
› Возможность однократного ввода логина и пароля пользователем
› Гибкость при установке или удалении приложений
18
Минусы XToken
› Теоретически меньшая безопасность
› Более сложная схема работы при выписывании токенов и их отзыве
19
Хранение токенов на устройстве
› iOS – shared keychain (нужно помнить про группы доступа)
› Android – content provider (не используем Android AM)
20
AM и SSL-pinning
Решаем три проблемы
› Найти соединения, где необходим TLS
› Дать разработчикам «правильный» TLS
› Не допустить MitM-атак
22
OAuth 2.0 и TLS
› “Implementations MAY also support additional transport-layer security mechanisms that meet their security requirements” https://tools.ietf.org/html/rfc6749#section-1.6
› И требование использовать TLS по всему RFC
23
Как найти все API вызовы
› Эмулятор и tcpdump
› Функциональное тестирование и MitM-proxy
› Исходные коды и статический анализ
24
Трюк для iOS
› NSURLProtocol позволяет определить свой протокол, который перехватит всё сетевое взаимодействие
› https://events.yandex.ru/lib/talks/1076/
› http://nshipster.com/nsurlprotocol/
25
Пример простого сниффера
Sniffer.h
#import <Foundation/Foundation.h>
@interface MySniffer : NSURLProtocol
@end
Пример простого сниффера
Sniffer.m
#import ”Sniffer.h”
@implementation MySniffer
+ (BOOL)canInitWithRequest:(NSURLRequest *)request
{
NSLog(@"%@, %@", request.allHTTPHeaderFields, request.URL);
return NO;
}
@end
Типичная ошибка
Нет нормальной проверки сертификатов
NSMutableURLRequest *request = [self requestWithMethod:@"GET" path:reques
tURL parameters:nil];
AFHTTPRequestOperation *operation = [[AFHTTPRequestOperation alloc] initW
ithRequest:request];
operation.allowsInvalidSSLCertificate = YES;
Та же ошибка в Android
Используется AllowAllHostnameVerifier или X509TrustManager
пропускающий все сертификаты
SSLContext sslContext = SSLContext.getInstance("SSL");
sslContext.init(null, new TrustManager[] { new X509TrustManager() {
public X509Certificate[] getAcceptedIssuers() {
return null;
}
} }, new SecureRandom());
30
Интернет
API (сервис)«Плохая» точка доступа
Пользователь
«Старший брат» следит за тобой
▌ iOS
› http://support.apple.com/en-us/ht5012
› 209 сертификатов
▌ Android
› http://kurrytran.blogspot.ru/2013/05/how-to-get-root-certification.html (для < 4.0 ICS)
› Settings – Security – Trusted Credentials
31
32
Интернет
API (сервис)«Плохая» точка доступа
Пользователь
Непонятныйгосударственный
firewall
Бюджетный вариант пининга
33
1. Пининг сертификатов (в данном случае своего CA)
2. Использование стойких криптоалгоритмов (никакого SSLv3, стараемся использовать ECDSA)
3. Как делать TLS на стороне сервера https://events.yandex.ru/lib/talks/2434/
Экстремальный вариант
34
1. Свой Intermediate CA
2. Несколько доверенных Intermediate CA с сертификатами на всех нужных платформах
3. Возможность динамического изменения списка «запиненных»
4. Черные и белые списки
Яндекс.АккаунтМенеджер
Что дает разработчику?
› Не нужно думать про аутентификацию пользователя
› Есть «правильная» реализация TLS
› Скрыты все вопросы реализации OAuth на стороне клиента
36
Что дает СИБ?
› Единую точку концентрированного контроля
› Возможность быстро исправлять ошибки
› Меньше головной боли с TLS
37
Подведём итоги
› Мы научились не просить пользователя вводить пароль для каждого нашего приложения
› Разобрались с плюсами и минусами OAuth 2.0
› Научились безопасно передавать данные между приложением и сервером
38
Спасибо за внимание!
