Comments 10
Алладин продаёт примерно по 1500 руб/шт (если сотнями брать, наверняка дешевле) токены, которые генерируют OATH / HOTP пароли. Дёшево и сердито. Есть приложения для iPhone и Android, которые бесплатно генерируют такие пароли. Если сделать TOTP, то совсем дёшево, можно Google authenticator использовать.
А то ведь разорят сотрудники контору своими смс-ками.
А то ведь разорят сотрудники контору своими смс-ками.
Вы правы насчет вариантов использования,
поэтому мы хотим использовать на веб-сервисе за счет модульности.
1. Токены — условно-фиксированная сумма на использование (необходимость больших запросов сразу)
2. TOTP — Google Authenticator — практически за дарма
3. SMS — разорение, но можно варьировать читая статью Закат SMS-уведомлений
4. e-mail — за счет создания БД корпоративной и личной. Где личная, вероятно, имеет 2-факторную аутентификацию.
Например, смотрим тут почтовый сервер поддерживает ли 2-факторную авторизацию.
поэтому мы хотим использовать на веб-сервисе за счет модульности.
1. Токены — условно-фиксированная сумма на использование (необходимость больших запросов сразу)
2. TOTP — Google Authenticator — практически за дарма
3. SMS — разорение, но можно варьировать читая статью Закат SMS-уведомлений
4. e-mail — за счет создания БД корпоративной и личной. Где личная, вероятно, имеет 2-факторную аутентификацию.
Например, смотрим тут почтовый сервер поддерживает ли 2-факторную авторизацию.
А каковы требования к клиентскому месту? Какая там может быть платформа? Планшеты, телефоны поддерживаются?
На сервере HTTPS?
На сервере HTTPS?
Требования к клиентской части:
1. Наличие веб-браузера с поддержкой JS.
2. Насчет, платформы, как раз-таки хотим не привязывать к ней, так как все на браузере
3. Задача возникла из-за необходимости поддержки телефонов, планшетов.
4. Наличие Https, по моему мнению, скоро станет правилом хорошего тона для любого веб-сервиса.
1. Наличие веб-браузера с поддержкой JS.
2. Насчет, платформы, как раз-таки хотим не привязывать к ней, так как все на браузере
3. Задача возникла из-за необходимости поддержки телефонов, планшетов.
4. Наличие Https, по моему мнению, скоро станет правилом хорошего тона для любого веб-сервиса.
Аутентификация же.
Авторизация — процесс предоставления прав аутентифицированному пользователю.
Очень хотел сказать это на весь хабр, потому что видел уже много статей с подобной ошибкой.
Авторизация — процесс предоставления прав аутентифицированному пользователю.
Очень хотел сказать это на весь хабр, потому что видел уже много статей с подобной ошибкой.
Вы, правы.
Исправил название.
Исправил название.
По сути вы придумали систему для защиты от подбора паролей. Эта система блокирует неизвестных пользователей до прохождения ими аутентификации по OTP.
Правильно ли я понимаю, что аутентификация в целевом приложении после прохождения первого этапа проверки IP/user_agent остается прежней?
Разрешите немного покритиковать:
Уязвимость вижу в том, что можно подставить любое значение user_agent и в принципе можно иметь одинаковый IP с жертвой: работать в одном офисе, сидеть в одном интернет-кафе и т.п. То есть ваша защита будет в основном от ботов-сканеров, а от целевой атаки она сильно не защитит.
Правильно ли я понимаю, что аутентификация в целевом приложении после прохождения первого этапа проверки IP/user_agent остается прежней?
Разрешите немного покритиковать:
Уязвимость вижу в том, что можно подставить любое значение user_agent и в принципе можно иметь одинаковый IP с жертвой: работать в одном офисе, сидеть в одном интернет-кафе и т.п. То есть ваша защита будет в основном от ботов-сканеров, а от целевой атаки она сильно не защитит.
Да, получается, что применил защиту от подбора паролей.
1. Защита сработает на низком уровне от ботов сканеров — это уж точно, исключая умных переборов, смотрите 2 п.
2. Защита не сработает при ситуации с одинаковым IP, user-agent, cookie, где существует uid.
Но для целевой атаки нужно:
а. IP, user-agent, cookie, — дальше перебор паролей — где на конечных сервисах есть ограничение по паролю
б. Доступ ко второму фактору, чтобы добавить новый IP адреса. — но следует учитывать при большом количестве,
сведений можно блокировать аккаунт.
Какие у вас есть предложения?
1. Защита сработает на низком уровне от ботов сканеров — это уж точно, исключая умных переборов, смотрите 2 п.
2. Защита не сработает при ситуации с одинаковым IP, user-agent, cookie, где существует uid.
Но для целевой атаки нужно:
а. IP, user-agent, cookie, — дальше перебор паролей — где на конечных сервисах есть ограничение по паролю
б. Доступ ко второму фактору, чтобы добавить новый IP адреса. — но следует учитывать при большом количестве,
сведений можно блокировать аккаунт.
Какие у вас есть предложения?
Есть ли у вас дополнительно предложения?
Проверил на сервисах access логи, перебор паролей ботами очень легко выясняется.
А именно не полный или сокращенный user_agent, либо IP входят в TOR, black листы.
Может у вас иные результаты? И еще пользователи имеют дискретное количество user-agentов, что очень радует при рассмотрении логов.
Проверил на сервисах access логи, перебор паролей ботами очень легко выясняется.
А именно не полный или сокращенный user_agent, либо IP входят в TOR, black листы.
Может у вас иные результаты? И еще пользователи имеют дискретное количество user-agentов, что очень радует при рассмотрении логов.
Sign up to leave a comment.
Двухфакторная аутентификация для корпоративных веб-сервисов