«Стой! Кто идет?»: аутентификация и авторизация в...

22 октября 2015 года

Стой! Кто идет? Аутентификация и авторизация в

корпоративных системах

Владислав Иофе

Архитектор

О компании

2/67

Проектирование Заказная разработка

Бережное внедрение Масштабных IT-систем

О себе

В 2005 окончил мехмат

Ташкентского государственного университета

С 2004 занимаюсь корпоративным

программным обеспечением

В 2008 пришел в CUSTIS

Работал разработчиком, техлидом,

тимлидом, сейчас занимаюсь архитектурой

3/67

Аннотация

4/67

При проектировании и реализации корпоративных систем всегда

возникает целый ряд вопросов: нужно ли самим разрабатывать

систему контроля доступа? Как аутентификация и авторизация

встраиваются в архитектуру приложения? Возможно ли сделать

вход в систему одновременно простым, удобным и безопасным?

Что делать с паролями от сотен сайтов?!

На семинаре мы:

рассмотрим разные методы аутентификации и авторизации,

попробуем обойти их

познакомимся с промышленными стандартами

и современными трендами в этой сфере

дадим ответы на указанные вопросы с позиций проектировщика,

пользователя, разработчика, тестировщика и инженера сопровождения

уделим особое внимание архитектуре и юзабилити

Семинар рассчитан на студентов и молодых специалистов,

интересующихся проектированием, разработкой и сопровождением

подсистем контроля доступа в корпоративных приложениях

Мотивация

Ни разу не специалист

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

Но в корпоративном ПО много

«сквозной функциональности» (cross-cutting concerns)

Примеры:

Аутентификация (Authentication)

Авторизация (Authorization)

Кэширование (Caching)

Связь (Communication)

Обработка ошибок (Exception Management)

Журналирование (Logging)

Валидация (Validation) 5/67

Сквозная функциональность

Таких функциональностей много одновременно

Нам приходится знать, как они устроены

Мы хотим делать их удобными

Нам приходится думать, как их встраивать в приложение

6/67

Сегодня не будет

Математики

Криптографии

Информационной

безопасности

Зато будут

Методы

UX

Архитектура

План

Вступление, мотивация

Аутентификация

Терминология, способы и пр.

Протоколы

В атаку!

Single sign-on

Перерыв ☕


UX

Настоящее и будущее

Авторизация

Виды


Зрелость модели контроля доступа

Заключение 7/67

Терминология

Идентификация (identification) – это

установление идентификатора субъекта

(пользователя или процесса). Иногда

идентификацией называют сам факт

присвоения идентификатора.

8/67







Аутентификация (authentication, AuthN) –

это проверка подлинности

предъявленного субъектом

идентификатора. В русском языке в термин

вкрался досадный лишний слог.

8/67







Аутентификация (authentication, AuthN) –

это проверка подлинности

предъявленного субъектом

идентификатора. В русском языке в термин

вкрался досадный лишний слог.

Авторизация (authorisation, authorization,

AuthZ) – это определение и предоставление

субъекту прав на выполнение

определенных действий

8/67

Вопрос

Приведите примеры, в которых

происходит идентификация

без аутентификации?

9/67

Терминология и UX

10/67

Вопрос

Банк предоставляет услугу аренды

сейфовой ячейки с анонимным доступом.

Для доступа к ячейке достаточно

предъявить специальную пластиковую

карту (ранее выданную арендатору

ячейки) и ключ

11/67

Вопрос







Проводится ли в таком случае

аутентификация?

11/67

Вопрос







Проводится ли в таком случае

аутентификация?

Кто несет ответственность при пропаже

содержимого ячейки после посещения

ячейки анонимным пользователем?

11/67

Способы аутентификации

Пароли

Public Key Infrastructure (PKI)

Токены – делегирование аутентификации

12/67

Парольная аутентификация

Очень распространенная

Очень уязвимая

48% пользователей сообщают

пароли другим

3% – записывают на бумажке

60–70% – используют одинаковые

пароли на всех сайтах

В среднем около десятка–двух

паролей и ПИНов выдается

каждому пользователю

…13/67

Парольная аутентификация

Очень распространенная

Очень уязвимая

48% пользователей сообщают

пароли другим

3% – записывают на бумажке

60–70% – используют одинаковые

пароли на всех сайтах

В среднем около десятка–двух

паролей и ПИНов выдается

каждому пользователю

…13/67

«Пароли

мертвы…»

Билл Гейтс, 2004

Повышение надежности

Срок действия пароля

Ограничения

на длину снизу

Ограничения на символы

Прочие простые проверки

Не совпадает с логином

Не «123456789»

Не «qwerty»

Ограничение числа

неудачных попыток ввода

14/67

http://goo.gl/Cc6vF7

