Как сделать код безопасности на сайте
Обновлено: 07.07.2024
В статье приведен ряд профилактических рекомендаций, которые помогут защитить ваш сайт от заражения.
Как помешать злоумышленникам разместить вредоносный код на своем сайте
Используйте надежное программное обеспечение.
Загружайте дистрибутивы веб-приложений и расширения/плагины для CMS из проверенных источников.
Регулярно обновляйте CMS и серверное ПО, следите за новостями об уязвимостях используемой CMS.
Регулярно проводите аудит безопасности серверов.
После установки CMS удаляйте установочные и отладочные скрипты.
Используйте сложные пароли от веб-серверного ПО (FTP, SSH, административные панели хостинга и CMS).
Сложный пароль содержит не менее 11 символов и включает в себя буквы в разных регистрах, цифры, и специальные символы.
Не используйте одинаковые пароли для доступа к разным сервисам.
Даже самые надежные пароли рекомендуется менять раз в три месяца, чтобы обезопаситься от случайной утечки.
Не сохраняйте важные пароли в веб-браузерах, файловых менеджерах, а также FTP-, SSH- и прочих клиентах.
Следите за безопасностью рабочих компьютеров.
На всех компьютерах, с которых ведется работа с сервером (машины вебмастера, администратора, контент-менеджера, менеджера по продажам и т.д.) должны быть установлены антивирусы с поддержкой регулярных обновлений. Также необходимо своевременно обновлять операционную систему и прикладные программы.
Контролируйте данные, вводимые пользователями.
Фильтруйте HTML-разметку во вводимых пользователями данных, которые могут встраиваться в код страниц сайта.
Получая данные от пользователя, проверяйте на сервере, допустим ли их размер, входят ли переданные значения в допустимые списки и интервалы.
Никогда не вставляйте полученные от пользователей данные напрямую в вызовы eval() , SQL-запросы или в преобразование типов. Всегда проверяйте и очищайте полученную информацию от потенциально опасных элементов.
Не оставляйте в рабочей версии кода параметры, введенные для отладки, эксперименты с новой или отключенной функциональностью.
Контролируйте права доступа пользователей, в частности, предусмотрите защиту от межсайтовой подделки запросов (CSRF).
Ограничьте доступ к панелям администрирования CMS и БД (например, phpMyAdmin), а также:
к резервным копиям кода;
к конфигурационным файлам;
к метаданным систем контроля версий (например, к каталогам .svn или .git ).
По возможности скрывайте версии серверного ПО (CMS, веб-сервера, интерпретатора сценариев, СУБД).
Настраивайте файрволы и сетевую инфраструктуру так, чтобы были разрешены только соединения, необходимые для работы.
Старайтесь избежать кликджекинга. Простейшие проверки, предназначенные для этого:
Рекомендуем хостингам регулярно проверять поддерживаемые сайты с помощью Safe Browsing API Яндекса или API Вебмастера.
Как не дать разместить вредоносный код пользователям сайта
Если посетители вашего сайта могут загружать файлы или текст на ваш сайт, вредоносный код может оказаться в загруженном контенте (умышленно или случайно).
Защищайтесь от ботов.
Для защиты от роботов-взломщиков можно использовать специальные плагины к CMS или искать IP-адреса пользователей в черных списках.
Проверяйте данные, которые могут ввести пользователи.
Не давайте возможности вставлять JavaScript-код внутри script , в тегах или ссылках.
Не вставляйте напрямую на страницы сайта код в тегах iframe , object , embed , и не подгружайте файлы .jar , .swf и .pdf (с их помощью сайт может генерировать такие теги автоматически).
Проверяйте вставленные пользователями ссылки, например, через Safe Browsing API Яндекса.
Как не разместить вредоносный код случайно
Проверяйте используемое ПО.
Скачивайте дистрибутивы CMS, виджеты, библиотеки только с официальных сайтов или из проверенных источников.
Если какой-то дистрибутив приходится скачать с сомнительного сайта, обязательно проверьте наличие в нем вредоносного кода.
Внимательно изучайте код любых дополнительных компонентов, которые вы хотите добавить в CMS.
Будьте осторожны с рекламными блоками и кодом.
Вставляйте на страницы своего сайта только те рекламные блоки, которые были предоставлены проверенными рекламными системами.
Прежде чем подключить сайт к новой партнерской системе, ищите отзывы о ней и примеры распространяемого контента.
По возможности встраивайте на свои страницы статический контент (ссылки и картинки). Избегайте подгружаемых элементов script и iframe . Flash, Java и ActiveX-компоненты принимайте только в виде исходного кода, который можно проверить и скомпилировать самостоятельно.
Не используйте партнёрские программы со скрытыми блоками.
Внимательно контролируйте доступы к служебным интерфейсам. Доступом к сайту должны обладать только те, кому доступ необходим и пока он необходим.
Отзывайте доступ специалистов, выполнявших разовые работы, предыдущих владельцев, людей, не ответственных за работу сайта (например, специалистов по маркетингу или руководителей).
Привлекая к работе над сайтом посторонних людей, старайтесь получить какие-нибудь рекомендации. После окончания работ — отключайте их учетные записи или меняйте пароли.
Если ваш сайт статический, некоторые партнёрские системы могут запросить доступ по FTP, чтобы самостоятельно менять баннеры. Предоставлять такой доступ опасно: если база данных партнерской системы будет взломана, злоумышленники получат прямой доступ к файлам на вашем сайте.
Ищите надежный и качественный хостинг. Не все хостеры качественно обеспечивают безопасность своих серверов, а некоторые могут сознательно заражать сайты клиентов.
В статье рассмотрим такую важную составляющую работы сайта как информационная безопасность. Определим основные принципы, угрозы и рекомендации по повышению уровня защищенности сайта.
Также коснемся нашей веб-платформы Falcon Space в контексте вопросов информационной безопасности.
Принципы. Что учесть при обеспечении информационной безопасности сайта
Безопасность определяется слабейшим звеном в защите
Если в вашем доме массивная стальная дверь, но окна при этом всегда открыты, общее состояние защищенности будет невысоким. Вы можете ставить различные антивирусы, закрыть все порты на сервере, но если при этом ваши пользовали ставят пароли 123456 и пишут их на бумажке на рабочем столе на ПК, то риски быть взломанным очень высоки.
Поэтому фокус внимания всегда должен быть на наиболее слабом на данный момент звене.
Экономическое обоснование взлома
Зачем взламывают какую-либо систему? Для получения некой выгоды. Если взлом стоит дешевле этой выгоды, то игра стоит свеч. Задача защиты сделать взлом невыгодным.
Необходимо максимально повысить стоимость взлома. Это в первую очередь время на взлом и аппаратные/программные ресурсы взломщика.
Что защищать на сайте? КЦД
Что может плохого случиться с информацией на сайте?
- Может возникнуть утечка данных - будет потеряна конфиденциальность информации.
- Данные могут повредиться - информация потеряет целостность.
- Информация может стать недоступна пользователю - потеряна доступность.
Все меры по безопасности так или иначе направлены на обеспечение конфиденциальности, целостности или доступности информации.
Человеческий фактор в информационной безопасности - самый тонкий момент
Человек слаб. У него есть множество соблазнов и уязвимых мест. Кого-то можно подкупить, кого-то запугать, а кто-то может по простоте дать доступ злоумышленнику по телефону.
Более опасен для системы внутренний человек (инсайдер), а не человек с улицы. У него может быть много причин для помощи злоумышленнику: обидели на работе, не дают повышения, "подработка", компромат на него и т.д. Имея доступ во внутреннюю часть систем человек становится точкой входа в систему для злоумышленника.
Угрозы для сайта и адекватные им меры
Не нужно стрелять из пушки по воробьям. Ваша защита должна соответствовать уровню угроз и модели злоумышленника. Если против вас работает АНБ, то ресурсов на защиту, вероятно, потребуется много (но, наверняка, в этом случае вам есть, что защищать).
Важно представлять себе примерный портрет злоумышленника и его возможности.
Это позволит вам понять, что может сделать злоумышленник, какие цели преследует (что он сможет с вас получить в случае успешного взлома) и какие варианты атаки он может реализовать.
Непрерывность состояния защищенности
Система безопасности должна работать непрерывно во времени. Странно будет выглядеть инкассаторы, которые при перевозке денег в 13:00 все разом поехали в кафе обедать, оставив деньги в машине.
Необходимо предусмотреть факторы, которые могут "оборвать" эту непрерывность состояния защищенности: выключили свет, уволился системный администратор, необходимо обновить какой-то ПО или ключ шифрования.
Подход риск менеджмента - риски информационной безопасности сайта
Информационная безопасность - это та же работа с рисками.
Риск - это вероятность и критичность для бизнеса.
Оцените свои риски информационной безопасности в плане вероятности возникновения негативного события и степени критичности. Далее продумайте меры, которые могут снизить вероятность возникновения риска и меры по снижению критичности.
Угрозы информационной безопасности для сайта по КЦД и меры противодействия угрозам безопасности
Первый вопрос - откуда ноги растут? Кто злоумышленник, и зачем ему нужно взламывать наш сайт?
Что он получит? Какие возможности для взлома у него есть? Какой бюджет на взлом он может выделить?
Понимая эти вопросы, вы сможете более адекватно выработать ряд мер для защиты своего сайта.
Разберем основные меры защиты сайта по угрозам для конфиденциальности, целостности и доступности информации на сайте. Некоторые из мер относятся сразу к нескольким типам.
Меры по обеспечению конфиденциальности
Также SSL дает некую гарантию пользователю, что он взаимодействует именно с нужным сайтом (в браузере видна информация чей это сертификат).
Защита от разных атак на веб приложение (XSS, SQL инъекции).
Пользователь может ввести некий код через поля форм и этот код может негативно сказаться на работе системе.
Например, XSS атака подразумевает ввод JS кода, который сохранится в базе сайта (например, в виде тикета в службу поддержки), затем другой пользователь запросит эти данные из базы и этот вредоносный код JS выполнится от имени этого пользователя.
В Falcon Space мы производим защиту от XSS на уровне ролей. Только некоторые определенные в настройках роли могут сохранять HTML разметку в системе. Для всех других разметка сохраняется в кодированном виде (что не позволяет внедрить JS код).
Атака SQL Injection - вводится код SQL, который видоизменяет SQL выполняемый на сервере. Это очень опасная штука, т.к. позволяет вводить прямые команды в БД (например, удалять данные или считывать данные из таблиц). Защита от SQL инъекций - весь код sql выполнять в хранимых процедурах с параметрами без использования динамически генерируемых процедур.
В Falcon Space вся обработка построена на хранимых процедурах с параметрами.
Обновление ПО
Периодически разработчики находят уязвимости в ПО и выпускают обновления. Если не делать обновления, то есть риск, что этой уязвимостью воспользуются злоумышленники. Необходимо проводить профилактику сервера и ПО на нем.
Организационные меры и обучение сотрудников
Можно так построить бизнес-процесс, чтобы снизить вероятность утечки конфиденциальности и целостности. Пример - создание и и подпись платежных документов разными людьми. Снижается вероятность злоупотреблений со стороны кассира и контроллера.
Второе направление - это обучение. Люди должны хорошо знать свой участок и роль в процессах. Что они могут, а что делать нельзя. Знать, какие бывают ситуации и как они должны реагировать на них.
Меры по обеспечению целостности информации на сайте
Транзакции
Если ряд операций должны быть выполнены как единое целое, то они должны быть заключены в единую транзакцию, которая либо полностью выполнится, либо откатится.
Это имеет важное значение для таких случаев как пополнение баланса. В рамках одной транзакции происходит изменение статусов платежей, изменение баланса пользователя и логирование этой операции. В случае возникновения проблем система будет всегда оставаться в целостном состоянии, т.к. не будет такой ситуации, что статус мы изменили, а пополнение баланса и логирования не произошло.
Платформа Falcon Space позволяет менять SQL скрипты, т.к. вы можете самостоятельно задать транзакции в системе под свои нужды.
Контроль целостности данных через скрипты
Данные в системе нужно периодически проверять. Код сайта может содержать ошибки, которые будут приводить к нарушению целостности. В этом случае необходимо создать ряд скриптов, которые будут проверять по бизнес-логике целостность данных в таблицах. Можно запускать подобные скрипты ежедневно для нахождения коллизий в данных, после чего выдавать отчет на почту.
В платформе Falcon Space есть подобный отчет для поиска медленных запросов. Ежедневно выполняется скрипт поиска проблемных запросов и отправляется краткий отчет на почту.
Правильная структура данных в базе данных
Если структура базы данных имеет проблемы, то при частичном обновлении данных может нарушиться целостность данных. Необходимо использовать нормализацию базы данных достаточного уровня, вводить ограничения, устанавливать внешние ключи и т.д.
Поиск и исправление ошибок в ПО (профилактика, обслуживание)
Глупо думать, что вы разработали 1 раз сайт, и он будет теперь работать бесперебойно без обслуживания, без администрирования хостинга и т.д.
Если сайт разрабатывался, а не просто был сделан на из готовых блоков, то в нем могут быть ошибки. И вылезти они могут не сразу, а в ходе эксплуатации.
Необходимо проводить профилактику приложения - смотреть логи, анализировать быстродействие, искать проблемные точки.
Это сказывается как на качестве сайта, так и на состоянии защищенности. В ходе таких обзоров могут быть обнаружены бреши, которые на стадии разработки сайта никак себя не проявляли.
Меры по обеспечению доступности сайта
Защита от DOS
DOS атака - это организация множества запросов на сайт с целью его перегрузки. Происходит отказ в обслуживании - сервер просто начинает не справляться с возникшей нагрузкой.
Защита от DOS атаки лежит в первую очередь на хостере. Задайте вопросы по поводу защиты от DOS атак своему хостеру.
Также вы можете блокировать подозрительные IP адреса, т.к. ваш сервер просто не будет обрабатывать некоторые запросы. Тут главное не перестараться, т.к. таким образом, можно отсеять реальных пользователей вместе с ботами (программы, заходящие на сайт).
Нагрузочное тестирование
Проводите нагрузочные тесты, находите проблемные места в своем сайте про производительности. То, что хорошо работает на малом объеме, может очень тормозить на больших оборотах.
Резервный сервер
Если будет полный трабл с основным сервером, хорошо бы иметь возможность быстро восстановить работу приложения на резервном сервере. В идеале сделать работу несколько серверов в связке, чтобы при выходе из строя одного сервера, запросы шли на другой сервер.
Мониторинг доступности и оповещения
Рекомендации по обеспечению информационной безопасности сайта
Пароли
Используйте сложные пароли, но которые реально запомнить. В этом случае пользователь не будет записывать их на бумажку. Пример: Kata007pulta* Пароль содержит спецсимволы, цифры, верхний регистр, более 8 символов. Такой пароль сложно подобрать, но легко запомнить пользователю.
Периодически меняйте важные пароли. Если храните пароли, то сделайте архив с паролем, и храните в нем Excel с паролями локально на своем ПК.
Минимальный доступ и убрать все ненужные элементы
У каждого пользователя должен быть минимальный уровень доступа, достаточный для его работы. Не нужно давать больше, чем ему нужно для выполнения служебных обязанностей. Атаке извне может быть подвергнут любой элемент вашей системы, и чем меньше возможностей у этого элемента, тем лучше.
Закрывайте доступ через неиспользуемые порты на сервере. Каждый порт - потенциальная точка входа для злоумышленника.
Обновления
Ставьте обновления своевременно. Заведите регламент работ по обновлению основного ПО - ПО сервера, CMS сайта, антивирус и т.д.
Инсайдеры
Инсайдер гораздо опаснее внешнего злоумышленника. У него уже есть доступ в системе. К нему есть некоторое доверие со стороны других людей в системе. Он может долгое время незаметно пакостить в системе. Создайте условия для максимальной удовлетворенности людей в системе, со всеми расставайтесь полюбовно, не оставляя долгов перед другими (особенно перед программистами и системными администраторами).
Чем сложнее решение, тем больше дыр и ошибок
Сложность программы идет рука об руку с ошибками. Чем больше кода, чем больше возможностей в нем, тем больше может быть багов в нем.
А баги - это риск-фактор для взлома системы. Уменьшайте сложность системы. По мере развития она и так будет усложняться по естественным причинам (много данных, обязательные хотелки пользователей и т.д.) - не стоит все усложнять на первых этапах своими же руками.
Используйте основы риск менеджмента
Проводите пересмотр рисков и мер по уменьшению критичности и вероятности возникновения риска.
Риски - это не что-то, что высечено на камне. Вы провели некие работы по снижению рисков, и необходимо пересмотреть их, сделать акцент на другие риски.
Не публикуйте в общий доступ лишней информации
Внешний злоумышленник собирает информацию сначала из открытых источников. По крупицам ищет уязвимости системы, изучает структуру системы и возможные точки входа в него.
Не публикуйте в общий доступ информацию, чувствительную ко взлому. Тем самым вы уменьшите вероятность взлома внешним злоумышленником.
Не ставьте ничего на телефон и ПК
На рабочих станциях (и тем более на серверах) не должно быть ненужного ПО. Любое дополнительное - потенциальный риск получить вирус или другое вредоносное ПО.
Уязвимости в ПО также могут быть точкой входа в систему.
Поэтому ставьте приложения только из проверенных источников и давайте этим приложениям минимум необходимых прав.
Для программистов - не доверять вводу юзера
Когда сайт обрабатывает запрос от браузера, нельзя доверять введенным данным от пользователя.
В платформе Falcon Space практически любая процедура принимает параметр @username, который находится внутри системы, а не получен от браузера. Именно на него мы ориентируемся при авторизации доступа к определенным ресурсам.
К примеру, пришел запрос GetOrder и передан параметр orderID - можем ли бы просто выдать заказ по orderID. Нет, т.к. юзер мог указать чужой orderID. Мы должны проверить сначала (по @username) имеет ли текущий пользователь доступ к этому объекту.
Бекапы, бекапы, бекапы!
Делайте бекапы базы данных и файлов сайта. Ежедневно должны создаваться бекапы. Их нужно копировать на удаленное хранилище (яндекс диск или dropbox). В случае, если сгорит сервер, ваши бекапы будут в сохранности.
Периодически проверяйте, что ваши бекапы делаются и они пригодны для использования (может случиться так, что бекапы делаются, но они повреждены и не могут быть использованы; либо делаются сильно усеченные и не позволяют полностью восстановить информацию).
Регламент обслуживания и контроля
Нет смысла описывать угрозы, считать риски без проведения работ по повышению уровня защищенности сайта. Реализовывать эти работы можно в виде регламентов обслуживания системы - т.е. это совокупность неких периодических действий, направленных на реализацию мер по обеспечению безопасности сайта.
Регламенты могут разниться и будут зависеть от специфики, масштаба вашего проекта, модели угроз и ваших возможностей/приоритетов.
Регламент обслуживания сервера
Выполняет системный администратор, проверяет критичные параметры сервера (память, место на диске, процессор), изучает системные логи, проводит обновление ПО, смотрит за бекапами сайта и базы данных.
Регламент профилактики по приложению
Также имеет смысл проводить диагностику быстродействия, искать слабые запросы и оптимизировать их.
Плановое обновление паролей
Вы можете проводить процедуру изменения пароля для важных точек входа - соединение с базой данных, доступ к хостинг панелям, доступ к серверу, доступ к платежным аккаунтам и т.д.
Регламент пересмотра состава угроз и соответствующих мер (риск менеджмент)
Хотя бы раз полгода имеет смысл возвращаться к рискам информационной безопасности и обновлять меры, регламенты для более адекватной защиты от вновь выявленных угроз.
Заключение
Информационная безопасность требует времени и средств. А видимой отдачи от нее нет. Что-то сделали, внедрили, а прямой выгоды от этого нет.
Но есть риски, которые могут в итоге принести колоссальный ущерб. Сделав небольшие усилия (20% по Парето), вы можете обеспечить значительную степень защищенности сайта и усложнить взлом для злоумышленника (т.е. защититься от 80% атак).
Начните с минимальных базовых моментов по обеспечению безопасности, итеративно добавляя новые элементы по мере необходимости.
Есть прекрасный закон Мерфи: "Если что-то может пойти не так, оно пойдёт не так".
Смысл его не в том, что вас обязательно взломают, но смысл в том, что кого-то когда-то непременно взломают. Будет ли это ваш сайт или чужой, завтра или через год, но это точно произойдет.
Для начала, вы можете проверить безопасность сайта нашим инструментом. Вот пример такого анализа. Как видно из отчета, не все в порядке. Защиту сайта можно улучшить.
Чтобы защитить свой сайт, представляем вам код PHP, специально для пользователей СеоЛик:
Почему SMS — не лучший выбор для двухфакторной аутентификации, и какие существуют альтернативы.
18 октября 2018
За последние пару лет идея двухфакторной аутентификации, о которой так долго говорили гики, сильно продвинулась в массы. Однако до сих пор в большинстве случаев речь идет о двухфакторной аутентификации при помощи одноразовых паролей, приходящих в SMS. А это, к сожалению, не очень-то надежный вариант. Вот что может пойти не так:
- Пароль в SMS можно подсмотреть, если у вас включен показ уведомлений на экране блокировки.
- Даже если показ уведомлений отключен, можно извлечь SIM-карту из смартфона, установить в другой смартфон и принять SMS с паролем.
- SMS с паролем может перехватить пробравшийся в смартфон троян.
- Также с помощью различных махинаций (убеждение, подкуп, сговор и так далее) можно заполучить новую SIM-карту с номером жертвы в салоне сотовой связи. Тогда SMS будут приходить на эту карту, а телефон жертвы просто не будет связываться с сетью.
- Наконец, SMS с паролем может быть перехвачена через фундаментальную уязвимость в протоколе SS7, по которому эти SMS передаются.
Надо заметить, что даже самый трудоемкий и высокотехнологичный из перечисленных методов перехвата пароля в SMS — с помощью взлома протокола SS7 — уже был использован на практике. Так что речь не о теоретической возможности возникновения неприятностей, а о вполне практической угрозе.
В общем, пароли в SMS — это не очень-то безопасно, а иногда даже и очень небезопасно. Поэтому есть смысл озаботиться поиском альтернативных вариантов двухэтапной аутентификации, о чем мы сегодня и поговорим.
Одноразовые коды в файле или на бумажке
Работает это очень просто: по запросу сервис генерирует и показывает на экране десяток одноразовых кодов, которые в дальнейшем могут быть использованы для подтверждения входа в него. Дальше вы просто распечатываете или переписываете эти коды на бумагу и кладете в сейф. Или, что еще проще, сохраняете в зашифрованных записях в менеджере паролей.
В общем, не так важно, будете ли вы хранить эти коды на теплой ламповой бумаге или в бездушном цифровом виде — важно сохранить их так, чтобы они а) не потерялись и б) не могли быть украдены.
Приложения для двухфакторной аутентификации
У единожды сгенерированного набора одноразовых кодов есть один недостаток: рано или поздно он закончится, и вполне может так получиться, что вы останетесь без кода в самый неподходящий момент. Поэтому есть способ лучше: можно генерировать одноразовые коды на лету с помощью небольшого и, как правило, очень простого приложения — аутентификатора.
Как работают приложения-аутентификаторы
Работают приложения для двухфакторной аутентификации очень просто. Вот что придется сделать:
- устанавливаете на смартфон приложение для двухфакторной аутентификации;
- заходите в настройки безопасности сервиса, который среди опций для двухфакторной аутентификации предлагает использовать такие приложения;
- выбираете двухфакторную аутентификацию с помощью приложения;
- сервис покажет вам QR-код, который можно отсканировать прямо в 2FA-приложении;
- сканируете код приложением — и оно начинает каждые 30 секунд создавать новый одноразовый код.
Коды создаются на основе ключа, который известен только вам и серверу, а также текущего времени, округленного до 30 секунд. Поскольку обе составляющие одинаковы и у вас, и у сервиса, коды генерируются синхронно. Этот алгоритм называется OATH TOTP (Time-based One-time Password), и в подавляющем большинстве случаев используется именно он.
Также существует альтернатива — алгоритм OATH HOTP (HMAC-based One-time Password). В нем вместо текущего времени используется счетчик, увеличивающийся на 1 при каждом новом созданном коде. Но этот алгоритм редко встречается в реальности, поскольку при его использовании гораздо сложнее обеспечить синхронное создание кодов на стороне сервиса и приложения. Проще говоря, есть немалый риск, что в один не очень прекрасный момент счетчик собьется и ваш одноразовый пароль не сработает.
Так что можно считать OATH TOTP де-факто индустриальным стандартом (хотя формально это даже не стандарт, на чем создатели этого алгоритма очень настаивают в его описании).
Совместимость приложений для двухфакторной аутентификации и сервисов
Подавляющее большинство приложений для двухфакторной аутентификации работает по одному и тому же алгоритму, так что для всех сервисов, которые поддерживают аутентификаторы, можно использовать любое из них — какое вам больше нравится.
Как и в любом добротном правиле, в этом тоже есть определенное количество исключений. Некоторые сервисы по каким-то причинам, ведомым только им одним, предпочитают делать свои собственные приложения для двухфакторной аутентификации, которые работают только с ними. Более того, сами сервисы не работают ни с какими другими приложениями, кроме своих собственных.
Особенно это распространено среди крупных издателей компьютерных игр — например, существуют несовместимые со сторонними сервисами приложения Blizzard Authenticator, Steam Mobile с встроенным аутентификатором Steam Guard, Wargaming Auth и так далее. Для этих сервисов придется ставить именно эти приложения.
Также по этому странному пути пошла Adobe, разработавшая Adobe Authenticator, который работает только с аккаунтами AdobeID. Но при этом вы можете использовать для защиты AdobeID и другие аутентификаторы, так что вообще непонятно, ради чего было городить огород.
Поэтому просто выбирайте приложение-аутентификатор, которое вам больше нравится по набору дополнительных функций — оно будет работать с большинством сервисов, которые вообще поддерживают 2FA-приложения.
Лучшие приложения для двухфакторной аутентификации
Несмотря на то что базовая функция у всех этих приложений одна и та же — создание одноразовых кодов по одному и тому же алгоритму, некоторые аутентификаторы обладают дополнительными функциями или особенностями интерфейса, которые могут показаться вам удобными. Перечислим несколько самых интересных вариантов.
1. Google Authenticator
Поддерживаемые платформы: Android, iOS
Как отмечают буквально все публикации, Google Authenticator — это самое простое в использовании из всех существующих приложений для двухфакторной аутентификации. У него даже настроек нет. Все, что можно сделать, — это добавить новый токен (так называется генератор кодов для отдельного аккаунта) или удалить один из имеющихся. А чтобы скопировать код в буфер обмена, достаточно коснуться его пальцем на сенсорном экране смартфона или планшета. Все!
Однако у такой простоты есть и недостаток: если вам что-то не нравится в интерфейсе или хочется от аутентификатора чего-то большего — придется устанавливать другое приложение.
+ Очень просто использовать.
2. Duo Mobile
Поддерживаемые платформы: Android, iOS
Duo Mobile также крайне прост в использовании, минималистичен и лишен дополнительных настроек. По сравнению с Google Authenticator у него есть одно преимущество: по умолчанию Duo Mobile скрывает коды — чтобы увидеть код, надо нажать на конкретный токен. Если вы, как и я, испытываете дискомфорт каждый раз, когда открываете аутентификатор и показываете всем окружающим кучу кодов от всех своих аккаунтов сразу, то вам эта особенность Duo Mobile наверняка понравится.
+ По умолчанию скрывает коды.
3. Microsoft Authenticator
Поддерживаемые платформы: Android, iOS
В Microsoft тоже не стали усложнять и сделали свой аутентификатор на вид очень минималистичным. Но при этом Microsoft Authenticator заметно функциональнее, чем Google Authenticator. Во-первых, хоть по умолчанию все коды показываются, но каждый из токенов можно отдельно настроить так, чтобы при запуске приложения код был скрыт.
Во-вторых, Microsoft Authenticator упрощает вход в аккаунты Microsoft. В этом случае после ввода пароля достаточно будет нажать в приложении кнопку подтверждения входа — и все, можно даже не вводить одноразовый код.
+ Можно настроить, чтобы коды скрывались.
+ Дополнительные возможности для входа в аккаунты Microsoft.
4. FreeOTP
Поддерживаемые платформы: Android, iOS
Есть четыре причины, по которым вам может понравиться этот аутентификатор, разработанный Red Hat. Во-первых, это ваш выбор, если вы любите программное обеспечение с открытым кодом. Во-вторых, это самое маленькое приложение из всех рассматриваемых — версия для iOS занимает всего 750 Кбайт. Для сравнения: минималистичный Google Authenticator занимает почти 14 Мбайт, а приложение Authy, о котором мы поговорим ниже, — аж 44 Мбайта.
В-третьих, по умолчанию приложение скрывает коды и показывает их только после касания. Наконец, в-четвертых, FreeOTP позволяет максимально гибко конфигурировать токены вручную, если вам это зачем-нибудь нужно. Разумеется, обычный способ создания токена с помощью сканирования QR-кода тоже поддерживается.
+ По умолчанию скрывает коды.
+ Приложение занимает всего 700 Кбайт.
+ Открытый код.
+ Максимум настроек при создании токена вручную.
5. Authy
Поддерживаемые платформы: Android, iOS, Windows, macOS, Chrome
Самое навороченное из приложений для двухфакторной аутентификации, основным достоинством которого является то, что все токены хранятся в облаке. Это позволяет получить доступ к токенам с любого из ваших устройств. Заодно это упрощает переезд на новые устройства — не придется заново активировать 2FA в каждом сервисе, можно продолжить пользоваться существующими токенами.
В облаке токены зашифрованы ключом, который создается на основе заданного пользователем пароля, — то есть данные хранятся безопасно, и украсть их будет нелегко. Также можно установить ПИН-код на вход в приложение — или защитить его отпечатком пальца, если ваш смартфон оснащен соответствующим сканером.
Основной недостаток Authy состоит в том, что приложение с ходу требует завести аккаунт, привязанный к вашему телефонному номеру, — без этого просто не получится начать с ним работать.
− Требуется зарегистрироваться в Authy, используя номер телефона, — без этого приложение не работает.
Поддерживаемые платформы: Android, iOS
− При большом количестве токенов не очень удобно искать нужный.
Если приложение, генерирующее одноразовые коды, кажется вам слишком эфемерным способом защитить свои аккаунты, и хочется чего-то более постоянного, надежного и материального — буквально запереть аккаунт на ключ и положить его в карман, — то у меня есть для вас хорошая новость: такой вариант также существует. Это аппаратные токены стандарта U2F (Universal 2nd Factor), созданного FIDO Alliance.
Как работают токены FIDO U2F
Аппаратные U2F-токены очень полюбились специалистам по безопасности — в первую очередь потому, что с точки зрения пользователя они работают очень просто. Для начала работы достаточно подключить U2F-токен к вашему устройству и зарегистрировать его в совместимом сервисе, причем делается это буквально в пару кликов.
Вставьте ключ и нажмите кнопку — и это действительно все
Приватный ключ используется для того, чтобы зашифровать подтверждение входа, которое передается на сервер и может быть расшифровано с помощью публичного ключа. Если кто-то от вашего имени попытается передать подтверждение входа, зашифрованное неправильным приватным ключом, то при расшифровке с помощью известного сервису публичного ключа вместо подтверждения получится бессмыслица, и сервис не пустит его в аккаунт.
Какими бывают U2F-устройства
YubiKey — вероятно, самые популярные U2F-токены
Например, Google недавно представила свой комплект аппаратных аутентификаторов Google Titan Security Keys. На самом деле это ключи производства Feitian Technologies (второй по популярности производитель U2F-токенов после Yubico), для которых в Google написали собственную прошивку.
NFC — необходим для использования со смартфонами и планшетами на Android.
Bluetooth — понадобится на тех мобильных устройствах, в которых нет NFC. К примеру, аутентификатор с Bluetooth все еще нужен владельцам iPhone: несмотря на то, что в iOS уже разрешили приложениям использовать NFC (до 2018 года это было позволено только Apple Pay), разработчики большинства совместимых с U2F приложений еще не воспользовались этой возможностью. У Bluetooth-аутентификаторов есть пара минусов: во-первых, их нужно заряжать, а во-вторых, их подключение занимает гораздо больше времени.
В базовых моделях U2F-токенов обычно есть только поддержка собственно U2F — такой ключ обойдется в $10–20. Есть устройства подороже ($20–50), которые заодно умеют работать в качестве смарт-карты, генерировать одноразовые пароли (в том числе OATH TOTP и HOTP), генерировать и хранить ключи PGP-шифрования, могут использоваться для входа в Windows, macOS и Linux и так далее.
Что же выбрать: SMS, приложение или YubiKey?
Так или иначе, главный совет — по возможности избегать использования одноразовых паролей в SMS. Правда, получится это не всегда: например, финансовые сервисы в силу своей консервативности продолжают использовать SMS и крайне редко позволяют пользоваться чем-либо еще.
Читайте также: