Двух-шаговые проверки при логине. А если потерялось? А если…?

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

Одним из первым, а может и самым первым, внедрил ее Google.

Основная идея в том, что вам нужно не только знать пароль к ученой записи, но и иметь еще что-то, например номер телефона или приложение, настроено специально для вашей учетной записи и только с ним можно залогиниться. Проще говоря: знать пароль и иметь устройство.

Очевидные плюсы – это невозможность перебором подобрать пароль удаленно. А также исключается возможность использовать ваш пароль, если вы к примеру вводили его в компьютерном клубе, а там установлен кей-логгер.

Хотя мне сразу было не очевидно, что к чему. Ну и основной вопрос был, а что если скажем потеряется телефон. Особенно интересно, если находишься где-то за границей и проблематично восстановить. Вопрос на свой вопрос я нашел, хотя и не скажу, что полностью удовлетворен.

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

По ходу ознакомления также возникли и другие соображения, которые я также опишу в этом посте. Замечу, я не ставлю задачей описать как использовать двух-шаговую авторизацию. А скорее описать неочевидные моменты в ее использовании. Хотя если вы не использовали ранее указанный механизм защиты, то ниже вы найдете полезные для себя ссылки, чтобы ознакомиться.

Двухэтапная аутентификация Google

Детально о двухэтапной аутентификации Google можно почитать на соответствующей  странице Двухэтапная аутентификация. Желательно это сделать до того, как вы продолжите читать этот пост далее.

После включения 2-х шаговой авторизации на странице Google – Account Setting – Security  можно указать свой номер телефона и на него будет приходить код подтверждения при попытке залогиниться. Мне это не сильно понравилось, поскольку не хочется привязываться к мобильной сети.

Поэтому я решил воспользоваться альтернативным вариантом – установить приложение Google Authenticator на свой мобильник. Ну а потом при включении двух шаговой авторизации сфотографировать QR-код, чтобы устройство стало уникальным и только с него можно было генерировать коды. Коды генерируются в зависимости от времени – мне это понравилось, не проблема синхронизировать часы. Не очень понравилось, что Google предлагает только одно устройство сконфигурировать для данной учетной записи. Хотя впринципе никто не мешает сфотографировать QR-код несколькими устройствами, но это уже отклонение от рекомендаций Гугла.
Если Google Authenticator по каким-то причинам не доступен, то можно опять же получить код подтверждения через SMS.

Вначале мне также показалось неудобным каждый раз вводить код при логине. Но есть возможность указать, что устройство зарегистрировано, т.е. ему можно доверять и оно является моим. И тогда при последующих входах в сервис код подтверждения вводить больше не нужно будет. В любой момент можно удалить зарегистрированные устройства из списка и оставить только одно – это на случай, если какое-то устройств, к примеру потеряется. Здесь мне не понятно, как образом Google запоминает зарегистрированные устройства и на сколько это безопасно.

Возвращаясь к вопросу, который у меня возник вначале. А что если устройство с Google Authenticator потерялось? Здесь есть 2 варианта:

1) Залогиниться на любое зарегистрированное устройство – на таких устройствах не нужно генерировать код. И уже установить Google Authenticator и сконфигурировать его.

2) Ввести код восстановления (backup codes). Такие коды можно сгенерировать и распечатать на страницы безопасности вашей учетной записи – это пятицифровые числа. И если вы не можете сгенерировать код подтверждения, то можете разово использовать 1 из 10 кодов восстановления.
А вот что мне не понятно, так это то, что Google советует хранить коды в легко-доступном месте, например в кошельке, или же так: “Храните их (коды восстановления) в надежном, но легко доступном для вас месте”. Т.е. легко-доступном и так, чтобы нельзя было потерять. Но ничего о том, что нужно их сделать не доступными для других, не сказано. Первое, что мне не понравилось, это то, что кошелек часто находится рядом с мобильным устройством. И если теряется устройство, то велика вероятность и потери кошелька. Вот и все…. Как по мне резерные коды лучше хранить где-то в облаке (не спрашивайте, где хранить коды восстановления для двух-шаговой авторизации самого облачного сервиса )) ). В этом случае они всегда доступны, причем только вам. Ну а если вдруг взломали ваш облачный сервис, то сами по себе коды без пароля особой пользы не принесут. Хотя конечно же стоит их обновить, если к ним получили доступ третьи лица.

Следующий интересный момент возникает, если приложение не умеет работать с двух-шаговой авторизацией. Например почтовый клиент. В этом случае есть возможность сгенерировать пароль, специфический для приложения, так называемые Application-Specific Passwords. Это Google так их называет, и можно подумать, что они специфичны для приложений. А по большому счету можно сгенерировать много паролей и использовать их на свое усмотрение. Хотя Google советует один пароль ввести один раз и нигде больше не сохранять.
Плюсы этого подхода следующие. Прежде всего это защита от социальной инженирии. Пароль сложный и его подобрать не так то и легко, поэтому простым перебором по словарю не получится. Также исключается вариант, что пароль написан где-то на бумажке и эту бумажку нашел злоумышленник – пароль вводится только раз и больше вы его не видите.  Google ограничил длину такого пароля 16 маленькими латинскими буквами, но мне не понятно, почему не указать букв 64, причем вперемежку с символами и цифрами.
Ну и видимо с помощью пароля приложения нельзя изменить основной пароль, что тоже более безопасно (хотя именно это я не пробовал делать, хотя мне и кажется логичным)
Application Specific пароли – это скорее исключение в случае Google, чем правило, поскольку у Google-а много сервисов, которые взаимодействуют с Third-Party-клиентами. В типичном сервисе этого нет необходимости делать.