СИМ-СИМ, ОТКРОЙСЯ!

ХА! ТВОЙ ПАРОЛЬ

ПРОСРОЧЕН!

Квантовый скачок в «Тысяча и одной ночи»

http://goo.gl/Cc6vF7

15/67

http://goo.gl/kyiefE

Сообщения об ошибках,

которые запутывают злоумышленников

ПАРОЛЬ ВЕРНЫЙ, А ИМЯ ПОЛЬЗОВАТЕЛЯ

НЕВЕРНОЕ!

http://goo.gl/kyiefE

Факторы аутентификации

Знание

Долговременный или одноразовый пароль,

кодовое слово, ПИН, паспортные данные, …

16/67


Знание



Обладание

Мобильный, карта, …

16/67


Знание



Обладание


Неотделимость

Отпечатки пальцев, радужная оболочка, сетчатка,

голос, лицо, ДНК, подпись, …

16/67


Знание



Обладание


Неотделимость

Отпечатки пальцев, радужная оболочка, сетчатка,

голос, лицо, ДНК, подпись, …

Интегрированность в общество

Доверенные друзья

16/67

Многофакторная аутентификация

Требование нескольких факторов

(часто разных категорий) существенно

повышает стойкость

17/67

One-time Password (Single-use Password)

В составе двухфакторной

аутентификации наиболее

популярен

Защищает от утечки

пароля или хэша

18/67




популярен



18/67

Навязчив → не подходит

для типовых учетных записей




популярен



18/67

Навязчив → не подходит

для типовых учетных записей

Компромисс – после ввода

одноразового пароля

сохранять для пары

«пользователь-устройство»

super-cookie

Risk-based authentication

В зависимости от степени риска

проводимой операции или набора

факторов может быть запрошена

дополнительная аутентификация

Основной пароль для входа

в интернет-банк, OTP для платежа

Ввод OTP на новом устройстве

19/67

Ау! Где мы?

20/67




Протоколы

В атаку!

Single sign-on

Перерыв ☕


UX



Виды



Заключение

Аутентификация в вебе: HTTP Basic

Логин и пароль передаются на сервер

в открытом виде (base64 не в счет)

21/67

В это время на сервере…

22/67

Аутентификация в вебе: HTTP Digest

Схема challenge-response

HA1=MD5(username:realm:password)

HA2=MD5(method:digestURI)

response=MD5(HA1:nonce:HA2) 23/67

Аутентификация в вебе: Forms

24/67

Аутентификация в вебе: Forms

24/67

Не стандартизована

Вы можете реализовать любой протокол передачи

учетных данных сами!

После успешной аутентификации устанавливается сессия.

Реализуется путем возврата с клиента выданного сервером

authentication ticket-а (через cookie или в адресной строке)

Public and private key

25/67

Уязвимости

26/67

http://goo.gl/vmHsgw

ВЫХОД НА

ПОСАДКУ ГРАЖДАНКА! ВЫ ДОЛЖНЫ ВЫКИНУТЬ ЭТОТ ГЕЛЬ ДЛЯ РУК.

В НЕМ 120 МЛ!

http://goo.gl/vmHsgw

Атака Man-in-the-middle (MITM)

27/67

«Опочтарение» (англ. Going postal), 2010


28/67

Игра в MITM

Каждые два ряда делятся на три

примерно равные команды

Каждая команда играет роли

и Алисы, и Боба, и Мэллори

Реквизит

Пара ключей

Калькулятор (в режиме «Научный»)

Бумага и ручка

29/67

Онлайн калькулятор

Игра в MITM (2)

Задачи

Мэллори

Узнать пароль, который передала Алиса Бобу

Подменить пароль, передаваемый Бобу

Алисы и Боба

Честно шифровать и дешифровывать сообщения

E(e, n, m) = me mod n

D(d, n, c) = cd mod n

Вам выданы две пары ключей

Сообщение m от Алисы – это число от 2 до 9

Если вы скомпрометировали ваш закрытый ключ,

вы можете запросить новую пару ключей у организаторов

30/67


31/67

Сертификат содержит:

Номер

Период действия

Владельца

Открытый ключ владельца

Реквизиты центра сертификации

Криптоалгоритм

Public Key Infrastructure, сертификаты

32/67

Вопрос

А в чем может заключаться MITM-атака

при digest-аутентификации?

33/67

Ау! Где мы?

34/67




Протоколы

В атаку!

Single sign-on

Перерыв ☕


UX



Виды




Новые вводные

Передавать пароли кому попало –

плохая идея!

35/67




Сколько же можно помнить и вбивать

разных паролей?

Компрометация универсального пароля

чревата

35/67




Делегирование аутентификации!




чревата

35/67




Делегирование аутентификации!




чревата

Single sign-on!

35/67

Kerberos

36/67

