• Семинар про криптографию и PGP Keysigning party

      На семинаре про криптографию, который завтра пройдет в Яндексе, состоится PGP Keysigning party. Если хочется подписать свои ключи и пообщаться с криптопараноиками, приходите.

      Для того, чтобы поучаствовать в подписи ключей, лучше заранее загрузить свой публичный ключ на biglumber.
    • Выбор ciphersuites для TLS и уязвимость Logjam. Опыт Яндекса

        Сейчас на фоне уязвимости Logjam все в индустрии в очередной раз обсуждают проблемы и особенности TLS. Я хочу воспользоваться этой возможностью, чтобы поговорить об одной из них, а именно — о настройке ciphersiutes. Мы уже не раз писали на Хабре о том, как внедряем шифрование трафика на сервисах Яндекса: например, об этом весьма подробно рассказывал Эльдар kyprizel Заитов, но ciphersiutes были одной из вещей, которые в тот раз остались в основном за кадром. Кстати, хочу всех успокоить и сказать, что на серверах Яндекса никогда не использовался экспортный вариант алгоритма Диффи-Хеллмана.

        Итак, Ciphersuite — это совокупность алгоритмов, используемых в конкретной TLS–сессии. Сюда относятся:

        • алгоритм выработки сессионных ключей шифрования;
        • алгоритм, используемый для аутентификации сервера;
        • собственно симметричный алгоритм шифрования трафика;
        • и, наконец, алгоритм контроля целостности (MAC, message authentication code).

        Для того чтобы понять, какова роль каждого из алгоритмов, давайте вкратце рассмотрим процесс инициализации TLS–соединения в применении к HTTPS (разумеется, TLS возможен и для других TCP и UDP протоколов, но сейчас мы это рассматривать не будем). За подробностями можно обратиться в RFC5246.

        image


        В TLS есть собственный механизм деления на сообщения, называемый record protocol. Каждое TLS-сообщение не обязано быть равно TCP-сегменту, оно может быть больше или меньше.
        Читать дальше →
      • Двухфакторная аутентификация, которой удобно пользоваться

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

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

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



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

          Расскажу о том, почему мы решили не использовать такие «стандартные» механизмы, как RFC 6238 или RFC 4226. Как работают распространенные схемы двухфакторной аутентификации?
          Читать дальше →
        • 1 000 000 уже неработающих паролей в открытом доступе. Как мы защищаем пользователей Яндекса

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

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

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

            Конечно, мы не храним пароли открытым текстом, никогда не передаём их по сети открытым текстом и не открываем их любым третьим лицам. Более того, большинство из этих паролей слишком простые, и сейчас их даже установить не получилось бы. Технические и не очень подробности читайте под катом.
            Читать дальше →
          • Яндекс почистил DNS view для AAAA-записей

              Сервисы Яндекс довольно долго работали, используя механизм DNS whitelisting на манер RFC6589. Для этого использовались средства DNS view в BIND. В белый список попадали провайдеры, имеющие прямую связанность с Яндексом (as path равен 1) и анонсирующие нам IPv6 префиксы. Я даже рассказывал про это на одной из конференций YaC. При этом, конечно, большой радости эта конструкция не приносила, хоть и белый список обновлялся автоматически, все равно с ним было неудобно: вроде, сервис и есть, а вроде и люди на него не могут попасть.

              Поэтому недавно мы собрались с духом и убрали DNS view для сервисов, работающих в зоне yandex.com — Поиск, Карты, Почту и Паспорт.

              А сегодня тихо и незаметно убрали из DNS view ya.ru.