В начале июня сотрудник компании Sakurity Егор Хомяков (Egor Homakov) написал пост о созданной им технологии SecureLogin, являющейся заменой парольной аутентификации. Несмотря на то что Егор наверняка прекрасно говорит и пишет по-русски, мы не смогли найти русскоязычного варианта и решили сделать перевод оригинальной статьи. Результат вы можете найти под катом.


Сегодня я с гордостью представляю SecureLogin Authentication Protocol 1.0, над которым работал последние 3 года.


Как насчет демки? Легко!


Нет, это не менеджер паролей. Да, это очередная попытка заменить пароли, причем для всех, а не только для гиков.


Кстати, я горжусь не нативными приложениями и реализациями? — ?это была лишь небольшая часть работы, объем которой не превышает нескольких тысяч строк кода.




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


Этот баланс основывается на 3 принципах.


Децентрализация


Никакая третья сторона не должна иметь возможность войти в вашу учетную запись откуда бы то ни было: ни провайдер телефонной связи, сливающий ваши SMS-коды, ни провайдер электронной почты, сбрасывающий ваши пароли, ни Facebook Connect/Google OAuth, выдающий ваш access_token кому-то другому, ни правительства и хакеры, тем или иным способом делающие это через вышеперечисленные сервисы. Только ваше личное устройство должно иметь возможность удостоверять запросы для вашей учетной записи.


На первый взгляд более привлекательные «2FA как сервис»-провайдеры, такие как Authy или Duo, не подпадают под определение end-2-end-децентрализованных, поскольку представляют из себя централизованные службы, подтверждающие запросы от имени пользователя. По большому счету это альтернативная реализация механизма «подтверждение по ссылке в email».


В настоящий момент добиться действительно безопасной аутентификации можно с помощью TOTP (например, Google Authenticator) или USB-ключа типа U2F.


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


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


Пришло время поговорить о втором принципе, на котором основан SecureLogin.


Удобство



Демонстрация пользовательского интерфейса десктопного и мобильного приложений


Это очень похоже на Facebook Connect (исключая зависимость от серверов Facebook): вы нажимаете кнопку Login, приложение открывается, вы подтверждаете запрос, и это все.


Никакой возни с аппаратными ключами, одноразовыми паролями, ожидания электронных писем или SMS, доставания телефона из кармана, сканирования QR-кодов и т. д.


Это настолько просто, насколько вообще возможно для аутентификации.


Масштабирование


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


О резервных копиях беспокоиться не стоит, так как их не существует: ваш закрытый ключ генерируется на основе вашего же мастер-пароля. Серверы SecureLogin не смогут испортить production-базу, так как этой базы не существует. Система работает в автономном режиме (offline).


Никакого аппаратного обеспечения покупать не нужно. Написаны приложения для iOS, Android, macOS, Windows, Linux, и при этом вы всегда можете воспользоваться веб-клиентом.


Протокол полностью свободен (entirely free), и код всех клиентов открыт. За использование системы никогда ничего не придется платить.


API протокола настолько прост, что даже нет необходимости в SDK-библиотеках: 20 строк JS-кода на клиенте, 50 строк на сервере.


Если вы ищете идею для open-source-проекта, рассмотрите реализацию SecureLogin-плагина для вашей любимой CMS. Напишите мне письмо, чтобы присоединиться к нашему Slack.


Кстати, первопроходцы SecureLogin могут получить бесплатный аудит безопасности.


Вопросы?


Буду рад ответить на них в Twitter! Но сначала поищите ответ в FAQ — 90% вопросов повторяют друг друга.


Прошу заметить, что SecureLogin не задумывался как самое безопасное решение, которое покрывало бы все граничные случаи (однако для версии 2.0 планируется функциональность Doublesign), или самое комфортное решение (тут вряд ли удастся переплюнуть Facebook Connect — он слишком удобен). Здесь весь смысл в балансе.


Ссылки:


  1. Оригинал: SecureLogin?—?Forget About Passwords.
  2. UPD: Draft RFC Specification for SecureLogin.
Поделиться с друзьями
-->

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


  1. aleksandy
    27.06.2017 09:14
    +8

    Реклама детектед. Где в статье подробности того, как эта штука работает?


    1. TheKnight
      27.06.2017 09:56
      +4

      1. CnapoB
        27.06.2017 12:39
        -1

        Особенно «радует» фраза: «Any FakePage can open securelogin://#provider=RealPage&state=TheirState and once the user accepts the request it will be sent for state=TheirState, so attacker’s login request will be successful.».


        1. mayorovp
          27.06.2017 12:49

          А что с ней не так?


          1. CnapoB
            27.06.2017 13:49

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


            1. mayorovp
              27.06.2017 14:14

              И именно по этой причине автор отказался от такого решения.


  1. mayorovp
    27.06.2017 09:34

    Все чудесно, но зачем опять новый формат и новый протокол? Чем не устроил JWT как формат токена? Да и OpenID-Connect был бы желателен...


    PS а строка res.header('Access-Control-Allow-Origin', '*'); внутри мидлвари выглядит попросту страшно. Автору стоило бы назвать эту функцию SLProfileHandler, а не SLMiddleware, чтобы не пугать случайных прохожих.


  1. Akuma
    27.06.2017 09:54
    +5

    И ни слова про то как это работает. Ну что за маркетинговая отписка то?


  1. izzholtik
    27.06.2017 10:05
    -2

    Если в андроид приложении открыть «список сайтов, поддерживающих SL», а потом перейти назад, выскакивает вот такое:

    уведомление


    1. mayorovp
      27.06.2017 10:09
      +1

      Ваш скриншот выше чем мой монитор. Вы никогда не думали, что их следует сжимать (геометрически, не информационно) прежде чем вот так выкладывать?


      Или хотя бы DPI стоило бы отличный от 96 выставить...


      1. izzholtik
        27.06.2017 10:17

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


  1. MrFrizzy
    27.06.2017 11:38
    +3

    За упоминание технологии спасибо, но все же статья на хабре без технических подробностей — это рекламный буллшит. Вот у меня сразу парочка вопросов:
    1) если по одному паролю генерится всегда один и тот же ключ — где защита от прегенерации таких ключей и радужных таблиц. если каждый раз разный, то смысл генерировать по паролю?
    2) какая предусмотрена защита от кражи токенов\ключей с локалхоста малварью? — конкретно к реализации вопрос, но все же
    3) предусмотрена ли защита от запросов малвари с локалхоста, раз уж слушается http://127.0.0.1:?

    Ответов на все это я в статье не нашел. Более того, в посте на медиуме я тоже этого не нашел. И взглянув на гитхаб беглым взглядом я тоже не нашел ответов, а читать код ну как-то не хочется…


    1. MrFrizzy
      27.06.2017 11:42
      +2

      upd: вот содержание этого документа стоило бы обсуждать на хабре


      1. danzalux
        27.06.2017 21:53

        О, вот это классный линк!
        Реквестую авторов перевода добавить линк в статью!


        1. olemskoi
          27.06.2017 21:55

          Спасибо, добавили.


  1. dmitry_dvm
    27.06.2017 12:37

    Windows 10
    Edge: does not support custom protocol handlers like securelogin://. At all. They don't provide any roadmap. Use the Web version.


    Но ведь из браузера можно вызвать стороннее UWP-приложение именно по зарегистрированному им протоколу. Или я что-то не допонял?


  1. inkelyad
    29.06.2017 12:13
    +1

    А какой смысл предпочитать и в чем отличие предлагаемого решения от WebAuthn, который медленно, но верно во все основные браузеры встраивают?