Сообщения между KDC и участниками шифруются

Сообщения от первой стороны для третьей стороны, передаваемое

второй, шифруется общим ключом первой и третьей сторон

Двусторонняя аутентификация

Усиленная безопасность

37/67

http://goo.gl/HY9tbJ

http://goo.gl/HY9tbJ

Сильная аутентификация

Двухфакторная

Взаимная

Но односторонняя на сегодняшний день

в вебе – норма

38/67

Central Authentication Service (CAS) Protocol

39/67

Single sign-out

Токен аутентификации / TGT действует довольно

долго – например, рабочий день

Инвалидация токена аутентификации / TGT

не приводит к мгновенному прекращению доступа

к приложению

Так же инвалидация сессии приложения приведет

к новой сессии (это же SSO!)

Инвалидация токена аутентификации / TGT приведет

к запросу учетных данных при доступе к другому

приложению в произвольный момент времени

40/67

Single sign-out

Токен аутентификации / TGT действует довольно

долго – например, рабочий день

Инвалидация токена аутентификации / TGT

не приводит к мгновенному прекращению доступа

к приложению

Так же инвалидация сессии приложения приведет

к новой сессии (это же SSO!)

Инвалидация токена аутентификации / TGT приведет

к запросу учетных данных при доступе к другому

приложению в произвольный момент времени

Конечно же, есть попытки обойти… Какие?

40/67

Неудобство и безопасность

41/67

http://goo.gl/6YIfa4

Все!

Я автостопом!

Контроль безопасности

аэропорта

Уберите жидкости, металлические

предметы, снимите обувь

и нижнее белье

http://goo.gl/6YIfa4

Перерыв

42/67

☕

Ау! Где мы?

43/67




Протоколы

В атаку!

Single sign-on

Перерыв ☕


UX



Виды




Пользователи

44/67


Одни наедине

с программой

44/67




Ленивы и любят

комфорт

44/67





комфорт

Изобретательны

в обходе неудобств

44/67





комфорт



Хотят быть

защищенными

44/67





комфорт



Хотят быть

защищенными

Самое слабое звено

44/67

Правило Что не так в юзабилити?

Стремиться к согласованности Ok

Уменьшать число действий в частых сценариях

(например, «горячие клавиши»)

Пользователь не может использовать «горячие клавиши»

Обеспечивать информативную обратную связь

для каждого действия

Невозможно/неудобно увидеть вводимый пароль

Доводить диалоги до логического конца Ok

Не провоцировать на ошибки и предлагать

простую обработку ошибок

Обычно системы только сообщают об успехе или неудаче.

Была ли ошибка в логине или пароле или мы ошиблись

в раскладке клавиатуры – узнать невозможно

Разрешать отмену любого действия Системы отслеживают неудачные попытки и блокируют

учетную запись

Дать пользователю чувство управляемости

системы и почувствовать ответственность

Пользователь отвечает на запросы системы, а не является

инициатором взаимодействий

Кратковременную память загружать

как можно меньше

Пользователи должны помнить уйму правил: как часто менять

пароль, сколько и каких символов, не забыть добавить

специальные символы, раскладку и т. д.

Authentication UX

45/67

Бен Шнейдерман, 1986

Правило Что не так в юзабилити?

Стремиться к согласованности Ok

Уменьшать число действий в частых сценариях

(например, «горячие клавиши»)

Пользователь не может использовать «горячие клавиши»

Обеспечивать информативную обратную связь

для каждого действия

Невозможно/неудобно увидеть вводимый пароль

Доводить диалоги до логического конца Ok

Не провоцировать на ошибки и предлагать

простую обработку ошибок

Обычно системы только сообщают об успехе или неудаче.

Была ли ошибка в логине или пароле или мы ошиблись

в раскладке клавиатуры – узнать невозможно

Разрешать отмену любого действия Системы отслеживают неудачные попытки и блокируют

учетную запись

Дать пользователю чувство управляемости

системы и почувствовать ответственность

Пользователь отвечает на запросы системы, а не является

инициатором взаимодействий

Кратковременную память загружать

как можно меньше

Пользователи должны помнить уйму правил: как часто менять

пароль, сколько и каких символов, не забыть добавить

специальные символы, раскладку и т. д.

А с точки зрения безопасности все эти меры предотвращают

атаки по словарю, угадывание и социальную инженерию

Authentication UX

45/67

Бен Шнейдерман, 1986

Сравнение видов аутентификации

Вид Безопасность UX

Пароли 2 2

Бесконтактные карты 3 3

Генераторы OTP 3 3

PKI (токены, УЭК и пр.) 5 3

Kerberos 5 3

Отпечатки, лицо и пр. 4 3

Подпись 3 3

Распознавание голоса 1 5

46/67

Настоящее и будущее: биометрия

