Как стать автором
Обновить

Комментарии 10

Алладин продаёт примерно по 1500 руб/шт (если сотнями брать, наверняка дешевле) токены, которые генерируют OATH / HOTP пароли. Дёшево и сердито. Есть приложения для iPhone и Android, которые бесплатно генерируют такие пароли. Если сделать TOTP, то совсем дёшево, можно Google authenticator использовать.

А то ведь разорят сотрудники контору своими смс-ками.
Вы правы насчет вариантов использования,
поэтому мы хотим использовать на веб-сервисе за счет модульности.

1. Токены — условно-фиксированная сумма на использование (необходимость больших запросов сразу)
2. TOTP — Google Authenticator — практически за дарма
3. SMS — разорение, но можно варьировать читая статью Закат SMS-уведомлений
4. e-mail — за счет создания БД корпоративной и личной. Где личная, вероятно, имеет 2-факторную аутентификацию.
Например, смотрим тут почтовый сервер поддерживает ли 2-факторную авторизацию.

А каковы требования к клиентскому месту? Какая там может быть платформа? Планшеты, телефоны поддерживаются?
На сервере HTTPS?
Требования к клиентской части:
1. Наличие веб-браузера с поддержкой JS.
2. Насчет, платформы, как раз-таки хотим не привязывать к ней, так как все на браузере
3. Задача возникла из-за необходимости поддержки телефонов, планшетов.
4. Наличие Https, по моему мнению, скоро станет правилом хорошего тона для любого веб-сервиса.
НЛО прилетело и опубликовало эту надпись здесь
Аутентификация же.
Авторизация — процесс предоставления прав аутентифицированному пользователю.
Очень хотел сказать это на весь хабр, потому что видел уже много статей с подобной ошибкой.
Вы, правы.
Исправил название.

По сути вы придумали систему для защиты от подбора паролей. Эта система блокирует неизвестных пользователей до прохождения ими аутентификации по OTP.
Правильно ли я понимаю, что аутентификация в целевом приложении после прохождения первого этапа проверки IP/user_agent остается прежней?
Разрешите немного покритиковать:
Уязвимость вижу в том, что можно подставить любое значение user_agent и в принципе можно иметь одинаковый IP с жертвой: работать в одном офисе, сидеть в одном интернет-кафе и т.п. То есть ваша защита будет в основном от ботов-сканеров, а от целевой атаки она сильно не защитит.
Да, получается, что применил защиту от подбора паролей.
1. Защита сработает на низком уровне от ботов сканеров — это уж точно, исключая умных переборов, смотрите 2 п.
2. Защита не сработает при ситуации с одинаковым IP, user-agent, cookie, где существует uid.

Но для целевой атаки нужно:
а. IP, user-agent, cookie, — дальше перебор паролей — где на конечных сервисах есть ограничение по паролю
б. Доступ ко второму фактору, чтобы добавить новый IP адреса. — но следует учитывать при большом количестве,
сведений можно блокировать аккаунт.

Какие у вас есть предложения?
Есть ли у вас дополнительно предложения?
Проверил на сервисах access логи, перебор паролей ботами очень легко выясняется.
А именно не полный или сокращенный user_agent, либо IP входят в TOR, black листы.
Может у вас иные результаты? И еще пользователи имеют дискретное количество user-agentов, что очень радует при рассмотрении логов.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории