Компания
493,63
рейтинг
3 февраля 2015 в 13:17

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

Редкий пост в блоге Яндекса, а особенно касающийся безопасности, обходился без упоминания двухфакторной аутентификации. Мы долго думали, как правильно усилить защиту пользовательских аккаунтов, да еще так, чтобы этим мог пользоваться без всех тех неудобств, которые включают в себя самые распространённые ныне реализации. А они, увы, неудобны. По некоторым данным, на многих крупных сайтах доля пользователей, включивших дополнительные средства аутентификации, не превышает 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 выплачивается двойная премия.
Автор: @ivlad
Яндекс
рейтинг 493,63

Комментарии (285)

  • +10
    Наконец таки! Плохо то, что я не смогу воспользоваться данной опцией имея старенькую нокию и свежий кнопочный филипс. Не люблю я сенсор… Пользуюсь телефоном только для звонков.
    • –6
      Всё это здорово, конечно, с авторизацией, а вот у меня вопрос к компании Яндекс:
      Хочу удалить свой очень старый аккаунт Яндекс (Почта, Деньги), которым не пользуюсь. Для удаления нужно ввести ответ на секретный вопрос, но у меня он не подходит (хотя и был записан в файле). Бог с ним. Написал в техподдержку, на что мне ответили, что в Яндекс нужно прислать скан паспорта(!) При регистрации (в те далёкие времена) от меня никакого скана паспорта (да и паспортных данных) не просили. Не хочу я вам свой паспорт светить.
      • +6
        Если к Вашему аккаунту не был привязан номер телефона и Вы сами не смогли никаким образом вспомнить какие-то автоматические средства восстановления доступа к аккаунту, то служба поддержки, как человеческий фактор, должна быть на 100% уверена, что даёт этот доступ и секретные данные не постороннему человеку, а истинному владельцу. Даже тот факт, что Вы на данный момент находитесь в ящике, не говорит, что Вы и правда владелец ящика.
        На данный момент одним из важных критериев идентификации является сравнение данных, которые Вы указывали при регистрации (ФИО, дата рождения и т.п.) с паспортом.
        Разумеется, эти данные сохраняются только в Яндексе, и не используются ни для каких целей, кроме как для восстановления доступа.
      • +5
        Так просто продолжайте им не пользоваться и всё.
      • 0
        Думаю уже много тысяч человек выслали свой паспорт Яндексу и еще много куда… Какую угрозу для себя Вы видите в скане паспорта? И какова вероятность этой угрозы? А можете оценить вероятный урон в деньгах?
  • +5
    Для WP планируется приложение?
    • +6
      IMHO, вопрос надо ставить не «планируется или нет», а «когда выйдет?».
    • 0
      Мы постараемся поддержать Windows Phone в будущем, но пока не можем назвать какие-либо сроки реализации. Сообщим об этой новости либо рассылкой, либо в одном из официальных Twitter-аккаунтов Яндекса.
  • +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
            Это тоже правда. Но есть таки подозрение, что оно уже совсем скоро изменится. Уж не знаю к лучшему-ли оно, но подозрение есть.
          • 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
          Поддержали :)
      • 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
    А если нет ноута, есть только смартфон, пытаюсь аутентифицироваться для использования сервисов Яндекса в телефонном-браузере или приложении. Поменялся ли как-то стиль работы с Паспортом с самогО смартфона?
    • 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 для ПДД то сборщик яндекс.почты продолжит собирать почту с ПДД ящиков, или надо будет вбивать в сборщик пароли для приложений?
    • 0
      Сборщик — это тоже приложение, поэтому в него тоже нужно вводить пароль для приложений.
      Не для гиков мы сделали возможность аутентификации через QR-код — руками надо будет ввести только 4 цифры пин-кода в приложении Яндекс.Ключ.
      30 секунд — это всё же около 3 секунд на каждый символ. Кроме того, визуально мы разбили символы на две группы, чтобы запоминать их частями и легче вводить. Пока что мы считаем, что всех этих мер достаточно.
      • +2
        Путь тестировщики проведут эксперимент на своих родителях — сколько времени им понадобится чтобы переписать 8 английских символов с экрана телефона в браузер, с учетом того, что тратится время на распознание символа на незнакомом языке и его поиск на клавиатуре. Да я понимаю, что есть QR-код, но при первоначальной активации 2FA временный код все равно приходится вводить, этот шаг пропустить нельзя.
        • 0
          Очень ценное замечание про родителей. Многие печатают двумя или даже одним пальцем. И я вот не уверен, что все успеют.
  • +2
    Это несложно, ведь смартфон почти всегда находится онлайн

    Включаю интернет только когда нужно что-то. ЧЯДНТ?! Точно так же поступают многие знакомые — а у кого двухсимочники и одна симка только для интернета — так некоторые ее вообще вырубают полностью когда не пользуются.

    Итого получается, без камеры — не зайти (с того же смартфона с браузера например), свой стандарт с поддержкой только iPhone и Android 4 на данный момент…

    А RFC реализованы уже на куче различных устройств — включая умные часы и непопулярные мобильные платфомы
    • +1
      Итого получается, без камеры — не зайти
      Зайти. Одноразовым паролем.
      • 0
        Да, перечитал ту часть, понял. А то я после первого прочтения и осмысления воспринял что одноразовый пароль создается на базе считанного QR-кода.
  • +4
    А что делать, если я потеряю телефон? Или сделаю фактори резет? :-) Есть ли фоллбэк-авторизация с помощью смс?
    • +1
      Есть восстановление с помощью СМС. Для этого на первом шаге и спрашивают номер телефона.
      • +1
        Будет ли возможность пользоваться 2FA без телефона и мобильных сетей? Не часто встретишь людей без телефона, но я таких знаю, да и самому приходилось пользоваться Enum через Java ME эмулятор.
        • 0
          Думаем про это. Хотя сейчас нам кажется, что это какой-то очень минорный кейс: смартфоны с андроидом от 3000 рублей нынче, по-моему.
          • 0
            Ох. На многих китайских телефонах шел (идет?) предустановленный с завода вирус под названием smsreg.apk, который отправляет СМС в Китай каждый раз при смене SIM. Лично я доверяю своему компьютеру значительно больше, нежели своему смартфону, даже несмотря на то, что я туда установил всякие ограничители прав и мониторинги. Уже существуют приложения под Android, которые не требуют root и прав администратора устройства, не отображаются в меню и незаметно отсылают СМС на номера банка без уведомления пользователя.
  • –2
    А самое смешное во всем этом — что на iOS настроить не получается. На последнем шаге требует пароль из приложения, но после ввода ругается на неправильный пароль.
    • 0
      Вы уверены, что сайт требует пароль, а не пин-код?
  • +26
    Ну вот, я уже обрадовался было, что наконец-то Яндекс сделает двухфакторку по RFC, и я смогу его занести в свой MS Authenticator в тёплую компанию к
    Гуглу,
    Майкрософту,
    Гитхабу,
    Дропбоксу,
    Фэйсбуку,
    Вордпрессу,
    Вконтакту,
    и даже моему любимому Тайнипэссу, для которой я сам буквально пару месяцев назад её и реализовал (обкатывается на QA, скоро глобально включим).

    Но нет. Оказывается, Яндекс изобрёл свой собственный нестандартный велосипед, для которого вдобавок нету приложения под WP.

    Спасибо, Яндекс.
    • +1
      Мы постараемся в будущем решить эту проблему. Когда устраним все критичные неудобства, о которых сообщат пользователи и сгладим некоторые неровности, то либо опубликуем наш метод в виде RFC, которое смогут поддержать другие приложения, либо поддержим в том числе имеющиеся RFC4226 и RFC6238 в следующих версиях Ключа.
      • +3
        Очень надеюсь, что это не займёт много времени. Включенная двухфакторка реально необходима в современных условиях.

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

        Буду ждать следующего анонса.
  • 0
    Включил, настроил, создал пароль «Облачный сервис» на Windows. Пытаюсь зайти в Яндекс.Диск (Windows 7) — неверный пароль. ЧЯДНТ?
    • 0
      Запустите яндекс.ключ. Там (синими буквами) создайте одноразовый пароль. И введите его в приложение. Это работает для всех приложений яндекс!
      • 0
        Спасибо, все получилось (для компьютера), главное в 30 секунд успеть
  • +3
    Вариант не такой простой для начала использования, но гораздо удобнее в дальнейшем — U2F. Воткнуть ключ быстрее, чем разблокировать телефон, ввести пин и отсканировать баркод.
    • +2
      Да, Яндекс участвует в FIDO Alliance. Я в курсе про UAF и U2F. Если посмотреть на схему работы Ключа, видно, что она похожа на UAF.

      Я не очень верю в широкое распространение U2F токенов, к сожалению. Но, безусловно, если это случится, мы поддержим именно U2F. Там нет недостатков, присущих RFC6238.
  • +1
    наши usability-исследования показывают, что ничто так не раздражает пользователей, как промежуточный экран, дополнительные нажатия на кнопки и прочие «неважные», с его точки зрения, действия

    То есть, проблема не в том, что RFC плохой, а в том, что пользователь, в среднем, не обладает достаточной компьютерной грамотностью. На вопрос о том, стоит ли решать эту проблему изобретением собственных методов (см. xkcd://927), или лучше заняться повышением компьютерной грамотности населения каждый пусть лучше ответит самостоятельно.

    Из любопытства: а возможность пользоваться TOTP по RFC останется для тех, кому iOS и сканирование QR-кодов с экрана не очень интересны?
    • +1
      Главная проблема RFC4226 — маленькое пространство выхода функции усечения. Этот результат нельзя использовать в качестве единственного пароля, поэтому те, кто его используют, вынуждены согласиться на двухстадийность аутентификации. Нам двухстадийность не нравится именно по указанной причине.
      • 0
        Ну кто-то может и «вынужден», а для кого-то это благо. Вопрос в области применения. И всё же, я повторю вопрос ещё раз: возможность пользоваться TOTP по RFC останется для тех, кому iOS и сканирование QR-кодов с экрана не очень интересны? Или Яндекс планирует полностью перейти на собственное решение?
        • +1
          Ну кто-то может и «вынужден», а для кого-то это благо.
          Поясните, для кого и почему двухстадийность аутентификации является благом?

          Или Яндекс планирует полностью перейти на собственное решение?
          То, что есть сейчас — бета версия. Мы, конечно, будем смотреть на то, как это работает и выбирать лучшее решение.
          • +1
            Поясните, для кого и почему двухстадийность аутентификации является благом?

            Для нас, но мы и не почтовые аккаунты с амурной перепиской таким образом защищаем. Кроме того, таковы требования NSA.

            То, что есть сейчас — бета версия. Мы, конечно, будем смотреть на то, как это работает и выбирать лучшее решение.

            Такое ощущение, что за вас это предложение отдел маркетинга написал :)
            • 0
              Кроме того, таковы требования NSA.
              Как жаль, что при разработке своих сервисов, Яндекс не учитывает пожелания NSA. :)
              Такое ощущение, что за вас это предложение отдел маркетинга написал :)
              Нет, я действительно хочу услышать констуктивную критику и сделать эту штуку лучше. Я пока услышал две вещи: сделать пин длинее и использовать U2F. Про обе я обещаю подумать. Пожелания сделать двухфазную аутентификацию я тоже услышал, но без понятной мне аргументации, почему это лучше. Возможно, в этом треде я дойду до понимания необходимости.
            • 0
              Кроме того, таковы требования NSA.
              Как жаль, что при разработке своих сервисов, Яндекс не учитывает пожелания NSA. :)

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

              В общем, серьезно — бета-версия, что-то может измениться. Хочется сделать хорошо и правильно.
              • 0
                Не вижу повода для сарказма. У Яндекса вместо NSA есть ФСБ, требования (sic!) которой вам либо уже надо учитывать, либо рано или поздно придётся. У меня нет цели раскритиковать ваше решение. Мне, например, было бы интересно посмотреть, можно ли (особенно при вашем размере пользовательской базы) эффективно поддерживать оба решения, и как это реализовать на практике.

                Если отвлечься на секунду от задач Яндекса, то, в случае именно двухстадийной аутентификации, доступ к определёным ресурсам можно ограничить таким образом, чтобы для прохождения второй стадии нужено было присутствие другого человека (например, супервайзера с токеном, санкционирующего таким образом доступ). Естественно, для защиты пользовательской переписки это избыточная мера. Поэтому, в частности, меня и заинтересовал ваш подход. Однако, учитывая мою целевую аудиторию, поддержка стандартного решения TOTP первична: кроме живых людей бывают ещё средства автоматизации, которые тоже используют одноразовые пароли для определённых действий, но вот нажать на кнопку в телефоне не могут. Впрочем, это опять же очень далеко от почты.
                • 0
                  Для Яндекса NSA — не разработчик стандартов, а оппонент. Известно, что NSA может преследовать собственные цели при разработке стандартов, поэтому для нас неправильно полностью на них полагаться. Что касается требований ФСБ в части аутентификации для публичных (негосударственных!) Web-сервисов, то когда они возникнут, мы, конечно, изучим необходимость их поддержки.

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

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

                  В отношений всяких средств автоматизации наш подход такой: там не нужны OTP, там нужны OAuth-токены с органиченным скоупом или их аналоги. Поэтому, например, у нас для сборщиков почты предусмотрены пароли приложений — с ними можно прочитать почту, но, например, нельзя управлять счетами в Директе. И наоборот. Но я не знаю вашей задачи, возможно там почему-то необходимы именно TOTP по RFC6238 для работы. Как я написал выше, если такая задача у нас возникнет, мы, вероятно, сможем это поддержать.
                  • +2
                    NSA стандарт не диктует, их аудиторы требуют определённый уровень безопасности, а выбор средств остаётся на совести компании. Но мы уходим в сторону.

                    По технической части решения здесь есть с кем поговорить и так, меня же смущает вот что: у меня сложилось мнение, что современному пользователю интернета меньше всего хочется ставить ещё одно приложение. Тот же Google Authenticator есть под все актуальные платформы, RFC6238 реализован, наверное, уже на всех языках программирования, и, что немаловажно, тот же самый RFC используется не только гуглом. То есть можно иметь одно приложение для всех сервисов, при чём для тех, кому по каким-то причинам не подходит GA есть ещё и альтернативы (хотя они и так себе, если честно). С другой стороны, ваши опасения тоже небезпочвенны. Заставить пользователя не исповедовать религию Неуловимого Джо сложно, практически невозможно без насилия, но я гуманист и такой подход не люблю. Как мне кажется, хорошим выходом было бы поддерживать RFC6238 вне зависимости от крутости вашего решения, как на сервисе (ну вдруг мне мама не велит Yandex Authenticator ставить?), так и в вашем приложении (а может быть наоборот, не велит ставить GA). В конце концов, наличие достойной альтернативы GA пошло бы только на пользу.
  • +2
    А где совместимость с 1password?
    Зачем мне отдельное приложение для этого?
    Только все перенес в 1password и удалили угловое приложение.
    • 0
      В будущем мы постараемся сделать более открытое решение, которое смогут поддержать разработчики аутентифицирующих приложений. Либо мы опубликуем наш метод в виде RFC, когда поймём, что критичные не устраивающие нас моменты исправлены, либо поддержим RFC4226 и RFC6238 в следующих версиях Ключа.
      Всем будет удобно :)
      • +1
        Прошел год. Ну что, есть совместимость с 1password?
  • +2
    в Яндекс.Сторе нет приложения… странно
    • 0
      В ближайшее время появится. Извините за задержку :(
  • +3
    Двухфакторная аутентификация, которой удобно пользоваться

    И что здесь удобного? Функция бесполезна для тех у кого нет смартфона.
    • 0
      Да. Google предлагает альтернативу приложению в виде SMS.
  • +6
    Если я в роуминге без интернета на смартфоне, то зайти в почту с чужого компьютера нереально. Найс. Как зайти в почту через сам смартфон, экран через два зеркала сфоткать? Удобно.

    Это отличный пример высасывания из пальца, такого, что повторяет то, что уже другие сделали, но надо чтобы было непохоже, потому что просто присоединиться «западло». Проблема скомпрометированного компьютера полностью надумана, потому что если он скомпрометирован, то как бы пользователь не зашёл в почту, то его данные уже утекли. А утёк там секрет генерации последовательности или нет, уже не суть важно.
    • +1
      Поему Вы считаете, что зайти в почту с чужого компьютера не получится? Одноразовые пароли тем и хороши, что вводить их можно на любом компьютере — даже если они там сохранятся, то второй раз не сработают. Кроме того, на чужом компьютере обязательно стоит нажать галочку «чужой компьютер» в форме авторизации. Зеркала при работе через один только смартфон совсем не нужны. Наш способ двухфакторной аутентификации позволяет вводить пароли руками, а позволяет сканировать QR-код. Просто QR-код — это небольшое упрощение для пользователей настольных компьютеров (или планшетов). А так — только что сгенерированный в Яндекс.Ключе пароль можно скопировать долгим нажатием пальца и вставить в любую форму аутентификации, будь то браузер или приложения от Яндекса.
      • 0
        Так а как сгенерить пароль, если у телефона нет соединения с интернетом?
        • 0
          Но читать почту же как-то планируется — без интернета это невозможно, а значит, какая-то точка есть. В современном мире Wi-Fi, LTE и прочих беспроводных способов связи подключить телефон к интернету не такая большая проблема.
          • 0
            Проблема, если в роуминге. Может бить стационарный компьютер с интернетом и нет продключения в телефоне.

            Но всё же мне мой fido ключик милее, воткнул в USB и всё работает, не разрядится и интернет не просит.
        • 0
          Он генерится без интернета. Интернет нужен только для того, что б вход по QR работал. А так можно пин ввести, нажать кнопку «покажи пароль» и его вбить в форму.
          • 0
            А, ну тогда ладно. Главное успеть за 30 секунд вбить 8ми значный рандомный пароль.
            • 0
              По нашим тестам кажется, что это реально.
              • 0
                а почему 30 секунд а не 60? На брутофорс это никак не влияет. Кстати какая у вас защита от брута?
                • +1
                  очевидно 30-секундная (хи-хи)
  • +2
    Спасибо, интересное решение! Два вопроса и одно пожелание:

    1) Как два iOS-устройства сделать доверенными способами авторизации? Сейчас после настройки одного не удаётся добавить аккаунт на другом: на oauth.yandex.ru/access не найти QR-код для этого.

    2) Как я могу повысить секьюрность для входа в мобильные приложения на самом iOS-устройстве? Раньше я сам определял, насколько длинным будет пароль (единый, но значит и для iOS-приложений тоже). Сейчас безопасность мобильного приложения снизилась до «завладеть устройством» + узнать «4 цифры» [+разлочить устройство]. Причём эти 4 цифры я ввожу для каждой авторизации на любом устройстве — то есть «свечу» их не реже, чем единый пароль раньше.

    Пожелание: окно для считывания QR-кода очень маленькое, например iPad Mini приходится весьма ощутимо отдалять от экрана ноутбука, чтобы «попасть». Можно сделать его практически совпадающим с полным размером экрана?
    • +1
      1. Для добавления нескольких устройств, надо считать один и тот же QR-код всеми устройствами (ну или вбить его текстовый аналог руками в приложение на стадии, когда оно просит QR-код). То есть настройку приложения Ключ нужно осуществлять на всех устройствах параллельно, чтобы одновременно ввести коды. Последовательно не получится.
      2. На данный момент мы всё же считаем, что «завладеть устройством» — это крайне редкий случай для взломов, особенно по сравнению с троянами на ноутбуках и прочих настольных компьютерах. Ну и пин-код в Яндекс.Ключе всё же может и должен отличаться от того кода, который используется для блокировки всего устройства. Чуть выше ivlad писал про это и упоминал, что мы уже думаем о возможности увеличении длины пин-кода.

      Пожелание про размер окошка для сканирования учтём, спасибо!
      • 0
        1 — это очень неочевидно из всех интерфейсов. А чем вызвано, что нельзя позже добавить второе устройство? Ведь дб нередким сценарием…

        2 — с позиций Яндекса приоритеты ясны. Но с моих личных позиций и в моих конкретных условиях — мои риски существенно другие, и вопрос именно исходя из них. Длина пин-кода — вариант, хотя не совсем понял, почему вместо пина не сделать просто произвольный пароль?

        Пожелание — вам спасибо!
      • 0
        > настройку приложения Ключ нужно осуществлять на всех устройствах параллельно, чтобы одновременно ввести коды.

        Так и сделал. Теперь одним устройством успешно вхожу; второе же при попытке считать QR-код для авторизации приводит к тому, что на вебе перекидывает на «Войти по одноразовому паролю», а в нём при попытке ввести логин и сгенерированный этим вторым устройством пароль — странное для данного контекста «Неправильная пара логин-пароль! Авторизоваться не удалось.»
        • 0
          Разобрался: оказывается аккаунт добавился в дополнение к старому, со старым PINом — и по умолчанию стоял старый.

          Это несмотря на то, что я пытался «снести» приложение Я.Ключ и установить его заново.

          В любом случае, при попытке добавить уже существующий аккаунт с новыми credentials стОит автоматически «убивать» старый, за ненадобностью.
          • 0
            Спасибо за подробности!
    • 0
      Сегодня весь вечер не могу залогиниться с 2FA: пробую браузер на iPad (iOS 8.1.1, Safari) и на OS X (Mavericks, Chrome stable); приложение на том же iPad и на iPhone 4 (iOS 7.x); результат за несколько раз стабильный (для всех вариантов):
      1) первая попытка: «неверная пара логин-пароль»
      2) вторая попытка: QR-сканнер просто не распознаёт код

      Ответ «неверная пара» выдаётся и для QR-кода, и для одноразового пароля.

      Отдельное неудобство — что при каждом возврате в приложение «ключ» PIN спрашивается заново, даже если я в нём был 10 секунд назад. Второе неудобство — что при переключении между одноразовым паролем и QR-кодом время от времени (не всегда?) переспрашивается PIN-код (зачем?).

      В общем, пока я почти готов отключить 2FA как недостаточно надёжную на данный момент.
      • 0
        Разобрался с «неверной парой» — это было следствием неверно введённого PINа. Который успешно «принимается» приложением, но затем из-за на вебе него получается «неверная пара». Очень не хватает для таких случаев внятной диагностики — в чём всё-таки проблема, что с такой ситуацией делать.

        Всё остальное из моего предыдущего комментария остаётся актуальным, увы.
        • 0
          Очень не хватает для таких случаев внятной диагностики — в чём всё-таки проблема, что с такой ситуацией делать.
          Очевидно, сервер не может сказать в ответ «у вас неправильный пин», тогда бы очень легко было бы их перебирать. Да и не знает он, что неправильное — пин или еще что-то.
          • 0
            Спасибо, Володя. Про это сейчас прокомментирую.
            А по остальным пунктам моего предыдущего комментария кто-то из специалистов сможет ответить?
          • 0
            Очевидно, сервер не может сказать в ответ «у вас неправильный пин», тогда бы очень легко было бы их перебирать. Да и не знает он, что неправильное — пин или еще что-то
            Давай ненадолго притворимся, что ничего не знаем о том, как оно устроено внутри — посмотрим как это выглядит для пользователя (а также для злоумышленника). Для начала ограничившись сценарием сканирования QR-кода.

            1. Пользователь: вот он вводит PIN, сканирует QR, запрос уходит на десктоп — и тот внезапно говорит «неверная пара логин-пароль». Помогает ли такое сообщение понять пользователю, что он сделал не так, и что нужно исправить? Есть ли хотя бы список для пользователя «что попробовать сделать, чтобы исправить ошибку» — в числе которых будет «проверьте что вы ввели верный PIN»? Кажется, нет => для пользователя всё крайне неинтуитивно.

            2. Злоумышленник: вот он решил брутфорсом подобрать PIN-код, и получает ответ «неправильный логин-пароль». Как это мешает ему продолжать перебор? Разве это не «security by obscurity», который уже самим нашим здесь обсуждением сводится на нет? => Злоумышленнику текущая невнятность диагностики практически никак не мешает.

            Таким образом, конкретно для QR-кода невнятность не несёт никакой пользы, но явно вредит. Честный пользователь может ошибиться только с вводом PINа (ну и ещё, в теории, тем что взял ключ от другого аккаунта). А ему никак не помогают понять, что он сделал не так.

            Для одноразовых паролей всё не настолько однозначно (там честный пользователь может ошибиться и при вводе одноразового пароля), но тоже смысла прятать истинную причину проблемы как-то не видно.
  • +2
    Включил двухфакторку, на телефоне в приложении почты ввел 30 секундный пароль, отображаемый в яндекс ключе на этом же телефоне с 5 раза, почта висит на «Загрузка», выключил двухфакторку.
    • 0
      Уточните, пожалуйста, версию приложения Яндекс.Почты и операционной системы на Вашем телефоне. Вы же используете приложение почты, написанное Яндексом, а не предустановленное, работающее по IMAP?
      • 0
        Андроид 4, устанавливал из стора официальное от яндекса.

        После отмены двухфакторной авторизации только раза с 10 удалось запустить приложение с паролем. Проходит авторизация, дальше бегает загрузка и все.
        • 0
          Пришлите, пожалуйста, на app-mail@support.yandex.ru или же мне личным сообщением данные, которые показываются в форме обратной связи внутри самого приложения. Надо зайти в настройки под списком папок, затем в самом низу списка выбрать «Помощь и обратная связь» и нажать «проблема» — в открывшейся форме будет техническая информация, которую нам надо прислать. Или же можно зайти в настройки, выбрать «о приложении», а затем долго жать на иконку с конвертом, чтобы появился UUID.
          • 0
            Отправил. Но если Вам нужно снять эту информацию, когда висит загрузка ( то есть когда воспроизводится ошибка ), то не получится, потому как и раздел просмотра папок и раздел меню ( там где настройки, входящие, удаленные и прочие ) просто висит на «загрузка» и бегающий ползунок.
          • 0
            И да, чуть не забыл сообщить. При переходе на двухфакторную авторизацию после первой попытки авторизации у меня в настройках появился второй аккаунт аналогично первому, только с маленькой буквы. Первый, допустим — Test1234, второй появился test1234.
            • 0
              Мы по UUID сможем найти проблему, если Вы сослались в письме на данное обсуждение :) А проблема с раздвоением ещё актуальна? Можете сделать скриншот и тоже всё отправить в поддержку?
              • 0
                Сейчас при включении обратно двухфакторки все ок. Что было до этого — напишу на тот же ящик.
  • +3
    joxi.ru/eAO4DV4U9jEdro — помогите, как определить ОС сборщика очты? :) все сломалось, хочу настроить обратно…
    • +3
      Анна, рады, что единственный недостаток, который вы обнаружили в нашей системе — мелкая неточность в интерфейсе. :) Значит, мы все сделали правильно. Верстку мы поправим. Пока же можете использовать «другое» — ведь у mail.ru нет своей операционной системы, не так ли? :)
      • +1
        это не единственный ) про другие вам уже много написали выше, зачем повторяться. к слову вот прямо сейчас один из моих знакомых не смог протестировать потому, что у него старый айфон с 5-й иос, например. т.е. это уже даже не винмобайл или нокия. но, ради фразы про «невысокотехнологичность», ваши пользователи, конечно, могут и потерпеть :) p.s. кстати, когда выбираю «другая», оно спрашивает название, очень настойчивая штука, пойду админов будить и спрашивать.
  • +1
    А что делать если смартфон 99% не в сети и wifi нет?
    Кроме того если у пользователя не подключены (не важно по какой причине) App Store и Google Play, то такой узер в пролете?
    • 0
      Если смартфон не в сети, то в нем все еще можно сгенерировать одноразовый пароль и руками вбить его в форму ввода.

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

        А сколько трафика кушает ваше приложение при осуществлении процесса аутентификации?

        • 0
          Приложение может работать даже офлайн. Соединение нужно только при сканировании QR-кода — тогда приложение отправляет данные в систему само за пользователя. А если вбивать пароль руками, то приложение просто сгенерирует его офлайн. Ну и сами представьте, сколько надо трафика, чтобы передать небольшой набор символов.
  • +1
    Первое впечатление от идеи — в техническом плане — здорово, и довольно очевидно. Первое впечатление как человека: не удобно. Я лично не стал бы пользоваться этим. Ну гик, я только звоню по телефону. Да. Зато мне не приходится его заряжать каждый день.

    Я хочу входить надёжно, но не использовать телефон вообще. А так выходит, чтобы прочитать почту, мне надо будет руки мыть, чтобы отпечатки заработали? :)
    • 0
      Никто же не принуждает Вас использовать именно аутентификацию по TouchID. Вместо него можно использовать обычный pin-код.
      • 0
        Да конечно! Сама идея подтверждения владения чем-либо, мне не очень нравится… :( Как и многим… Ибо процент двухфакторников минимален.
  • +3
    Не будет поддержки RFC 6238 или RFC 4226 — не взлетит.
  • +1
    Очень приятно, что появилась двухфакторная аутентификация: с ней спокойнее. Неужели предложенный подход оказался проще и удобнее, чем привычные SMS с паролями? Этот вопрос заслуживает отдельного поста.
    • 0
      Он не только менее удобный (много всего вводить надо), но ещё и менее надёжный: SMS может нередко задерживаться или не доставляться, а также его можно перехватит, а шифрования в SMS не было и нет. В то время как приложение генерирует пароль даже в том случае, когда не имеет доступа к интернету, и никуда его не передаёт открыто, кроме как показывает на экране.
      Если же вместо ручного ввода пароля Вы используете аутентификацию по QR-коду, то данные передаются по шифрованному соединению, их уже почти невозможно перехватить, а удобство (не)ввода пароля явно увеличивается, потому что вводить нужно только 4 цифры пин-кода в приложении.
      • +2
        его [SMS] можно перехватит

        Выше ваши коллеги (или вы) говорили что видите вариант кражи телефона соседа по офису и подсматривание пароля — фантастическим вариантом, а тут уже перехват SMS для вас обыденный вариант o_O

        данные передаются по шифрованному соединению

        Кстати, у вас в приложении используется Certificate Pinning или подобное? Или обычный HTTPS на основе сертификатов ОС?
        • 0
          перехват SMS для вас обыденный вариант
          Перехват sms нынче может выполняться удаленно и достаточно массово, если у атакующего есть доступ к ss7. Воровство телефона (в офисе или в метро) — атака на конкретного человека, вор, на мой взгляд, скорее заинтересован телефон быстрее продать, чем с ним что-то делать.

          Конечно, случаи бывают разные, пожелание про увеличение длины пина мы уже услышали, подумаем про это.
          Кстати, у вас в приложении используется Certificate Pinning или подобное?
          Используется.
    • +2
      Перехват SMS, а точнее «замена» карты в офисе мобильного оператора уже была. Предъявляли паспорт при замене или без паспорта… Концов не найти. Что взять с мальчика в торговом зале офиса абстрактного «мобильного оператора» с их зарплатами и текучкой кадров.

      В результате у нескольких человек через сервис Банк-Клиент похитили по несколько миллионов (а не надо гранты на личном счете хранить).
      Понятно, что атака была персональная и продуманная.
      Банк, мобильного оператора, город и подробности — не называю специально. Но было такое и будет. Просто не слишком афишируется.

      Двуфакторная авторизация в Банк-клиенте через SMS — зло.
      Операции в Банк-клиенте без цифровой подписи для физ.лиц. — зло…

      Поскольку работаю в сфере разработки ПО для платежных кар — храню на них только минимум.
      И свой банк-клиент отключил (банк, где держу счета, начал экономить на аппаратных токенах физ.лиц. для подписи операций).
      • 0
        И свой банк-клиент отключил (банк, где держу счета, начал экономить на аппаратных токенах физ.лиц. для подписи операций).
        А почему бы не сменить банк?
        • 0
          А нет банков (рядом с домом/работой), которые для сервиса Клиент-банка физ.лиц. предлагают подпись операций ключом, с аппаратного токена. И не факт что они вообще остались.

          Для юр.лиц. — это стандарт (ЭЦП), а для физ.лиц. у всех одинаково дыряво (как в Сбербанке).
          Попал на страницу Банк-клиента (хорошо если есть хоть какая двуфакторная аутентификация) и делай что хочешь.
          Как минимум, практически у всех есть оплата мобильного на произвольный номер. А как максимум — перевод на чужой расчетный счет, а то и карт.счет. по PAN карты.
          Почему этими дырками не пользуются массово — не понимаю.
          • 0
            Мне банк продал кард-ридер, которым подписываются транзакции. Размер подписи небольшой, но, думаю, достаточный для того, что б счет заблокировать, если что.
            • 0
              Вот это правильный вариант. В моем банке раньше то же так было и я этим пользовался. USB карт ридер для карт SIM формактора. Не совсем дешево (~50Eur), за то надежно.

              Более того — я карточное приложение для ЭЦП и разрабатывал, после того как в Gemalto (тогда еще Gemalto) из линейки продуктов GPK карты убрали.

              А потом пошел тренд «массовый продукт для тупого пользователя».
              И видимо подсчитали, что не выгодно больше это поддерживать/спрос маленький.
  • +6
    Почему ваше приложение требует минимум Android 4? Вы что не можете прочитать QR код и отобразить ключ на младших платформах? Google Authenticator работает на 2.3 и не парится, всё же это не тот тип приложений, для которых нужно топовое устройство!
    • 0
      На старте (а приложение и вся система выпущена в бета-версии) было решено сделать решение только для самых распространённых и популярных платформ. В дальнейшем будем работать над расширением по операционным системам и возможностям, чтобы сделать двухфакторную аутентификацию ещё доступнее.
  • +3
    … Ведь говорил я ему тогда за
    завтраком: «Вы, профессор, воля ваша, что-то нескладное придумали! Оно,
    может, и умно, но больно непонятно. Над вами потешаться будут»…
  • +2
    Есть 2 аккаунта. Использую на разных компах, — рабочий и домашний. Я так понимаю к одному телефону их привязать не получится?.. Яндекс диски не подерутся?
    • 0
      В Яндекс.Ключ можно добавить несколько логинов, как и вообще на телефон в менеджер аккаунтов. В Диске просто будет выбран один из тех логинов, что присутствует в менеджере аккаунтов. Логин из Яндекс.Ключа даже не обязательно заводить потом в менеджере аккаунтов, если Вы не хотите его использовать в мобильных приложениях Яндекса.
  • +1
    а куда и кого в яндексе спрашивать (а желательно — и вовсе стукнуть чем-нить тяжелым) за смену яндекс.подписки на яндекс.новости, которые мало того что неюзабельны, так еще и с ходу роняют браузер, заставляя его выжрать всю доступную оперативку?
  • +1
    >Многофакторность в аутентификации определяется отнесением элементов аутентификации (собственно, они и называются факторами) к одной из трех категорий

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

    А вообще любой 2FA фигня если вы не делаете правильный out of band verification транзакций. В вашем случае для яндекс денег такое просто необходимо. Обычный пиннинг браузер приности такую же результативность.
  • 0
    Вы рассматривали риск, когда Гугл и Эпл будут удалять ваше приложение из-за политики? Отключите двухфакторку? А пользователи как будут восстанавливать доступ к своей почте? (старые пароли большинство позабывает)
    • 0
      В процессе настройки 2FA Яндекс требует указать телефон именно для того, чтобы в случае неприятности можно было восстановить доступ к логину. Но Гугл и Эппл — не единственные владельцы сторов, а установочный файл можно взять не только из стора.
      • 0
        О как! И как же мне на айфон поставить приложение не из эппстора не ломая ось? Корпоративные не считаются
        • 0
          Одно средство Вы уже назвали :) Второе: купить Android :) Мы делим труп неубитого медведя. Никто доступ к приложениям Яндекса не закрывал. Хотел бы — уже сделал.
          • 0
            Первое средство нерабочее — там же ограничение в N пользователей. Второе — лол, стиль мейл.ру прям…
          • 0
            Закрывал, к сожалению. Прецедент — Крым, оттуда вроде как вообще никаких приложений уже скачать нельзя. Как из AppStore, так и из Play Market.
            • –1
              Есть Яндекс.Store, например. Владельцам iPhone можно только посочувствовать. Но они изначально выбирали закрытую платформу.
              В любом случае, пока что это только старт, для которого было принято решение взять только популярные распространённые платформы. В будущем мы очень хотим сделать более массовое решение, чтобы им можно было воспользоваться даже не с самых продвинутых телефонов.
  • +3
    Отличная штука! Остается вопрос. Когда будет Яндекс.Ключ API, чтобы можно было эту технологию использовать в своих проектах?
  • +1
    Пожелание по интерфейсу программы Яндекс.Ключ — сделайте сразу экранную цифровую клавиатуру для ввода пин-кода, как это сделано например в Сберовском приложении.
    Если уж вы заботитесь о пользователях, не любящих лишние экраны, то это как раз оно. Открыть приложение, нажать на поле ввода, дождаться открытия клавиатуры, вот это всё (раздражает).
    • +2
      Спасибо, подумаем о такой возможности при развитии приложения — хорошая идея :)
      • 0
        … а также было бы круто совместить показ одноразового пароля и видоискатель камеры для QR-кода. Чтобы переключение между этими режимами не требовало лишних тапов: один режим не подошёл — другим воспользовался.
  • 0
    Это все конечно очень занимательно, только в вашей новой разработке я не заметил чего-то действительно нового, кардинально отличающегося от того же E-num, вебманевского клиента двухфакторной авторизации. Притом E-num образца где-то 2011 года, когда они тоже делали ставку на QR-коды.
  • 0
    Юзабилити-исследования это тоже хорошо, но по собственному опыту скажу, что решение через QR-коды выглядит таким красивым и удобным только на бумаге. На деле это такой же, а то и даже больший гемор, чем оффлайн-генерация пароля. Разлочить телефон, войти с паролем в аппку, перейти в режим сканирования, сфокусировать камеру на коде, выровнять, справиться с тремором похмельным. :) Пальцами вбить число-вопрос и получить число-ответ оказывалось быстрее и проще. Те же вебмани полагаю также провели какие-то свои юзабилити-исследования и в итоге от QR практически отказались (полагаю разочаровали они не меня одного). Теперь второй пароль у них приходит просто в виде пуш-уведомления, которое сейчас может сразу и на умные часы выводиться. Вот это я понимаю — кошерно и удобно. :)
    • 0
      Мы подумаем про пуш-уведомления.
    • 0
      Ну, справедливости ради, хочу заметить – на пятом айфоне QR считывается до того, как я помещаю qr-код в квадратик на экране. Т.е. я ещё только собираюсь прицелиться, но код уже попал в объектив и считался.
      Про модель телефона я упомянул исходя из того, что это должно зависеть от камеры и ещё чего-нибудь.
      • 0
        Не стану спорить — гемор был на 4 айфоне и на еще более старой нокии. Сейчас у меня давно у самого пятерка, а на ней очень крутая, чувствительная камера. Но с пушками это все равно не сравнится, они же как смски, появляются прямо на рабочем столе смартфона, его даже разблокировать не надо.
  • +2
    Радует, что Яндекс начал движение в сторону более удобной двухфакторной аутентификации, хотя и более чем на год позже, чем мы.
    Еще больше радует, что Яндекс осмелился изобрести свое решение, а не стал делать «как у всех».

    Однако не вижу, как это решение защищает от фишинга?
    1. Атакующий завлекает жертву на фишинговый сайт, который выглядит точно так же как сайт яндекса
    2. Жертва думает, что это сайт яндекса, и для входа с помощью приложения кликает на значок QR кода на фишинговом сайте
    3. Атакующий (точнее его робот) кликает на такой же значок на реальном сайте яндекса
    4. Яндекс показывает QR код атакующему и начинает ждать
    5. Атакующий транслирует QR код жертве на фишинговом сайте.
    6. Жертва сканирует QR код своим телефоном.
    7. Телефон жертвы посылает данные на сервер яндекса, и яндекс открывает аутентифицированную сессию… атакующему.
  • +1
    ура яндекс изобрел велосипед SQRL www.grc.com/sqrl/sqrl.htm
    • 0
      На самом деле, этот велосипед еще и с квадратными колесами, в отличие от SQRL.
  • 0
    Не получается подключить, смс не приходит на номер, который был перенесен на другого оператора. Видимо баг.
    • 0
      Если SMS так и не удалось получить, скажите мне в личном сообщении номер телефона, пожалуйста, и оператора, чьими услугами Вы пользуетесь.
      • 0
        В 10.40 утра пришло сразу 5 смс :) Сейчас проверил еще раз, смс пришла сразу же. Спасибо
  • 0
    После включения 2fa не могу залогиниться в приложении Я.Почты на iOS: ни старый пароль, ни «пароль приложения» не воспринимаются. QR-сканера в приложении нет.
    Во встроенном почтовом клиенте по паролю приложения войти получается. Но хочется-то родное приложение.
    Мои действия?
    И второй вопрос: а можно сделать «копию» Я.Ключа на втором моём устройстве?
    • +1
      В приложениях, написанных самим Яндексом, нужно использовать одноразовые пароли из Яндекс.Ключа. Скопировать их оттуда можно долгим нажатием на текст сгенерированного пароля.
    • +1
      Для того чтобы подключить один аккаунт к Ключам на двух устройствах, нужно их настраивать одновременно, параллельно, и сканировать один и тот же QR-код на странице подключения 2FA. То есть Вам нужно отключить 2FA, затем (только после отключения) удалить из приложения Ключ уже настроенный аккаунт, долго нажимая на аватар, а потом произвести настройку заново, но уже на двух устройствах сразу.
      • 0
        Спасибо, попробую чуть позже. Но опять-таки, в инструкцию добавите? ;)
  • 0
    а есть ли у вас описание этого решения на английском языке — что нибудь вроде ietf draft? Или может быть статья где-то опубликована с описанием всех деталей решения. Спасибо
  • 0
    Скажите пожалуйста, а есть ли альтернативный и безопасный вариант входа в аккаунт, в случае, если смартфон недоступен, скажем если разрядилась батарея или телефон забыт дома?

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

    • коды входа (печатаются на бумажку и хранятся в "безопасности"). Данная система используется Google, F-secure.
    • секретный вопрос или серия секретных вопросов.

    В общем, беспокоит зависимость от смартфона.
    • 0
      Я не очень понимаю, как Вы хотите получать SMS, если батарея Вашего телефона разрядилась. Но если допустить, что Вы смогли вставить sim-карту в аппарат соседа, то восстановить доступ вполне реально через страницу https://passport.yandex.ru/restoration — потребуется sms и знание пин-кода, на основе которого создаются одноразовые пароли для Вашего аккаунта.
      Вариант с кодами входа тоже достаточно узкий: ведь эта бумажка лежит у вас в тумбочке дома, а там уж зарядить телефон не проблема. А вот в каком-то месте, где зарядить телефон проблематично, и кодов тоже под рукой не будет. А значит, они неэффективны.
      Вариант с серией вопросов мы обдумываем.
      • 0
        Спасибо за ваш ответ и за ссылку на восстановление доступа через яндекс паспорт. Однако, это крайняя мера, которая приводит к смене пароля и выходу на всех устройствах, что не совсем удобно, особенно учитывая, что потом придется заново вводить пароли приложений.

        Смс, действительно, можно получить, вставив сим карту в другой телефон. Это возможно, если на минуту представить, что человек ходит с 2 телефонами или попросит на время телефон друга, супруга, коллеги по работе, с которым едешь в метро и т.д. Также, это позволит избавиться от предположения, что телефон — обязательно смартфон. А чтобы гарантировать, что вход не пытается сделать злоумышленник, незаконно получивший сим карту, можно запрашивать пароль или пин код из приложениея — в точности так же, как при восстановлении доступа.

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

        Все эти варианты могли бы послужить основной цели — альтернативному методу входа в аккаунт безопасным путем (если мы договорились считать, что двухуровневая система входа безопасна), без жесткой привязки к наличию смартфона.
  • 0
    (извините за некропостинг)
    Скажите, пожалуйста, выше вы писали о том, что опубликуете RFC с описанием. Есть ли какой-нибудь прогресс в этом отношении?
    Где-нибудь можно почитать официальное описание, как сгенерировать одноразовый ключ, кроме как разобрать apk?

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