Биометрия

Сетчатка

Радужная оболочка

Отпечатки пальцев

После терактов 9/11 IСAO

(Международная организация гражданской

авиации) разработала стандарты

биометрических документов

Биометрическая аутентификация

перспективна, но не может / не должна быть

единственным способом

47/67

Настоящее и будущее: биометрия

48/67

Аутентификация жестом

Настоящее: протоколы, стандарты

CAS

SAML – SSO для веб, стандартизирует формат

сообщений, а не метод аутентификации

OАuth – протокол аутентификации

и авторизации. Можно использовать

не только в веб, но он неинтероперабелен.

В версии 2.0 за аутентификацию

отвечает OpenID Connect.

49/67

Настоящее и будущее: FIDO Alliance

Сосредоточен на разработке двух открытых

расширяемых стандартов:

UAF – Universal Authentication Framework,

беспарольная аутентификация

с зарегистрированного устройства

U2F – Second Factor UX, двухфакторная

аутентификация с помощью устройств

и поддержкой браузера

50/67

Настоящее и будущее: FIDO Alliance

51/67

Ау! Где мы?

52/67




Протоколы

В атаку!

Single sign-on

Перерыв ☕


UX



Виды




Этапы контроля доступа

53/67


Discretionary access control, DAC

Mandatory access control, MAC

Role-based access control, RBAC

Attribute-based access control, ABAC

Гибридные модели

54/67

Discretionary access control

Избирательное управление доступом

Для каждой пары субъект – объект

задается перечисление допустимых

разрешений (например: Read, Write,

List, Execute)

Часто объект имеет привязанного

субъекта-владельца. Владелец может

устанавливать разрешения

для других субъектов

55/67

Mandatory access control

Мандатное управление доступом

Объекты несут метку конфиденциальности

Субъект ограниченно управляет объектами,

которыми владеет

Модель Белла – Лападулы

Субъекты также несут метку

“No read up”

“No write down”

56/67

Role-based access control

Управление доступом на основе ролей

Субъекту присваивается роль или роли

Выдаются разрешения заданным ролям

Реализует DAC и MAC

Может быть усложнен введением

наследования ролей

Очень распространен

в корпоративных приложениях

Пример: Пользователь может подтвердить

заказ, если его роль – менеджер

57/67

Role-based access control

Управление доступом на основе ролей

Субъекту присваивается роль или роли

Выдаются разрешения заданным ролям

Реализует DAC и MAC

Может быть усложнен введением

наследования ролей

Очень распространен

в корпоративных приложениях


заказ, если его роль – менеджер

Вопрос: Как ограничить менеджера только

московскими заказами?

57/67

Attribute-based access control

Управление доступом на основе атрибутов

Субъекты и объекты наделяются атрибутами

Политики вычисляют условия, заданные через

выражения атрибутов субъекта и объекта


заказ, если подразделение пользователя равно

подразделению, в котором создан заказ,

и должность субъекта – менеджер

58/67

Сравнение методов контроля доступа

59/67

DAC RBAC ABAC

Изменения без участия программиста ✔ ✔ ✔Описание близко́ к бизнес-терминам ✘ ✔ ✔

Простота разработки ✔ ? ✘

Сравнение методов контроля доступа

Кстати, в блоге CUSTIS на «Хабрахабре» вы можете

найти статьи про ABAC:

http://habrahabr.ru/company/custis/blog/248649/


59/67

DAC RBAC ABAC

Изменения без участия программиста ✔ ✔ ✔Описание близко́ к бизнес-терминам ✘ ✔ ✔

Простота разработки ✔ ? ✘



Какая модель контроля доступа

здесь используется?

60/67

Как сквозная функциональность «прорастает»

61/67

Как можно улучшить (1)

62/67

Как можно улучшить (2)

63/67

Зрелость авторизации корпоративного ПО

64/67

Базовая Стандартная Усовершенствованная/

Федеративная

Клиент-серверная

архитектура

N-уровневая


Сервис-

ориентированная



как авторизация

Обычно RBAC RBAC, доступны

глобальные роли

Каждое приложение

реализует авторизацию

Шлюз авторизации,

возможна

кроссплатформенная

авторизация

Контроль доступа

на уровне ресурсов

Контроль доступа

на уровне приложения

Авторизация через

сервисную шину (ESB)

Другие смежные вопросы

Протоколы

SPNEGO/Negotiate

Темы

Identity and Access Management (IAM)

Access Management

User provisioning

Audit

65/67

Ау! Где мы?

66/67




Протоколы

В атаку!

Single sign-on

Перерыв ☕


UX



Виды




Спасибо!

Вопросы?

67/67

Владислав Иофе

[email protected]

mailto:[email protected]

«Стой! Кто идет?»: аутентификация и авторизация в...

Software