Работаю достаточно давно в направлении обеспечения безопасностью корпоративных средств связи. Основное направление — электронная почта. У нас в компании такая политика, что менеджеры используют свою основную почту и, разумеется, приходится консультировать их в вопросах безопасности на популярных серверах. Вопросов к данным серверам много, но некоторые вызывают особый интерес и непонятно, почему компании-гиганты не задумывались о простых вещах.
1. Уведомление о попытке восстановления доступа к учетной записи путем направления пользователю СМС уведомления, электронного письма на основной и резервный адреса.
2. Принудительная смена пароля, в случае многократной попытки доступа к учетной записи путем подбора (брута) и уведомление пользователя об этом, используя способы из п.1
3. Уведомление при использовании способов из п.1 о доступе с новой машины и при включенной опции проверки пользователя — блокировка доступа. Частично эта функция реализована, но никаких уведомлений на большинстве сервисов нет.
4. Определение пользователя по идентификатору устройства (user_agent + ip + cookies), использование localStorage, контроль пользователя через сессию.
6. Добавление функции, которая позволит контролировать пользователя даже в случае смены IP и чистки cookies, тут поможет и localStorage и другие меры. Например, передачу скрытого идентификатора в коде страницы или адресе страницы и пр.
7. Блокировка многократной попытки восстановления доступа через секретный вопрос. В основном это относится к «Р», где об этом вообще не думают, однако других сервисов тоже касается.
8. Знаете, как безопасный «Г» реагирует, когда вы восстанавливаете доступ к почтовому ящику через резервный адрес e-mail? Показывает 60-70% адреса резервной почты на странице восстановления и в случае перехода по ссылке — просто предлагает сменить пароль. Г — гениально.
9. Отслеживание ботов (брут, чек). Если кодер оказался грамотным и написал хороший софт, его можно отследить по результатам его действий и IP. На миллионы «сбрученных» учетных записей прокси не хватит, а следовательно, они повторялись. Хранить в базе — не так сложно, а при желании можно находить тех из них, которые любят использовать ботов со своих IP без подмены. Некоторые кодеры не утруждают себя даже в смене User-Agent, а многие просто игнорируют требования сайта и, таким образом, находят недостатки системы.
10. Как отследить программу? И надо ли? Да, но не всегда. Вариантов множество и даже есть те, которые не будут хищно пожирать ресурсы серверов. Капчей брутеров не испугать, даже русской, а делать сложные системы — потерять пользователей. Но установить элементарную задержку на повторный ввод пароля/секретного ответа можно. Так или иначе это скажется на результате работы злоумышленника, особенно, если задержка случайная и её нарушение приводит к режиму тревоги, так как позволяет обнаружить бота.
11. Многие кодеры не утруждают себя в имитации действий человека, пропускают галочки, не вчитываются в текст, нарушают порядок параметров в запросе, если за этим следить, то опять же можно легко определить машину, а следовательно, усложнить жизнь кодеров — так мыслить могут не все. Добавьте в форму случайный вопрос и сделайте динамичные поля — это так же усложнит жизнь кодерам, пусть и не всем, но избавит от дураков и позволит сосредоточиться на серьёзных проблемах.
12. Чем больше этапов — тем сложнее. Мы пробовали организовать систему, в которой от пользователя требовалось подтверждение, а если точнее — от его обозревателя, для этого отправляли каждые 10 секунд запрос, если пользователь находился на странице авторизации, если ответа нет — сессия разрушается, так мы убили антикапчу.
13. Работа над ошибками. Как кодеры определяют результат? По результату, допустим, находят указатель error в ответе или адресе. Этот вопрос мы решали таким образом, что ответ с успешной авторизацией не отличался от результата с ошибкой, что требовало от кодера лишней работы по поиску отличий в ответах; вариантов так же оказалось много. Очень эффективно показал себя система, которая блокировала бота, но при этом продолжала сообщать ему, что данные указаны с ошибкой, а дальше небольшой финт и реальный пользователь получал уведомление о том, что пора прекратить вспоминать пароли и обратиться в службу поддержки.
14. Требовать обращения в службу технической поддержки, прежде чем приступить к восстановлению доступа, ставить учетную запись на контроль и предложить ответить на секретный вопрос, для чего нужно подтвердить через другой почтовый адрес свое желание.
15. Основная проблема — это брут, отсутствие localStorage и чистые cookie, новый IP-адрес, новая учетная запись для брута, как определить? Если нет проверки по IP, пользователь не заходил неделю, телефон не подключен и нет резервного адреса, что делать? Первый вариант — запретить такие учетные записи, потребовать прикрепления телефона, дополнительного адреса электронной почты и задать вопрос — а нужна ли такая почта пользователю? Ответит — да, значит, пойдет на все меры, это в его же интересах. В противном случае будут “сливы”, накопленные за годы брута.
16. Обеспечить безопасность IMAP и POP3, требовать установить уникальные пароли, отличные от паролей учетной записи, подтверждать устройства и жестко контролировать подключение по этим протоколам. Опять же, хотите «удаленку»? Подключайте телефон, нет? Подключайте почту и сидите через веб-интерфейс. Мера жесткая, но если станет стандартом — другого выбора не будет.
Можно в деталях описывать множество вариантов обеспечения безопасности или приводить примеры уязвимостей, на которые просто закрывают глаза даже крупные ресурсы. Зачем это нужно, если можно свою вину в отсутствии должной безопасности свалить на пользователя, мол это у него вирусы, трояны, кривые руки итд., а по факту демонстрировать наплевательское отношение в адрес своих же пользователей. Стыдно, что сегодня так поступают крупные компании, которые закрывали глаза все эти годы на очевидные проблемы и жалобы пользователей, а в конечном итоге просто на них же свалили всю вину. Хочется извиниться за такой сервис перед всеми пользователями, потерявшими веру в хорошее отношение и безопасность в Сети, за то, что не уважающие себя и своих клиентов владельцы крупных сервисов миллионные сливы паролей называют «исключением» и «ошибкой пользователя». Признать то, что их сервис позволил этому произойти, у них не хватает духа. Это хороший сигнал для тех, кто смотрит на такие вещи иначе, кто готов создать свой сервис, ориентированный на клиента. С учетом всех последних скандальных историй, с просмотром ботами писем пользователей, сливами и ограничениями, хороший и безопасный сервис получил все преференции для быстрого старта, и я убежден, что в ближайшее время мы увидим их появление или вторую жизнь аутсайдеров рынка.
Автор:
