company_banner

Двухфакторная аутентификация, которой удобно пользоваться

    Редкий пост в блоге Яндекса, а особенно касающийся безопасности, обходился без упоминания двухфакторной аутентификации. Мы долго думали, как правильно усилить защиту пользовательских аккаунтов, да еще так, чтобы этим мог пользоваться без всех тех неудобств, которые включают в себя самые распространённые ныне реализации. А они, увы, неудобны. По некоторым данным, на многих крупных сайтах доля пользователей, включивших дополнительные средства аутентификации, не превышает 0,1%.

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

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



    После включения двухфакторной аутентификации в Паспорте вам надо будет установить приложение Яндекс.Ключ в App Store или Google Play. В форме авторизации на главной странице Яндекса, в Почте и Паспорте появились QR-коды. Для входа в учётную запись необходимо считать QR-код через приложение — и всё. Если считать QR-код не получается, например не работает камера смартфона или нет доступа к интернету, приложение создаст одноразовый пароль, который будет действовать всего 30 секунд.

    Расскажу о том, почему мы решили не использовать такие «стандартные» механизмы, как RFC 6238 или RFC 4226. Как работают распространенные схемы двухфакторной аутентификации? Они двухэтапные. Первый этап ─ обычная аутентификация логином и паролем. Если он прошел успешно, сайт проверяет, «нравится» ему эта пользовательская сессия или нет. И, если «не нравится», просит пользователя «доаутентифицироваться». Распространенных методов «доаутентификации» два: отсылка SMS на привязанный к аккаунту номер телефона и генерация второго пароля на смартфоне. В основном для генерации второго пароля используется TOTP по RFC 6238. Если пользователь ввел второй пароль верно, сессия считается полностью аутентифицированной, а если нет, то сессия теряет и «предварительную» аутентификацию.

    Оба способа ─ отправка SMS и генерация пароля ─ доказательства обладания телефоном и потому являются фактором наличия. Пароль, вводимый на первом этапе, ─ фактор знания. Поэтому такая схема аутентификации ─ не только двухэтапная, но и двухфакторная.

    Что показалось нам проблемным в этой схеме?


    Начнем с того, что компьютер среднестатистического пользователя не всегда можно назвать образцом защищенности: тут и выключение обновлений Windows, и пиратская копия антивируса без современных сигнатур, и ПО сомнительного происхождения ─ все это не повышает уровень защиты. По нашей оценке, компрометация компьютера пользователя ─ самый массовый способ «угона» учетных записей (и недавно тому было еще одно подтверждение), от нее в первую очередь и хочется защититься. В случае двухэтапной аутентификации, если считать, что компьютер пользователя скомпрометирован, ввод пароля на нем компрометирует сам пароль, являющийся первым фактором. Значит, злоумышленнику необходимо лишь подобрать второй фактор. В случае распространенных реализаций RFC 6238 второй фактор ─ это 6 десятичных цифр (а максимум, предусмотренный спецификацией, ─ 8 цифр). Согласно калькулятору bruteforce для OTP, за три дня атакующий в состоянии подобрать второй фактор, если ему каким-либо образом стал известен первый. Нет ясности, что сервис может противопоставить этой атаке, не нарушая нормальную работу пользователя. Единственный возможный proof of work ─ капча, что, на наш взгляд, является последним средством.

    Вторая проблема ─ непрозрачность суждения сервиса о качестве пользовательской сессии и принятия решения о необходимости «доаутентификации». Хуже того, сервис не заинтересован в том, что бы сделать этот процесс прозрачным, ─ ведь тут фактически работает security by obscurity. Если злоумышленник знает, на основании чего сервис принимает решение о легитимности сессии, он может попытаться подделать эти данные. Из общих соображений можно заключить, что суждение делается на основе истории аутентификаций пользователя с учетом IP-адреса (и производных от него номера автономной системы, идентифицирующей провайдера, и местоположения на основе геобазы) и данных браузера, например заголовка User Agent и набора cookies, flash lso и html local storage. Это означает, что если злоумышленник контролирует компьютер пользователя, то он имеет возможность не только украсть все необходимые данные, но и воспользоваться IP-адресом жертвы. Более того, если решение принимается на основе ASN, то любая аутентификация из публичного Wi-Fi в кофейне может привести к «отравлению» с точки зрения безопасности (и обелению с точки зрения сервиса) провайдера этой кофейни и, например, обелению всех кофеен в городе. Мы рассказывали о работе системы обнаружения аномалий, и ее можно было бы применить, но времени между первым и вторым этапом аутентификации может оказаться недостаточно для уверенного суждения об аномалии. Кроме того, этот же аргумент разрушает идею «доверенных» компьютеров: злоумышленник может украсть любую информацию, влияющую на суждение о доверенности.

    Наконец, двухэтапная аутентификация попросту неудобна: наши usability-исследования показывают, что ничто так не раздражает пользователей, как промежуточный экран, дополнительные нажатия на кнопки и прочие «неважные», с его точки зрения, действия.
    Исходя из этого, мы решили, что аутентификация должна быть одноэтапной и пространство паролей должно быть намного больше, чем возможно сделать в рамках «чистого» RFC 6238.
    При этом нам хотелось по возможности сохранить двухфакторность аутентификации.

    Многофакторность в аутентификации определяется отнесением элементов аутентификации (собственно, они и называются факторами) к одной из трех категорий:
    1. Факторы знания (это традиционные пароли, пин-коды и все, что на них похоже);
    2. Факторы владения (в используемых OTP-схемах, как правило, это смартфон, но может быть и аппаратный токен);
    3. Биометрические факторы (отпечаток пальца ─ самый распространенный сейчас, хотя кто-то вспомнит эпизод с героем Уэсли Снайпса в фильме Demolition Man).

    Разработка нашей системы


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

    Широко распространена такая форма одноэтапной аутентификации: пользователь помнит пин-код (первый фактор), имеет на руках аппаратный или программный (в смартфоне) токен, генерирующий OTP (второй фактор). В поле ввода пароля он вводит пин-код и текущее значение OTP.



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

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

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

    Итак, у нас есть программа для смартфона, куда пользователь вводит свою часть секрета, та смешивается с хранимой частью, результат используется в качестве ключа HMAC, которым подписывается текущее время, округленное до 30 секунд. Выход HMAC приводится к читаемому виду, и вуаля ─ вот и одноразовый пароль!



    Как уже было сказано, RFC 4226 предполагает усечение результата работы HMAC до максимум 8 десятичных цифр. Мы решили, что пароль такого размера непригоден для одноэтапной аутентификации и должен быть увеличен. При этом нам хотелось сохранить простоту использования (ведь, напомним, хочется сделать такую систему, которой будут пользоваться обычные люди, а не только security-гики), так что в качестве компромисса в текущей версии системы мы выбрали усечение до 8 символов латинского алфавита. Кажется, что 26^8 паролей, действующих в течение 30 секунд, вполне приемлемо, но если security margin нас не будет устраивать (или на Хабре появятся ценные советы, как улучшить эту схему), расширим, например, до 10 символов.

    Подробнее о стойкости таких паролей


    В самом деле, для латинских букв без учета регистра число вариантов на один знак равно 26, для больших и малых латинских букв плюс цифры, число вариантов равно 26+26+10=62. Тогда log62(2610) ≈ 7,9 то есть пароль из 10 случайных малых латинских букв почти такой же стойкий, как пароль из 8 случайных больших и малых латинских букв или цифр. Этого точно хватит на 30 секунд. Если говорить о 8-символьном пароле из латинских букв, то его стойкость log62(268) ≈ 6,3, то есть немного больше 6-символьного пароля из больших, малых букв и цифр. Мы считаем, что это все еще приемлемо для окна в 30 секунд.

    Магия, беспарольность, приложения и дальнейшие шаги


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



    Поэтому мы начали работы над «магическим логином». С таким способом аутентификации пользователь запускает приложение на смартфоне, вводит в него свой пин-код и сканирует QR-код на экране своего компьютера. Если пин-код введен правильно, страница в браузере перезагружается и пользователь оказывается аутентифицирован. Магия!

    Как это устроено?


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

    Стало лучше, но и тут мы решили не останавливаться. Начиная с iPhone 5S в телефонах и планшетах Apple появился сканер отпечатков пальцев TouchID, а в iOS версии 8 работа с ним доступна и сторонним приложениям. На деле приложение не получает доступ к отпечатку пальца, но если отпечаток верен, то приложению становится доступен дополнительный раздел Keychain. Этим мы и воспользовались. В защищенную TouchID запись Keychain помещается вторая часть секрета, та, которую в предыдущем сценарии пользователь вводил с клавиатуры. При разблокировке Keychain две части секрета смешиваются, и дальше процесс работает так, как описано выше.

    Зато пользователю стало невероятно удобно: он открывает приложение, прикладывает палец, сканирует QR-код на экране и оказывается аутентифицированным в браузере на компьютере! Так мы заменили фактор знания на биометрический и, с точки зрения пользователя, совсем отказались от паролей. Мы уверены, что обычным людям такая схема покажется куда более удобной, чем ручной ввод двух паролей.

    Можно подискутировать, насколько формально двухфакторной является такая аутентификация, но на деле для успешного ее прохождения все еще необходимо иметь телефон и обладать правильным отпечатком пальца, так что мы считаем, что нам вполне удалось отказаться от фактора знания, заменив его биометрией. Мы понимаем, что полагаемся на безопасность ARM TrustZone, лежащей в основе iOS Secure Enclave, и считаем, что на настоящий момент эту подсистему можно считать доверенной в рамках нашей модели угроз. Разумеется, нам известны проблемы биометрической аутентификации: отпечаток пальца ─ не пароль и заменить его в случае компрометации нельзя. Но, с другой стороны, всем известно, что безопасность обратно пропорциональна удобству, и пользователь сам вправе выбрать приемлемое для него соотношение одного и другого.

    Напомню, что пока это бета. Сейчас при включении двухфакторной аутентификации мы временно выключаем синхронизацию паролей в Яндекс.Браузере. Связано это с тем, как устроено шифрование базы паролей. Мы уже придумываем удобный способ аутентификации Браузера в случае 2FA. Вся остальная функциональность Яндекса работает в прежнем режиме.

    Вот что у нас получилось. Кажется, вышло неплохо, но судить вам. Мы будем рады услышать отзывы и рекомендации, а сами продолжим работу над улучшением безопасности наших сервисов: теперь вместе с CSP, шифрованием транспорта почты и всего остального у нас появилась и двухфакторная аутентификация. Не забывайте, что сервисы аутентификации и приложения генерации OTP относятся к критичным и поэтому за обнаруженные в них ошибки в рамках программы Bug Bounty выплачивается двойная премия.
    Метки:
    Яндекс 639,23
    Как мы делаем Яндекс
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 297
    • +10
      Наконец таки! Плохо то, что я не смогу воспользоваться данной опцией имея старенькую нокию и свежий кнопочный филипс. Не люблю я сенсор… Пользуюсь телефоном только для звонков.
      • –6
        Всё это здорово, конечно, с авторизацией, а вот у меня вопрос к компании Яндекс:
        Хочу удалить свой очень старый аккаунт Яндекс (Почта, Деньги), которым не пользуюсь. Для удаления нужно ввести ответ на секретный вопрос, но у меня он не подходит (хотя и был записан в файле). Бог с ним. Написал в техподдержку, на что мне ответили, что в Яндекс нужно прислать скан паспорта(!) При регистрации (в те далёкие времена) от меня никакого скана паспорта (да и паспортных данных) не просили. Не хочу я вам свой паспорт светить.
        • +6
          Если к Вашему аккаунту не был привязан номер телефона и Вы сами не смогли никаким образом вспомнить какие-то автоматические средства восстановления доступа к аккаунту, то служба поддержки, как человеческий фактор, должна быть на 100% уверена, что даёт этот доступ и секретные данные не постороннему человеку, а истинному владельцу. Даже тот факт, что Вы на данный момент находитесь в ящике, не говорит, что Вы и правда владелец ящика.
          На данный момент одним из важных критериев идентификации является сравнение данных, которые Вы указывали при регистрации (ФИО, дата рождения и т.п.) с паспортом.
          Разумеется, эти данные сохраняются только в Яндексе, и не используются ни для каких целей, кроме как для восстановления доступа.
          • +5
            Так просто продолжайте им не пользоваться и всё.
            • 0
              Думаю уже много тысяч человек выслали свой паспорт Яндексу и еще много куда… Какую угрозу для себя Вы видите в скане паспорта? И какова вероятность этой угрозы? А можете оценить вероятный урон в деньгах?
          • +5
            Для WP планируется приложение?
            • +6
              IMHO, вопрос надо ставить не «планируется или нет», а «когда выйдет?».
              • 0
                Мы постараемся поддержать Windows Phone в будущем, но пока не можем назвать какие-либо сроки реализации. Сообщим об этой новости либо рассылкой, либо в одном из официальных Twitter-аккаунтов Яндекса.
                • 0
                  Привет. Как дела с приложением?
                  • 0
                    Может тогда включите через «проверка подлинности(microsoft)»? Все службы win phone с ней хорошо работают на двухфакторной))
              • +26
                Поясните, как выглядит брут-форс атака на TOTP? Если код меняется в течение каждых 60 секунд, и секрет (в основе кода) не скомпрометирован, то достаточно ограничить число попыток ввода.

                Алгоритм простой: человек ошибся с вводом кода, всё, надо ждать следующего. Натуральным образом (при ttl 30с) это даёт всего 2880 попыток в сутки. А дальше простой алгоритм, который увеличивает задержку после каждой следующей попытки. Очевидно, что человек не будет пробовать больше пары тысяч раз ни при каких обстоятельствах (тем паче, код надо не «вспоминать», а «набрать»), то есть увеличение задержки можно делать после пятой-шестой попытки.

                То, что не следуете RFC — плохо.
                • 0
                  Алгоритм простой: человек ошибся с вводом кода, всё, надо ждать следующего. Натуральным образом (при ttl 30с) это даёт всего 2880 попыток в сутки. А дальше простой алгоритм, который увеличивает задержку после каждой следующей попытки.
                  Вы учитываете, что злоумышленник может открыть одновременно много сессий?
                  То, что не следуете RFC — плохо.
                  Кажется, я объяснил логику, почему существующие RFC нас не удовлетворяют. Однако, если все сойдется хорошо, мы опубликуем нашу спецификацию в качестве RFC, когда она устаканится.
                  • +13
                    Вы учитываете, что злоумышленник может открыть одновременно много сессий?
                    мне кажется много сессий особенно для 1 пользователя это первое за что должна банить система входа
                    • +3
                      мне кажется много сессий к 1 пользователю это первое за что должна банить система входа
                      тогда получится элементарный DoS любого пользователя.
                      • +9
                        Поэтому сначала спрашивают логин и пароль, а потом уже код из приложения.
                        • 0
                          То есть, вы предлагаете сделать глобальный лок по всей системе аутентификации, когда пользователь прошел первую стадию? С репликацией между датацентрами, таймаутом на случай, если пользователь браузер закрыл, защитой от падений датацентров и каналов между ними, вот этим всем?

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

                          Вы знаете, что она где-то реализована?
                          • –1
                            у вас есть событие pre-auth — пользователь успешно ввел логин и пароль. таких событий много может быть только если вы похерите сессии всех пользователей, вы можете сделать счетчик успешных авторизация для каждого пользователя например это будет 60 байт (час истории с максимумом в 255 входов в минуту), то есть если у вас в час авторизуются 1кк человек это около 100мб данных.
                            я не знаю одновременно ли все ДЦ могут обработать вход одного и того же пользователя, но эти данные по сути не шибко нуждаются в синхронизации, у вас же тысячи ДЦ?!
                            при каждом следующем pre-auth вы смотрите этот лог, и если вам не нравится кол-во повторов просто ставите лок на пользователя в базе
                            • +1
                              у вас есть событие pre-auth — пользователь успешно ввел логин и пароль. таких событий много может быть только если вы похерите сессии всех пользователей
                              Таких событий может быть много потому, что много пользователей аутентифицируется и не проходит второй фактор. Дело не в объеме. Я спорю с самим тезисом о том, что нужно лочить сессию пользователя, когда он прошел первую стадию. Для этого нужно иметь глобальный лок и реплицировать его между ДЦ. И у нас десяток ДЦ, а трафик пользователей вполне может между ними скакать.

                              Так что нет, эти данные не только нуждаются в синхронизации, они еще и нуждаются в быстрой и гарантированной доставке, без гонок (что делать, если «одновременно» в двух ДЦ случился первый этап аутентификации).

                              Я не говорю, что сделать двухстадийную аутентификацию в распределенной системе нельзя — можно, пример известен — я говорю, что есть способы, которые удобнее для пользователя и надежнее с точки зрения реализации.
                              • 0
                                я же описал способ блокировать именно перебор TOTP глобальный лок пользователя происходит только после срабатывания защиты, потому что живой пользователь в минуту больше 10-20 раз ни при каких обстоятельствах сделать не сможет. То есть если держать эти счетчики внутри одного ДЦ, сколько попыток будет 100-200? по моему этого мало для нормального перебора
                                • 0
                                  > Я спорю с самим тезисом о том, что нужно лочить сессию пользователя, когда он прошел первую стадию

                                  Ну можно не лочить сразу, а просто добавлять прогрессивную задержку ответа после ввода данных первой стадии.
                                  Плюс есть и другие способы борьбы с подобными DoS ботами, например honeypot form field.
                                  • 0
                                    honeypot form field — да, про это можно подумать.
                                    • +2
                                      так а чем вам это поможет, если бот разбирается что у вас 2х факторная авторизация, то он либо сам догадается до CSS ибо он ИИ, либо он просто под вас заточен
                                      • 0
                                        Я сказал, что «можно подумать». :) Надо сесть и подумать, есть ли польза, или нет.
                              • +10
                                Извините, может я что-то не понимаю, но куда проще считать количество попыток двухфакторной авторизации per-user. И её вполне можно хранить per-server, без репликации и т.д.

                                Алгоритм простейший: у сервера есть сессия (вероятнее всего, глобальная), а есть данные по второму фактору пользователя (локальный), который следит, когда была предыдущая попытка и с каким «коэфицентом замедления». Каждая новая попытка увеличивает замедление. Долгая пауза уменьшает.

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

                                Так что я пока что не понимаю, где тут затруднения или страшный брутфорс с которым не совладать.
                                • 0
                                  Пользователь ведь может одновременно много сессий иметь?
                                  • –3
                                    Остаётся ещё проблема лёгкого DoS.
                                    • +2
                                      для того чтобы сделать DoS пользователя нужно знать его логин пароль, я бы не сказал что это легко
                                      • 0
                                        Повторюсь еще раз про нашу модель угроз: компьютер пользователя — рассадник малвари. Пароли утекают массово оттуда. Телефон пользователя — не рассадник малвари, особенно, когда он не порутован. Телефон можно считать доверенным устройством, что позволяет обойтись без двухстадийности (она нам не нравится потому, что мы знаем, что промежуточные экраны снижают конверсию и потому, что второй фактор слишком короткий).
                                        я бы не сказал что это легко
                                        Я позволю себе не согласиться.
                                        • 0
                                          Промежуточные экраны снижают конверсию… когда?

                                          Тогда, когда они обязательные (яркий пример — платежные системы). Двухфакторная аутентификация пока что обязательная только у банков, больше нигде не видел, в остальных случаях только по желанию клиента. И если уж клиент такое желание изъявил, как это может понизить конверсию?
                                          • 0
                                            Однажды я 3 дня не мог зайти на github, неделю в twitter и день в google. Если бы эти сервисы не были для меня важны — я бы забил. Так что имхо 2-фактор может повлиять на конверсию
                                            • 0
                                              Серьезно думаю, что двухфакторную аутентификацию подключают именно только те, кому сервис действительно важен (т.е. те, кто боится урона от потери контроля за аккаунтом), причем по разным причинам (личные данные, деньги, какие-то активы и т.д.).

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

                                              P.S.: Мало того, подключают такой механизм обычно более-менее продвинутые пользователи, которые представляют, что делать в том случае, если сломался, потерялся, отформатировался, etc. смартфон. Поэтому даже в таком случае восстановить доступ — почти нет проблем.
                                    • +1
                                      И её вполне можно хранить per-server, без репликации и т.д.
                                      Я с этим, увы, не могу согласиться.

                                      В остальном — нигде нет страшного брутфорса, с которым не совладать. Пример есть, он работает. Есть традиционные proof-of-work, типа капчи, про них я написал. Я полагаю, что можно сделать лучше. Бета-версия — попытка это сделать. Если тут есть, что улучшить, я искренне буду рад предложениям.

                                      Возможно, я плохо услышал преимущества двухстадийности. Тогда поясните подробнее.
                                      • +1
                                        Почему per-server хранение плохо? Оно кратно (числу серверов) ослабляет устойчивость, но у вас усиление экспонентой от длины пароля и ослабление o(n) от числа серверов — чистый выигрыш в пользу пароля.
                                        • +1
                                          вас усиление экспонентой от длины пароля
                                          И еще раз повторюсь, что наша модель угроз предполагает скомпроментированный компьютер пользователя. Поэтому стойкость пароля для массовой атаки значения не имеет.
                                          • 0
                                            Кстати, я не понимаю, каким образом вы защищаетесь (и от чего?) Пароль в моём ответе = токен, который на втором этапе вводит пользователь. Добавьте один символ и получите следующую ступень по экспоненте.

                                            Если у злоумышленника браузер пользователя под контролем, то что ему мешает показать диалог логина ещё раз, а на самом деле использовать его для отключения двухфакторной авторизации или регистрации ещё одного устройства?
                                            • +1
                                              Добавьте один символ и получите следующую ступень по экспоненте.
                                              rfc4226 не разрешает иметь больше 8 цифр. Конечно, так бы и сделали, если бы могли. Больше того, подозреваю, многие бы так и сделали, если бы rfc это позволял.
                                              Если у злоумышленника браузер пользователя под контролем, то что ему мешает показать диалог логина ещё раз, а на самом деле использовать его для отключения двухфакторной авторизации или регистрации ещё одного устройства?
                                              CSP? БОльшая сложность, чем клавиатурный сниффер?
                                              • 0
                                                Откуда у вас CSP появился на бытовой машине? Или вы пользователю сертификат выписываете?

                                                К вопросу о «лимите попыток per user per server» — если у вас 8 символов, то если вы ограничите пользователя 30-40 попытками в сутки (это для кода-то с экрана!), то даже если у вас там тысяча серверов в сумме, то это всё равно нереалистичные сроки взлома. 8 символов — это 100 миллионов попыток. По 40 попыток на сервер ежедневно, при 1000 серверах (это если злоумышленник может равномерно размазать запросы, то есть worst case), это 2500/2 = 1200 дней перебора. Повторю, это worst case, если же пользователь по балансировке попадает на одни и те же сервера (допустим, 10), то время увеличивается до «криптографических» 120000 дней.

                                                То есть я пока не понял, что мешает иметь лимит per server per user с экспоненциальной задержкой на второй фактор.
                                                • 0
                                                  CSP.

                                                  Кстати, время действия кода можно сделать подольше (1 минута)
                                                  RFC6238 предполагает дефолтом время в 30 секунд и не каждая реализация умеет что-то, кроме этого.

                                                  К вопросу о «лимите попыток per user per server» — если у вас 8 символов, то если вы ограничите пользователя 30-40 попытками в сутки (это для кода-то с экрана!)
                                                  Я запутался, мы про что говорим — про TOTP из RFC6238 или про нашу реализацию? Если мы говорим про нашу реализацию, то вопрос формулируется — почему нам не нравится двухстадийная аутентификация, ответ на этот вопрос есть в посте. Если речь идет про RFC6238, то выбор ограничивается 6-8 цифрами при окне 30 секунд. Я считаю, что такой размер приемлем только для второго фактора и только в двухстадийном варианте. Двухстадийный вариант я считаю неприемлемым — см. п. 1.
                                                  • 0
                                                    А как насчет сделать в качестве компромисса два варианта входа? Основной — через вашу реализацию, для тех же, кому удобно единое хранилище одноразовых паролей или приложение на платформе, которая сейчас не подерживается вами (а вы уже обделили Android 2 и пока не поддерживаете WinPhone) — через RFC6236 в качества второй стадии после пароля.
                                                    В вашем случае вы упрощаете для массы пользователей, но пропускаете много тех, кто либо банально не может воспользоваться вашим способом из-за неподдерживаемой платформы, либо хочет использовать удобное ему единое хранилище. При этом многие из этих пользователей наверняка хотели бы использовать 2FA и в яндексе (особенно вторая группа), и наверняка спокойно относятся к двухстадийному варианту, т.к. он используется уже во многих местах.
                                                    • 0
                                                      Мы подумаем про это.
                        • +11
                          Ключевой вопрос, неужели нажать доп кнопку на компе сложнее чем разблокировать мобильное приложение и им открывать страницу?
                          По мне текущая схема еще более гиковская, чем обычный ввод дополнительного пароля.
                          • 0
                            Какую доп кнопку?
                            • 0
                              Ввести 2 пароль и нажать далее.
                              • 0
                                Какого пароля? Чтобы узнать второй пароль при двухфакторной авторизации — надо так же разблокировать телефон и открыть приложение.
                                • 0
                                  а точнее просто прочитать его в бегущей строке в заголовке в случае смс, либо запустить аппу и прочитать от туда.
                                  Ну а в остальном, такую авторизацию по QR на экране ввели WatsApp вроде на прошлой неделе, когда запустили свою web версию.
                                  Там авторизация из мобильного приложения путем считывания QR, под капотом скорее всего, что то аналогичное.
                          • +1
                            А я не осилил. Оно просит код из приложения, код в буквах, а ввести можно только цифры. Либо что-то не работает, либо не очень очевидно описали процедуру подключения приложения.
                            • 0
                              Пинкод состоит только из цифр. Пинкод вы придумываете сами на стадии включения двухфакторной аутентификации на странице oauth.yandex.ru/access. Затем этот пинкод нужно вводить только в приложении Яндекс.Ключ на телефоне, а приложение будет генерировать пароль, который нужно вводить при аутентификации на Яндексе.
                              На каком шаге Вы получаете требование ввести только цифровой код, хотя на руках у Вас буквенный?
                              • 0
                                Перейти на пароли из приложения -> Перейти к активации:
                                Отсканируйте этот QR — Ok
                                Приложение предлагает придумать PIN — Ok
                                Приложение отображает буквенный код — Принял к сведению.
                                Код из приложения: ввожу PIN — не принимает. Буквенный код ввести нельзя.
                                Платежный пароль верный.

                                Приехали…
                                • +1
                                  Похоже я сам дурак. Ломился в сервис одноразовых паролей. Забавно, что приложение приняло QR код, предназначавшийся для приложения яндек.денег, что весьма странно.
                                  • +12
                                    Вообще говоря, вы нашли огромную багу.
                                    • 0
                                      Тот факт, что сейчас приложения от Яндекса распознаёт какую-либо информацию с QR-кода Яндекс.Денег — и правда ошибка, мы её исправим. В дальнейшем же мы постараемся прийти к тому, чтобы наоборот «подружить» две наши системы, возможно, совместив в одну, или ещё как-то.
                              • 0
                                К Яндексу применима поговорка «лучше поздно, чем никогда», причем действительно Лучше.

                                При этом нам хотелось сохранить простоту использования (ведь, напомним, хочется сделать такую систему, которой будут пользоваться обычные люди, а не только security-гики), так что в качестве компромисса в текущей версии системы мы выбрали усечение до 8 символов латинского алфавита.

                                Вот бы где пригодились 3 слова
                                • +2
                                  Да, кстати, мило. Мы думали использовать diceware в Ключе. Как по-вашему, три английских слова для пароля лучше, чем 8 случайных букв?
                                  • +2
                                    Мне лично лучше, да, но большинству русскоязычных могут быть лучше русские слова — для вас ведь ничего не изменится.
                                    • +2
                                      Конечно. Можно даже одновременно поддержать слова из нескольких алфавитов, если аккуратно.

                                      Надо про это подумать.

                                      Спасибо.
                                • 0
                                  Не пускает по одноразовому паролю в почту (Android, Яндекс.Почта).
                                  Аккаунт на своем домене. Для ПДД двуфакторная авторизация точно работает? Включилась без проблем, а войти не получается.
                                  • 0
                                    Для доменных аккаунтов всё работает точно так же: нужно завести полный email в качестве логина в Ключе и включить 2FA в Паспорте. Проверьте, пожалуйста, что вводите правильный пин-код в Ключе, потому что пароль будет генерироваться даже в том случае, если пин неправильный.
                                  • +5
                                    Ну наконец-то! Только был ли смысл сразу изобретать велосипед, если есть уже проверенные и удобные способы?
                                    • +1
                                      Примерно треть статьи объясняет, почему нам не подошли «проверенные и удобные способы». Вкратце, потому, что они не очень удобны и недостаточно хороши для нашей модели угроз. RFC4226 написан 10 лет назад, под конкретную задачу. К сожалению, он нерасширяем. Если бы можно было жить в рамках стандарта, конечно же мы бы жили.
                                      • 0
                                        А если совсем коротко, то…
                                        … мы решили, что аутентификация должна быть одноэтапной и пространство паролей должно быть намного больше, чем возможно сделать в рамках «чистого» RFC 6238. При этом нам хотелось по возможности сохранить двухфакторность аутентификации
                                        … в телефонах и планшетах Apple появился сканер отпечатков пальцев TouchID [...] Этим мы и воспользовались…
                                        Так мы заменили фактор знания на биометрический и, с точки зрения пользователя, совсем отказались от паролей.

                                        1. Пароль и пин-код, вводимый с клавиатуры, превратился в часть ключа, хранимый в защищённой памяти смартфона.
                                        2. Хранимый секрет (тот же самый ключ в RFC 6238) никуда не делся и теперь также хранится в смартфоне.

                                        Фактически, вместо одноразовых паролей вы реализовали собственное решение, в котором вы исключили из процесса авторизации (в части генерации и передачи токена) ненадёжный с точки зрения защищённости компьютер пользователя.

                                        На первый взгляд, решение больше всего похоже на авторизацию по электронной подписи, когда на основе некого набора данных от сервера (QR-код с номером сессии) формируется ответ, который впоследствии проверяется. Тем не менее, речь идёт о подходе сроди OTP (HMAC, время, функция усечения).

                                        Кстати, если уж от пользователя не требуется особых усилий (приложить палец к кнопке) и вся магия происходит внутри смартфона, почему бы не навернуть настоящую электронную подпись и не избавиться от той же функции усечения, с которой возрастает вероятность нахождения коллизий одноразового пароля?
                                        • +2
                                          Да, так можно было бы сделать, но тогда бы существовало бы два путя аутентификации — через форму с усеченным паролем и OOB с подписью. Мы думали про это и решили, что безопасности это не прибавляет, поскольку остается shortcut. Тут сложность в балансе между удобством ввода одноразового пароля, когда не сработала магия с QR и стойкостью. А пароль нужно сохранить для того, что б пользователь мог аутентифицироваться, даже если в телефоне нет интернета.

                                          Я даже думал про использование Curve25519, где секретный ключ можно было б из пароля пользователя генерировать, но результат все равно слишком длинный для того, что б он мог нормально работать в случае fallback на ввод одноразового пароля в форму.

                                          Но если есть идеи, я буду рад услышать. На то это и бета-версия.
                                        • –1
                                          Статью не читал, сразу в комментарии. Пришел сказать что очень обидно, но так и не включил 2fa т.к. ставить одно приложение из-за одного только яндекса это как-то слишком жирно. Жаль что вы не сделали по нормальному. Поддержка стандартной 2fa авторизации сейчас есть в 1password, например. Вот это удобно и надежно. Смс как у мыла.ру и box – менее удобно, т.к. приходит с задержкой, но тоже лучше чем отдельное приложение из-за такой ерунды. Может все-таки дать людям опцию в виде смс? Я бы предпочел сам решать какое соотношение удобства к безопасности выбрать, а сейчас получается что никакое.
                                      • +2
                                        Windows Phone в пролёте… MS должно негодовать от такой дискриминации.
                                        • 0
                                          Мы постараемся поддержать WP в будущем. На старте было решено этого не делать, потому что интернет-аудитория среди пользователей WP крайне мала по сравнению с другими платформами.
                                          • 0
                                            интернет-аудитория среди пользователей WP составляет примерно 100%.
                                            Вот доля WP-аудитории среди пользователей интернета таки пока незначительна. :)
                                            • 0
                                              Она потому и незначительна, что для нее все делают послезавтра. В случае с Инстаграм — вообще никогда.
                                              • 0
                                                Это тоже правда. Но есть таки подозрение, что оно уже совсем скоро изменится. Уж не знаю к лучшему-ли оно, но подозрение есть.
                                          • +1
                                            Непонятно, к чему рассуждения про то, что 8 латинских символов достаточно на 30 секунд. Время ведь не важно, важна лишь длина пароля и есть ли защита от брут-форса.
                                            Например, если каждые 30 секунд генерируется новый пароль, а злоумышленник за эти 30 секунд успевает проверить все пароли начинающиеся на «a», то в среднем один раз из 28 30-секундных интервалов будет создан пароль, начинающийся на «a» и в этот раз он будет успешно подобран.
                                            • +1
                                              Важно еще и пространство, на котором работает защита от брутфорса. Одно дело, когда оно 10^8, другое — когда 26^8.
                                            • +7
                                              По-моему стало хуже: вот у меня был 20-значный пароль, а теперь у меня 4-значный пинкод и телефон?
                                              То есть злоумышленнику нет больше необходимости подбирать мой пароль? Просто пинкод и одолжить телефон?

                                              Сделайте, пожалуйста, как у всех, я не хочу иметь одно приложение для всех 2FA и для вас отдельное.
                                              • +6
                                                Я твердо убежден, что кейс заражения компьютера трояном, собирающим пароли — массовый. А кейс злоумышленника, «одолжившего телефон» — нет. Просто потому, что заразить 100000 компьютеров — дело нескольких дней, при хорошем стечении обстоятельств, а одолжить 1000000 телефонов так нельзя.

                                                Но длину пина можно увеличить, мы про это думаем.

                                                Сделайте, пожалуйста, как у всех, я не хочу иметь одно приложение для всех 2FA и для вас отдельное.
                                                А если мы сделаем поддержку RFC 4226 в нашем приложении, это не решит проблему?
                                                • 0
                                                  Если он будет так же хорош, как и Authy с Bluetooth интеграцией, то да.
                                                  • 0
                                                    А что Authy делает по Bluetooth?
                                                  • +1
                                                    Так а что криминального в том, что пароль будет скомпрометирован? Да, троян собрал пароль, попытался его ввести в яндекс, пришла смс. Пользователь, который сознательно включил второй фактор понимает, что пароль его куда-то слился и надо менять везде, где он используется. Никаких проблем по-моему.
                                                    • 0
                                                      >>А если мы сделаем поддержку RFC 4226 в нашем приложении, это не решит проблему?
                                                      Решит! Правда, пока не появится кто-то третий, с еще одной классной идеей.
                                                    • 0
                                                      А вы не допускаете, что со временем компрометация смартфонов будет стремиться к показателю pc? Почему вы решили, что смартфоны все такие неуязвимые? Поэтому и делают 2 фактора, потому что подобрать оба не получиться.

                                                      А чем вам метод енум вебмани не нравится? Код енума временный, так что никто не будет давать суток, на его подбор.
                                                      • 0
                                                        А вы не допускаете, что со временем компрометация смартфонов будет стремиться к показателю pc?
                                                        Допускаю. Если это будет наблюдаться, переделаем.
                                                        Код енума временный, так что никто не будет давать суток, на его подбор.
                                                        Тут тоже пароль временный.
                                                      • 0
                                                        > А если мы сделаем поддержку RFC 4226 в нашем приложении, это не решит проблему?

                                                        К сожалению, нет. По крайней мере не для меня. В 1password появилась встроенная функция, и естественно яндекс.ключ не заменит 1password. Кроме того, у меня на компьютере есть скрипт, который генерирует эти одноразовые пароли, чтобы не лезть за телефоном – его яндекс.ключ тоже не заменит (но скоро заменит обновление 1password для OS X). Вот поэтому удобно когда вся реализация стандартная.
                                                        • 0
                                                          Как я писал выше, мы опубликуем спецификацию, 1password сможет ее реализовать.
                                                          • +2
                                                            Это все слова, которые мне, как пользователю, ничем не помогут. Вот если 1Password действительно реализует этот стандарт, тогда, конечно, впечатления будут другие. В общем тут все понятно, вопрос закрыт, спасибо.
                                                      • +4
                                                        Телефон же только у Вас. 4-значным пинкодом защищены даже банковские операции по картам — там тоже только одолжить. Плюс приложение не выдаст ошибку, если введён неправильный пинкод — пароль всё равно сгенерируется. И, разумеется, от перебора защита тоже есть, как и во всей системе аунтентификации Яндекса.
                                                        А если Вы отдаёте нзащищённый телефон злоумышленнику, то он имеет доступ ко всему его содержимому.
                                                        • 0
                                                          Увеличили возможное количество цифр в пин-коде. Теперь можно сделать от 4 до 16 цифр. Ну и в Яндекс.Ключ теперь можно добавлять не только Яндекс, но и другие сервисы, работающие по TOTP.
                                                          Попробуйте :)
                                                        • +1
                                                          Чуть ранее то же самое реализовали WhatsApp. Правда вроде iOS у них пока не поддерживается. Но суть механизма один в один.
                                                          А планируется поддержка дополнительных методов аутентификации, а не только «фирменных»? Наример Google Authenticator?
                                                          • +1
                                                            Когда мы решим, что все основные неудобства и неровности в нашем способ двухфакторной аутентификации устранены, мы опубликуем этот метод в качестве RFC и постараемся договориться о поддержке в том числе и в Google Authenticator.
                                                            • 0
                                                              Как успехи в этом направлении? Хотел включить 2FA для Яндекса, но не стал, потому что он не работает через Google Authenticator.
                                                              • 0
                                                                Пока что сделали только обратное: поддержали в Яндекс.Ключе стандартный алгоритм https://yandex.ru/support/passport/key/external-websites.xml
                                                        • 0
                                                          А если нет ноута, есть только смартфон, пытаюсь аутентифицироваться для использования сервисов Яндекса в телефонном-браузере или приложении. Поменялся ли как-то стиль работы с Паспортом с самогО смартфона?
                                                          • 0
                                                            Если Вы активируете двухфакторную аутентификацию, то на сайтах самого Яндекса и в приложениях, написанных Яндексом, нужно использовать одноразовые пароли, генерируемые Яндекс.Ключом. Для быстроты можно просто долго жать на пароль — он скопируется в буфер, а Вы его вставите в нужную форму (приложение или мобильный сайт). Но если Вы сами не включите 2FA, аутентификация будет проходить полностью как и раньше, по старому паролю.
                                                            В остальном схема работы с персональными сервисами Яндекса не меняется: однажды введя тот самый одноразовый пароль, вы сможете работать с сервисом и сегодня, и завтра, и через неделю, пока не нажмёте «Выход» или не очистите cookies в браузере.
                                                            • 0
                                                              Только в этом случае Вам придётся в процессе подключения двухфакторной аутентификации вместо сканирования QR-кода копировать текстовый аналог с сайта oauth.yandex.ru/access/ в приложение Яндекс.Ключ.
                                                            • 0
                                                              О! Идеи витают в воздухе. :) Вот то-же самое один-в-один можно сделать на любом сайте с использованием моего приложения для подписания документов. :)
                                                              • +5
                                                                После включения и выключения 2ФА у меня в Яндекс.Диске на смартфоне исчезли все файлы из оффлайн-папки.
                                                                Повторил эту процедуру 2 раза — результат тот же.
                                                                • +1
                                                                  Ради интереса проверил — действительно исчезли.
                                                                • 0
                                                                  8 латниских симоволов запонимить для 30и секундного ввода довольно сложно. Может стоит на выбор предоставлять вариант с цифрами?
                                                                  • 0
                                                                    Их не нужно запоминать — они у Вас перед глазами на телефоне. За 30 секунд их можно считывать по одной и вводить. А можно воспользоваться магией QR-кода.
                                                                    • 0
                                                                      А если я на этом же телефоне авторизуюсь в браузере, и ваше приложение по какой-то причине не может связаться с серверами? Например, я сижу через WiFi с прокси
                                                                      • 0
                                                                        Долгим нажатием на пароль он копируется в буфер обмена, а потом вставляется в нужном приложении.
                                                                        • 0
                                                                          Окей, ладно, а как его сосканирую?
                                                                          • 0
                                                                            UPD: перечитал, понял, вначале считал что пароль создается на основе сосканированного кода
                                                                      • 0
                                                                        Для меня с первого раза это было нелегко (ввести 4+4 символа через пробел). С включенным (а он включен всегда) пунтосвитчером — это вообще целый ритуал.
                                                                        • –1
                                                                          Никому не рассказывайте, но пробел на самом деле вводить не обязательно :) Надеюсь, в следующий раз это облегчит Вам ввод пароля :)
                                                                          • 0
                                                                            Спасибо, я пока отключил 2FA. Я пока не готов к этому.
                                                                    • 0
                                                                      Android 2 в пролете…
                                                                      • +1
                                                                        Такими же принципами руководствовались и ребята из TeddyID.com, только для любых сайтов и любых телефонов (не смартфонов, wp, bb, etc), на хабре про них писали — habrahabr.ru/post/248575/
                                                                        • –1
                                                                          Отпечаток пальца спрашивается только при первом запуске, а потом только PIN? Почему?
                                                                          • 0
                                                                            Проверьте, пожалуйста, что в настройках Яндекс.Ключа (шестерёнка в углу экрана открытого приложения) активирован способ аутентификации при помощи Touch ID. Если Вы ранее уже при старте приложения задавали соответствие пары pin-код+отпечаток, то далее приложение будет просить с Вас отпечаток пальца, можно использовать только отпечаток. Если pin-код был введён неправильно, то нужно задать соответствие заново. TouchID — это лишь ключ к хранилищу паролей внутри iOS, куда записывается Ваш pin-код.
                                                                          • +1
                                                                            Первым делом при включении двухфакторной аутентификации Яндекс просит номер телефона, хотя в описанной схеме он никак не участвует.

                                                                            Сессию удобнее слать пушами, а QR оставить в качестве резервного канала. И не нужно будет вручную запускать приложение. А для защиты от дурака можно их сделать фоновыми по умолчанию.
                                                                            • +4
                                                                              Сессию удобнее слать пушами
                                                                              Да, спасибо, думаем про это. Пуши только задерживаются иногда.
                                                                              • +2
                                                                                Они задерживаются даже реже, чем SMS, а среднее время доставки сильно меньше.

                                                                                Вы так и не ответили, зачем вам в этой схеме номер телефона?
                                                                                • +1
                                                                                  Номер — что б восстановить доступ, если человек смартфон потеряет.
                                                                                  • 0
                                                                                    А если я использую планшет, причём тут вообще телефон?
                                                                                    • +2
                                                                                      Вы спросили, зачем нам номер телефона. Я ответил — для восстановления.
                                                                                      • 0
                                                                                        А если у меня нет номера телефона (у меня правда нет)
                                                                                        • 0
                                                                                          Мы думаем над другими способами восстановления.
                                                                                          • 0
                                                                                            Мастер-ключ, который на бумажку надо записать.
                                                                                            • 0
                                                                                              Не потеряете бумажку-то?
                                                                                      • 0
                                                                                        Так если у вас приложение на планшете слетит / планшет потеряете / сломается, как восстанавливать почту будете?
                                                                                        • 0
                                                                                          Нам нужен не номер телефона устройства, где установлено приложение. Нам нужен любой номер телефона, доступный пользователю, на который он сможет принять sms в случае, если ему нужно восстановить доступ.
                                                                                          • 0
                                                                                            Переустановлю / установлю приложение на другой девайс. Можно восстанавливать доступ через пароль, другую почту или секретные вопросы. Смущает обязательная привязка именно к номеру телефона.
                                                                                            • 0
                                                                                              Если конечно первая часть секрета в бэкапе или облаке.
                                                                                • +1
                                                                                  Клиент Яндекс диск на Windows7 отпал
                                                                                  • 0
                                                                                    То же самое на Mac OS X 10.10
                                                                                    Не авторизуется ни по старому паролю, ни по паролю приложения, ни по пину установленному для 2FA.
                                                                                    • +1
                                                                                      Он авторизуется по временному паролю из приложения Yandex.Key в телефоне.
                                                                                    • 0
                                                                                      Для аутентификации в приложениях Яндекса надо использовать одноразовые пароли, генерируемые Яндекс.Ключом. Для сторонних приложениях (для Диска это те, что работают по WebDAV) надо использовать пароли, создаваемые на странице oauth.yandex.ru/access
                                                                                      • +1
                                                                                        Вы называете это «не для гиков»? Для приложений создай специальный пароль, но для яндекс приложений одноразовый пароль, но для яндекс сборщика почты создай специальный пароль.
                                                                                        • 0
                                                                                          Всё достаточно просто: те сайты и приложения, которые написаны самим Яндексом, аутентифицируются через одноразовые пароли, генерируемые Яндекс.Ключом; все прочие внешние приложения (а сборщик, настраиваемый на стороне gmail.com — это тоже внешнее приложение), которые работают по специальным протоколам (IMAP, POP, SMTP, WebDAV, CalDAV, XMPP…), будут аутентифицироваться по отдельным паролям для приложений, создаваемым на странице oauth.yandex.ru/access. Кажется, что «не гику» гораздо проще установить приложение от Яндекса или зайти на сам сайт Яндекса, чем настраивать что-то по WebDAV или IMAP. А те, кто уже в это начали ввязываться, смогут отличить приложение Яндека от другого, для которого надо другой пароль.
                                                                                          • 0
                                                                                            Но если сборщиком является сам яндекс, то надо создавать пароль для приложений (как вы указали в этом комменарии), хотя сборщик яндекса очевидно написан самим Яндексом. Не вижу логики.

                                                                                            К тому же при этих правилах выходит, что авторизоваться в яндекс.диске для windows будет сложнее, чем в стороннем приложении для яндекс.диска, потому что для стороннего приложения пароль можно скопировать, а для официального приложения пароль придется переписывать из телефона вручную (ну если официальное приложение не научится показывать QR-коды, конечно).
                                                                                            • 0
                                                                                              Приложения мы обязательно доработаем таким образом, чтобы там тоже появилась магия QR-кода. А также мы постарались в Яндекс.Ключе показывать пароль группами символов, чтобы он легче считывался и легче запоминался для перепечатывания.
                                                                                              Про ситуация со сборщиками с Яндекса на Яндекс уже тоже думаем.
                                                                                    • +26
                                                                                      Если бы каждый из семи сервисов, которые есть у меня в Google Authenticator, делал своё приложение для входа, я бы, скорее всего, перестала пользоваться 2FA вообще. Так что было бы значительно приятнее, если бы была возможность пользоваться стандартным способом.
                                                                                      • +7
                                                                                        Это правда. Мы собираемся решить эту проблему двумя путями:
                                                                                        1. подумать над реализацией поддержки RFC4226 и RFC6238 в следующих версиях Ключа
                                                                                        2. опубликовать наш алгоритм в виде RFC, что б другие разработчики могли подтянуться, это мы сделаем, когда выйдем из бета-версии, надо какой-то опыт накопить и устаканить спецификацию
                                                                                        • +1
                                                                                          Не забудьте, что владельцы умных часов типа Pebble могут настроить на часах, можно использовать опенсорсные реализации при нежелании пользоваться маркетом, и вообще найти клиент под симбиан или обычный джавафон
                                                                                        • 0
                                                                                          Мне как пользователю не нравится необходимость каждый раз вводить пин-код. А вот ввод логина и пароля на сайте я бы оставил. Кроме того, имхо, лучше сделать возрастающую паузу перед вводом следующего цифрового кода, нежели переходить на символы.
                                                                                          • +1
                                                                                            Ого! Только вчера сокрушались на работе, что дескать если бы у Yandex бала двухфакторная аутентификация, то потихоньку стали бы переводить всю почту на него. Yandex, оперативно черт возьми!
                                                                                            • 0
                                                                                              Вот, человек без инвайта попросил поделиться как мне показалось полезным опытом

                                                                                              Меня зовут Лёха, я эникейщик в глубокой сибирской жопе.Увидел на хабре твой
                                                                                              комментарий по поводу перевода ящиков компании на яндекс, топик про двухфакторную
                                                                                              авторизацию habrahabr.ru/company/yandex/blog/249547/#comment_8261189.
                                                                                              Комментировать не могу, безинвайтный, но чувствую себя обязанным предупредить о
                                                                                              подводных камнях, я как раз сейчас занимаюсь разгребанием последствий размещения
                                                                                              ящика учреждения на яндексе.

                                                                                              Контора у нас государственная, ящик приёмной руководителя, кроме секретаря туда
                                                                                              наведывалось и руководство, сам глава, зам.главы, главбух и т.п. За время
                                                                                              существования ящика успел смениться весь состав конторы, и не по разу.
                                                                                              И вот похоже кто-то из уволившихся этот ящик и увёл. Разумеется никто не помнит что
                                                                                              там указано в данных, а мои предупреждения о том что такой режим небезопасен
                                                                                              и пароли нужно менять игнорировались — госучреждение, чиновники, сам понимаешь.

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

                                                                                              Разумеется при попытке восстановления начинается абсурд. Ты можешь дать самые
                                                                                              убедительные доказательства того что ящик принадлежит организации, а поддержка
                                                                                              в ответ будет долдонить «паспорт не совпадает с именем.

                                                                                              Я например предъявил ЭЦП руководителя, где этот ящик прямым текстом указывается.
                                                                                              Казалось бы, ЭЦП намного надёжнее фото паспорта, её не подделать. Не тут то было. У
                                                                                              поддержки в инструкции похоже написано „только если паспорт совпадает с именем, указанным
                                                                                              при регистрации“ и прошибить её невозможно.

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

                                                                                              Почему фото паспорта оказалось надёжнее ЭЦП в век фотошопа, и почему игнорируется
                                                                                              распространённый способ использования ящиков остаётся только недоумевать. Даже государство уже
                                                                                              запилило единый портал, авторизующий по ЭЦП, а Яндекс тем временем: „Электронная подпись? Не, не слышали.“
                                                                                              • 0
                                                                                                Яндекс не предусматривает режима использования ящика сотрудником
                                                                                                с безопасным переходом ящика к последующему сотруднику.
                                                                                                Мне кажется, вы описываете кейс для ПДД. ПДД специально придумана для жизни организаций на Яндексе. Попробуйте.
                                                                                                • 0
                                                                                                  Спасибо за ссылку! Переход на Yandex мне еще только предстоит… Буду разбираться
                                                                                                • 0
                                                                                                  При восстановлении доступа к почтовому ящику в домене yandex.ru (не на подключённом к Яндексу домене) учитывается очень много факторов. Сотрудники исследуют ситуацию с разных сторон в попытках зацепиться за что-то, ведь мы тоже заинтересованы в восстановлении доступа, чтобы пользователь остался с Яндексом дальше. Но паспорт пока что является одним из весомых аргументов для идентификации.
                                                                                                  А ЭЦП ведь создана самой фирмой — там эта фирма может точно так же что угодно написать, любой email.
                                                                                                  Поэтому для бизнес решений действительно лучше заводить ящики не yandex.ru, а подключать свой собственный домен к Яндекс.Почте. Тогда управление паролями производится через специальную доступную администратору панель.
                                                                                              • +2
                                                                                                По-моему пароль браузер в большинстве запоминает сам (не запоминает при кривой или намеренной реализации формы входа).
                                                                                                То есть с моей точки зрения было бы достаточно чтобы QR-код предоставлял URL, на который нужно отправить код, сгенерированный по RFC 4226 код (можно было бы резать иначе чтобы увеличить сложность перебора). Было бы безопаснее, а так украв телефон остается обмануть биометрический датчик, и всё — можно сделать полноценный вход, ваше знание не нужно, то есть вход по сути однофакторный, просто вы для себя усложнили реализацию.

                                                                                                К стати, по поводу
                                                                                                удел банков и прочих нетехнологичных компаний

                                                                                                посмотрите на ПриватБанк, у них вход через QR-код и многие другие штуки уже очень давно)
                                                                                                • +1
                                                                                                  Как часто для кражи аккаунта у пользователей крадут телефоны и обманывают биометрические датчики?
                                                                                                  • –1
                                                                                                    Потерять телефон весьма просто, а обман биометрики — это уже если есть такое желание.
                                                                                                    Мне не нравится идея того, что биометрика (не слишком надежная) стала единственным, что нужно для входа.
                                                                                                    К примеру, можно взять телефон соседа пока он отвернулся, войти в своем браузере, и положить телефон на месте. Вполне реалистичный вариант. Можно вообще попросить поиграться. Без знания пароля одноразовые токены бесполезны, а тут совсем нет, пароль вообще не нужен.
                                                                                                    • 0
                                                                                                      Хорошо, допустим, ваши соседи дают вам телефон поиграться и сообщают вам свой пин-код (или вы создаете поддельный отпечаток).
                                                                                                      Теперь давайте попробуем оценить сколько аккаунтов уводится таким способом, сколько аккаунтов уводится с помощью зараженных машин, сколько случаев взлома можно предотвратить, вводя неудобную схему, защищающую от первого сценария, и сколько можно предотвратить, вводя удобную схему, защищающую от второго.
                                                                                                      • 0
                                                                                                        Всё зависит от ситуации. Если взлом целенаправленный, а не массовый — то вариант с биометрикой ненадежный, а без нее неудобный — пароль всё ещё нужно вводить.
                                                                                                        habrahabr.ru/company/yandex/blog/249547/#comment_8261261
                                                                                                        • 0
                                                                                                          От целенаправленного взлома вас никто никогда надежно не защитит (особенно при привычке давать телефон соседу), это в принципе бессмысленно.
                                                                                                          • 0
                                                                                                            Само собой, но всегда есть выбор реализовать удобнее и безопаснее, менее удобно с тем же уровнем безопасности, либо так же удобно но менее безопасно. Я могу ошибаться, возможно статистика покажет обратное, но мой вариант видится более удобным, и не менее безопасным.
                                                                                                        • +1
                                                                                                          С точки зрения Яндекса, вы правы, но с точки зрения пользователя — нет. Меня (как пользователя) не волнуют проблемы других пользователей. Мне важно чтобы МОИ данные (почта, файлы и тд) были надежно защищены.
                                                                                                    • +2
                                                                                                      То есть с моей точки зрения было бы достаточно чтобы QR-код предоставлял URL, на который нужно отправить код, сгенерированный по RFC 4226 код (можно было бы резать иначе чтобы увеличить сложность перебора).
                                                                                                      Там так и сделано. В Ключе, конечно, HMAC из RFC4226 (тут изобретать велосипед незачем), только функция усечения дает выход побольше именно для защиты от перебора.
                                                                                                      украв телефон остается обмануть биометрический датчик
                                                                                                      Я про это написал в посте. Да, мы заложились на стойкость Secure Enclave, он сделан довольно разумно. Конечно, можно украсть отпечаток пальца (про это тоже написано), но если вы этого боитесь, не используйте TouchID.

                                                                                                      На Приватбанк и на многое другое, конечно, посмотрели.
                                                                                                      • 0
                                                                                                        Не совсем так, на сколько я понял из статьи, пароль нужно вводить на телефоне, в то время как у меня браузер сам его запоминает.
                                                                                                        По-моему просто убрать необходимость ввода циферок и увеличения токена было бы достаточно, и было бы удобнее, так как удалось бы избавиться от ввода пароля совсем.
                                                                                                        • 0
                                                                                                          Пароль Вы вводите в том месте, где открывается форма авторизации. То есть это либо браузер на настольном компьютере, либо браузер в мобильном телефоне, либо приложение (если речь о приложении, написанном самим Яндексом, а не сторонним). Браузеры обычно всё же не запоминают всё молча, а спрашивают, сделать ли это. Да и какая разница, если пароль одноразовый — второй раз он уже не сработает, даже если будет запомнен.
                                                                                                          А в приложении Яндекс.Ключ надо вводить только пин-код. Ну или отпечаток пальца, если речь о последних версиях iOS.
                                                                                                    • 0
                                                                                                      В верстке странички, показывающей QR-код, работает JavaScript, ожидающий со стороны сервера ответа на проверку пароля с данной сессией.


                                                                                                      Я правильно понимаю, что если злоумышленник знает ID сессии, то вся остальная защита бесполезна?
                                                                                                      • 0
                                                                                                        Нет.
                                                                                                        • +1
                                                                                                          Не могли бы ответить более развернуто? Почему знания ID сессии недостаточно, чтобы получить сессионные куки при успешной проверке пароля пользователя?
                                                                                                          • +4
                                                                                                            Возможно, я не очень подробно сформулировал вопрос. Представьте, что где-то в общественном месте пользователь готовится авторизоваться на сайте Яндекс при помощи этой технологии. У него открыта страница с бар-кодом. Пока он достает свой смартфон, проходящий мимо официант незаметно фотографирует этот бар-код на свой телефон. Теперь он имеет ID сессии и ждет, пока клиент отправит на сайт свои данные. Может ли официант получить ответ от сервера раньше клиента?
                                                                                                            Это, конечно, все утрированно и вместо официанта может быть классический man-in-the-middle, но тем не менее.
                                                                                                            • +2
                                                                                                              Спасибо. Ценная мысль.

                                                                                                              Тут есть место для гонок. Это можно решить так: если в пределах одного окна пришло сразу две одинаковых аутентификации, надо считать невалидными обе. Подумаем, как это лучше сделать.
                                                                                                              • +1
                                                                                                                Да, но «официант» ничего не посылает. Он лишь пытается по ID сессии получить сессионные куки раньше «клиента» и таким образом получить доступ к аккаунту этого клиента. Вопрос был про это. Но две аутентификации по одному сессионному ID конечно тоже стоит рассмотреть.
                                                                                                                • +1
                                                                                                                  Так это тоже самое. Если он получит сессионную куку раньше клиента, случится аутентификация. Ее двойника и нужно ловить.
                                                                                                                  • +4
                                                                                                                    Нет, действительно непонятно. Если комп пользователя считается по определению ненадежным, то кто мешает злоумышленнику как-либо заблокировать аутентификацию пользователя и аутентифицироваться самому? Ну условно говоря, официант не только фотографирует qr-код, но и тут же отключает wifi во всем кафе?

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

                                                                                                                    Точнее даже так: если компьютер пользователя скомпрометирован, то поможет ли какая-нибудь двухфакторная аутентификация вообще? Вирус просто дождется, когда пользователь заглогинится, и так или иначе вытащит куки из браузера или что еще требуется?
                                                                                                                • 0
                                                                                                                  Сделайте маленький-маленький QR-код, который можно считать только вплотную к экрану, и его увеличение при нажатии, если чувствительности матрицы телефона не хватает. Это точно можно сделать по умолчанию, если пуш сделаете.
                                                                                                                  Вообще, посмотрите, как у Webmoney Enum реализован. Это, пожалуй, лучшая реализация, что я видел.
                                                                                                                  • 0
                                                                                                                    ok, посмотрим.
                                                                                                                    • 0
                                                                                                                      Не проще вбить пароль руками, если так страшно использовать QR? Ключ может просто сам генерировать пароль, не только взаимодействовать по QR.
                                                                                                                      • 0
                                                                                                                        Маленький-маленький QR-код на маленьком-маленьком экране с большими пикселями и пользователь со старым андроидом :)
                                                                                                                        Лучше не добавлять геморроя таким образом. Раз уж уменьшают количество кликов, то лучше и здесь не добавлять.
                                                                                                              • 0
                                                                                                                Ввод 8 символов за 30 секунд может быть довольно сложным для некоторых пользователей, если уж вы делаете не для гиков, то учтите, что многие из них, особенного старшего возраста, не пройдут этот шаг при включении 2FA.

                                                                                                                Вопрос: если включить 2FA для ПДД то сборщик яндекс.почты продолжит собирать почту с ПДД ящиков, или надо будет вбивать в сборщик пароли для приложений?