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
Запуск приложения
Приложение
GET/ authorize?
client_id=
<id приложения>
oauth.yandex.ru
Запрос разрешения
Разрешаю
<код подтверждения>
POST /token? client_secret=
<пароль приложения>
<токен для доступа к API>
11
Основные проблемы
› Проблема client_id и client_secret
› Проблема с распределением грантов
› Необходимость строгого использования TLS
12
13
Распределение грантов
Одно приложение = один грант
N приложений c M API-вызовами?
14
Как появился XToken
oauth.yandex.ru
Логин и пароль
client_id
и client_secret
access_token
API Яндекс.Диск
Разрешение:
API Яндекс.Диск
16
oauth.yandex.ru
Логин и пароль
client_id_D и
client_secret_D
x_token
API Яндекс.Диск
access_token_YD
Разрешение:
Получение токенов
access_token_YP
API
Яндекс.Парковки
17
Плюсы 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#section1.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());
Пользователь
Интернет
«Плохая» точка
доступа
API (сервис)
30
«Старший брат» следит за тобой
▌ 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
Интернет
Пользователь
«Плохая»
точка доступа
Непонятный
государственный
firewall
API (сервис)
32
Бюджетный вариант пининга
1. Пининг сертификатов (в данном случае своего CA)
2. Использование стойких криптоалгоритмов (никакого SSLv3, стараемся
использовать ECDSA)
3. Как делать TLS на стороне сервера https://events.yandex.ru/lib/talks/2434/
33
Экстремальный вариант
1. Свой Intermediate CA
2. Несколько доверенных Intermediate CA с сертификатами на всех нужных
платформах
3. Возможность динамического изменения списка «запиненных»
4. Черные и белые списки
34
Яндекс.АккаунтМенеджер
Что дает разработчику?
› Не нужно думать про аутентификацию пользователя
› Есть «правильная» реализация TLS
› Скрыты все вопросы реализации OAuth на стороне клиента
36
Что дает СИБ?
› Единую точку концентрированного контроля
› Возможность быстро исправлять ошибки
› Меньше головной боли с TLS
37
Подведём итоги
› Мы научились не просить пользователя вводить пароль для
каждого нашего приложения
› Разобрались с плюсами и минусами OAuth 2.0
› Научились безопасно передавать данные между приложением и
сервером
38
Спасибо за внимание!
Юрий Леонычев
Менеджер проектов
[email protected]
tracer0tong