Следует также отметить культурность Гугла при изменении параметров безопасности – каждый раз присылается письмо, видны даты использования, актуальность кодов востановления и т.д.

А что у Apple?

Двух-шаговая авторизация может использована для логина при использовании Apple ID, хотя возможность пока не доступна во всех странах, поэтому протестировать не удалось.

Apple очередной раз меня приятно удивила. В Google мне показалась не продуманным подход в случае, если потерялось устройство – похоже на кучу хаков. В частности, касательно хранения кодов восстановления.

Apple пошли дальше. Для разработки более элегантной системы они используют подход как для безопасного логина, так и на случай утери устройства, они используют подход: из трех нужно иметь минимум два элемента:

  1. Пароль. Обычный пароль, который используется при одношаговой авторизации.
  2. Устройства. В отличии от Гугла советуют делать авторизированными несколько устройств. А также номер телефона кого-то из близких, видимо подразумевая, что его не будут использовать для взлома. Хотя конечно не очень безопасно зависеть еще от кого-то. Но в целом удобно, если потерялся телефон, то можно получить код с помощью телефона кого-то из близких. Код генерируется при помощи стандартного приложения Find my iPhone.
  3. Ключ восстановления (Recovery Key). Это аналог backup codes. Но в Apple не возникает вопрос открытого хранения Recovery Key – они явно советуют его “прятать” от лишних глаз. И состоит он не из 5 цифр, а из 14.

При доступе к двум элементам третий можно восстановить. При утере доступа к двум элементам, восстановить больше ничего нельзя.

Понравился у Apple момент, связанный с тем, что если менялся пароль, то нельзя включить двух-факторную авторизацию, только через 30 дней. Это на случай, что сразу нельзя много всего менять, что обычно может потребоваться только злоумышленнику, например поменять пароль, чтобы ограничить доступ прежнему владельцу, а потом сразу вкючить двух-шаговую авторизацию. Поскольку при изменении пароля владелец также получит оповещение на электронную почту, то будет достаточно времени, чтобы адекватно отреагировать на ситуацию.

Login в Facebook

В Facebook процесс очень похож на тот, который в Google. В Web-клиенте называет опция Login Approvals. Но есть и отличия. Коды подтверждения можно получить как через sms, так и в самом мобильном приложении. Генерировать коды в приложении удобно, поскольку  ничего дополнительно не нужно устанавливать. Т.е. чтобы залогиниться на новом устройстве, вам нужно иметь доступ к устройсту, где вы залогинились ранее.

Насторожило меня то, что коды подтверждения на разных устройствах генерировались разные. Т.е. я ложил рядом 2 устройства, которые показывают в один момент времени разные коды, но оба кода подходят. Как-то странно…

Тестирование также осложнилось тем, что трудно было сделать так, чтобы Facebook требовал код, не смотря на то, что при первом логине и вводе кода я указывал, чтобы  устройство не считалось надежным.
Это немного настораживает. Это может привести к тому, что если вы использовали чужой компьютер и на нем установлен троян, который запоминает нажатия клавиш, то позже злоумышленник может зайти без кода подтвеждения. Похоже, это какой-то глюк.

Коды подтверждений также, как и в Google можно получить, если нет доступа к какому-то своему устройству, где вы уже залогинены.

Детально можно почитать на странице Introducing Login Approvals , хотя качество документации ниже, чем у Apple или Google.

В целом в Facebook подход работает, но настораживают некоторый моменты, которые похожи на глюки. Также благодаря тому, что Facebook сам разрабатывает свои клиенты, нет необходимости использовать пароли, подобные Application Password в Google.

Но для интергации с Apple-устройствами все таки нужны пароли, аналогичные Application Password в Google. И здесь какие-то странности начинаются.
При попытки залогиниться с одного устройства, получил сообщение, что прийдет пароль из 6 цифр и его нужно будет использовать для логина – сработало. Правда остается открытым вопрос, насколько надежна передача пароля в SMS, учитывая также то, что смс содержит информацию о том, что это за числа: Use 123456 as your password for iOS. Не понятно также какой срок действия пароля, подходит ли он к другим устройствам – кустарно как-то сделано.
Но, даже не смотря на недопонимание, при попытке включить интеграцию на другом устройстве я удивился еще больше – прошла обычная одношаговая авторизация – я просто ввел почту, свои пароль и все – никаких запросов больше не было.

 

Резюме

Двух-шаговая авторизация действительно улучшает защиту. Она исключает возможность перебирать пароли удаленно. А также использовать украденный пароль, если вам пришлось его ввести на зараженном устройстве. Хотя установка двух-шаговой авторизации и требует некоторых усилий. Но регистрация устройств, которым вы доверяете, убирают почти все неудобство ввода кодов.

