Описание сервиса
Сервис дополнительной аутентификации для внешнего доступа к веб-сервисам компании должен будет осуществлять проверку по UID, в основу формирования которого ложится IP-адрес, с которого он осуществляет доступ и данные user-agent. Если по результатам проверки UID не находится в базе доверенных, то требуется авторизация путем ввода одноразового пароля, отправляемого на телефонный номер или email-аккаунт пользователя.
После авторизации в базу системы аутентификации добавляется UID.
Принципиальная схема работы сервиса и схема работы компонентов приведены ниже.
Базовая архитектура системы
Требования к функционалу мы для себя определили следующие:
- Динамическая авторизация по IP пользователей веб-сервисов Компании (TCP: 80, 443);
- Возможность включения аутентификации для любых сервисов, к примеру, SMTP, IMAP, Jabber, FTP и т.д. (с некоторыми неудобствами для пользователей);
- Возможность разграничения доступа (фильтрации) по веб-сервисам: почта, трекер и т.п.;
- Авторизация новых адресов должна производиться путем ввода разового пароля, получаемого пользователем на заранее введенный моб. телефон или email;
- В качестве базы данных пользователей должен использоваться LDAP;
- Мобильные телефоны, соответствующие пользователю, должны храниться в LDAP, адресной книге портала или локальной базе системы (реализовать 1 или более вариантов);
- Модульность системы: (возможность замены отдельных модулей системы, без серьезных последствий для остальной системы: возможность замены типа аутентификации, возможность замены типа межсетевого экрана или иного ПО);
- Фильтрация пользователей по общей группе (базовая группа/роль дающая пользователю доступ к основному набору сервисов);
- Возможность добавления дополнительных группы (для отдельных сервисов) и фильтрация по данным группам.
- Плавающий срок хранения авторизованных UID, учитываться должны следующие параметры:
— Давность последнего входа (таймаут)
— Общее кол-во входов; - CAPTCHA + таймаут на повторную отправку после 2-3 отправок разовых паролей подряд (к примеру 5 минут), после 5-10 отправки — блокировка;
- При удачной и неудачной аутентификации пользователю должно выводиться сообщение:
— При удачной на несколько секунда показывается баннер «Успешный вход в систему», а затем идет пересылка на искомый адрес
— При неудачной аутентификации показывается сообщение с ошибкой, контакты технической поддержки и ссылку на повторную аутентификацю - Хранение всех ip-адресов с которых пользователь получал аутентификацию;
- Хранение всех ip-адресов с которых пользователь запрашивал аутентификацию;
- Ограничение по ip геолокаций и TOR;
- Универсальность по соотношениям внешних/внутренних адресов;
- Доступность ряда сервисов только для доверенных групп IP (реализуется опциональным фильтром);
- Возможность ограничения e-mail серверов, которые могут быть использованы для получения разового пароля;
Что читатели думают по поводу предложенного способа организации двухфакторной авторизации? Буду рад комментариям и вашим предложениям.
Также, возможно, кто-то может поделиться опытом внедрения аналогичной системы.
Комментарии (10)
cryptoman
08.04.2015 03:19А каковы требования к клиентскому месту? Какая там может быть платформа? Планшеты, телефоны поддерживаются?
На сервере HTTPS?brate1nikoff Автор
08.04.2015 10:42Требования к клиентской части:
1. Наличие веб-браузера с поддержкой JS.
2. Насчет, платформы, как раз-таки хотим не привязывать к ней, так как все на браузере
3. Задача возникла из-за необходимости поддержки телефонов, планшетов.
4. Наличие Https, по моему мнению, скоро станет правилом хорошего тона для любого веб-сервиса.
phozzy
08.04.2015 10:12ipsilon в связке с ipa-server могут помочь. не знаю как у ипсилона с 2-х факторной аутентификацией, но ипа поддерживает.
nmk2002
08.04.2015 11:41Аутентификация же.
Авторизация — процесс предоставления прав аутентифицированному пользователю.
Очень хотел сказать это на весь хабр, потому что видел уже много статей с подобной ошибкой.
nmk2002
08.04.2015 16:44По сути вы придумали систему для защиты от подбора паролей. Эта система блокирует неизвестных пользователей до прохождения ими аутентификации по OTP.
Правильно ли я понимаю, что аутентификация в целевом приложении после прохождения первого этапа проверки IP/user_agent остается прежней?
Разрешите немного покритиковать:
Уязвимость вижу в том, что можно подставить любое значение user_agent и в принципе можно иметь одинаковый IP с жертвой: работать в одном офисе, сидеть в одном интернет-кафе и т.п. То есть ваша защита будет в основном от ботов-сканеров, а от целевой атаки она сильно не защитит.brate1nikoff Автор
22.04.2015 13:12Да, получается, что применил защиту от подбора паролей.
1. Защита сработает на низком уровне от ботов сканеров — это уж точно, исключая умных переборов, смотрите 2 п.
2. Защита не сработает при ситуации с одинаковым IP, user-agent, cookie, где существует uid.
Но для целевой атаки нужно:
а. IP, user-agent, cookie, — дальше перебор паролей — где на конечных сервисах есть ограничение по паролю
б. Доступ ко второму фактору, чтобы добавить новый IP адреса. — но следует учитывать при большом количестве,
сведений можно блокировать аккаунт.
Какие у вас есть предложения?
brate1nikoff Автор
22.04.2015 13:16Есть ли у вас дополнительно предложения?
Проверил на сервисах access логи, перебор паролей ботами очень легко выясняется.
А именно не полный или сокращенный user_agent, либо IP входят в TOR, black листы.
Может у вас иные результаты? И еще пользователи имеют дискретное количество user-agentов, что очень радует при рассмотрении логов.
vlad_shabanov
Алладин продаёт примерно по 1500 руб/шт (если сотнями брать, наверняка дешевле) токены, которые генерируют OATH / HOTP пароли. Дёшево и сердито. Есть приложения для iPhone и Android, которые бесплатно генерируют такие пароли. Если сделать TOTP, то совсем дёшево, можно Google authenticator использовать.
А то ведь разорят сотрудники контору своими смс-ками.
brate1nikoff Автор
Вы правы насчет вариантов использования,
поэтому мы хотим использовать на веб-сервисе за счет модульности.
1. Токены — условно-фиксированная сумма на использование (необходимость больших запросов сразу)
2. TOTP — Google Authenticator — практически за дарма
3. SMS — разорение, но можно варьировать читая статью Закат SMS-уведомлений
4. e-mail — за счет создания БД корпоративной и личной. Где личная, вероятно, имеет 2-факторную аутентификацию.
Например, смотрим тут почтовый сервер поддерживает ли 2-факторную авторизацию.