Но в целом не удобно, что процедуры для разных сервисов могут отличаться. Может быть сложно вспомнить, что к чему. Поэтому как компромисс можно использовать двухфакторную авторизацию для наиболее важных сервисов, например почты. Ведь часто именно почта используется для отсылки вам пароля, если вы его забыли на каком-то другом сервисе. Поскольку сейчас также часто есть возможность использовать свою учетную запись социального сервиса для логина на разные форумы, блоги и т.д., то есть смысл эту учетную запись также получше защитить в связи с ее широким использованием.

При подключении двух-шаговой авторизации сразу следует продумать о том, как вы будете восстанавливать доступ к  учетной записи при потере устройства, на котором вы генерируются коды. Это нужно сделать заранее. При наступлении инцидента может быть уже поздно.

Слабым местом в двух-шаговой аутентификации являются устройства, с помощью котороых генерируются коды подтверждения. Поэтому их желательно защищать паролем. И при утере желательно побыстрее обновить процедуру генерации кодов подтверждения, чтобы с помощью утерянного устройства больше нельзя было генерировать эти коды.
А также следует убрать предварительный просмотр смс на заблокированном телефоне, как это сделать для iPhone, можно прочитать в статье How can I turn off the home screen preview of SMS/text messages?

В целом же после включение двух-шаговой авторизации чувствую себя более комфортно 🙂

Ссылки по теме

  1. Michiel Appelman, Yannick Scheelen. Analysis of Google’s 2-step Verification. Статья об анализе двух-шаговой аутентификации. … в целом статья мне бестолковой показалась. Но если есть желание проникнуться дополнительными исследованиями, то можно прочитать. Для скачивания нужно зарегистрироваться на сервисе. Там есть тестовый период и статью можно скачать бесплатно.
  2. Известные сервисы, поддерживающие двух-шаговую авторизацию.
  3. Authy . Приложение для генерации кодов подтверждения для логина других приложений. Поддерживает разные платформы. Видимо может служить альтернативой Google Authenticator при работе с Google Account. Но я его не пробовал использовать, потому что не так-то много пока у меня сервисов с двух-шаговой авторизацией. Да и процессы двух-шаговой аутентификации немного отличаются в разных приложениях, поэтому пока не решил использовать.  Но в будущем приложение может оказаться очень даже полезным.
Share

2 thoughts on “Двух-шаговые проверки при логине. А если потерялось? А если…?

  1. facebook.com Mykola Denysiuk

    Привет, Сергей!

    Сорри, многабукаф – прочитал только вывод.
    Для того, чтобы исключить возможность удаленно перебирать пароли, требуется всего лишь хэшировать их достаточно сложной хэш-функцией. Чтобы один логин занимал 0.1 – 0.5 секунды, например. В таком случае перебирать пароли (даже на украденном дампе базы данных учетных записей) придется как минимум несколько десятков лет. Такое никому не будет интересно.
    Для удаленного логина – еще проще, достаточно вставить ту же небольшую задержку перед ответом с проверкой пары логин/пароль.

    Информация для размышления: меня очень забавляют сервисы, присылающие пароли в СМС, которые видно во всплывающей подсказке на заблокированном телефоне. Получается, злоумышленнику достаточно подсмотреть на телефон (даже если он защищен пин-кодом) для того, чтобы увидеть пароль из смс.

    P.S. Еще предлагаю тебе написать про Microsoft, Dropbox и Twitter, для полноты картины, так сказать 🙂

    Reply
    1. sergtk Post author

      > Для того, чтобы исключить возможность удаленно перебирать пароли, требуется всего лишь хэшировать их достаточно сложной хэш-функцией.

      Злоумышленник тоже может хешировать пароли такой же хеш-функцией. Хотя с учетом “соли” хеш-фкнкция ему вряд-ли доступна, но тем не менее. Я поразумевал, что перебор паролей опасен прежде всего для коротких паролей и паролей, состоящих из слов, которые можно перебрать по словарю.

      > Чтобы один логин занимал 0.1 – 0.5 секунды, например. В таком случае перебирать пароли (даже на украденном дампе базы данных учетных записей) придется как минимум несколько десятков лет.

      Конечно. Я думаю, обычно “плохие” пароли и ломают. А также ломают из-за проблем безопасности самих сервисов, но здесь “хороший” пароль уже не поможет.

      > Информация для размышления: меня очень забавляют сервисы, присылающие пароли в СМС, которые видно во всплывающей подсказке на заблокированном телефоне. П

      Отлично подмечено. Добавил ссылку в пост, как убрать preview смс на iPhone-е.

      > P.S. Еще предлагаю тебе написать про Microsoft, Dropbox и Twitter, для полноты картины, так сказать

      Когда начинал разбираться, то не думал, что на столько разная двух-шаговая авторизация в разных сервисах. Как минимум хотел еще Authy опробовать. Но тесты заняли много времени, особенно непонятно с ФБ. Поэтому ни Authy не опробовал, ни к другим приложениям не дошел.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *