BrowserID: почтовый адрес как ID пользователя

    Mozilla закончила разработку BrowserID — единой децентрализованной системы аутентификации, которая использует HTML5, криптографию с открытым ключом и цифровые подписи. Она основана на упрощённой интерпретации Verified Email Protocol.

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


    Так будет работать система, если Gmail станет поддерживать BrowserID. В этом случае отпадёт необходимость подтверждать свой email на сайте Browserid.org, который сейчас является пока единственным центром идентификации первого уровня.

    Кроме отсутствия паролей, ключевым преимуществом BrowserID является защита приватности — в отличие от OpenID и всех подобных систем, провайдер identity в BrowserID не получает данных о том, на каком сайте залогинился пользователь.

    Для поддержки BrowserID достаточно включить библиотеку include.js, добавив следующую строчку в заголовок страницы:

    <script src="https://browserid.org/include.js" type="text/javascript"></script>

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



    По нажатию на кнопку осуществляется вызов функции верификации адреса электронной почты.

    navigator.id.getVerifiedEmail(function(assertion) {
        if (assertion) {
            // This code will be invoked once the user has successfully
            // selected an email address they control to sign in with.
        } else {
            // something went wrong!  the user isn't logged in.
        }
    });

    После успешной проверки адреса электронной почты API возвращает вам подписанную строку assertion, которая подтверждает email пользователя.

    На втором этапе вам нужно верифицировать assertion и получить email пользователя. Это делается запросом к https://browserid.org/verify с двумя параметрами POST (assertion и audience) — запрос подписан уже вашей подписью. Верификатор проверяет валидность assertion.

    $ curl -d "assertion=<ASSERTION>&audience=https://mysite.com" "https://browserid.org/verify"
    {
        "status": "okay",
        "email": "lloyd@example.com",
        "audience": "https://mysite.com",
        "expires": 1308859352261,
        "issuer": "browserid.org"
    }

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

    Демо BrowserID (с конференции Mozilla All Hands в сентябре 2011 г.)
    Support the author
    Share post

    Similar posts

    Comments 44

      0
      Угнали почту и что мне делать?
        +5
        Ничего. С таким же успехом угонят все зареганные на эту почту аккаунты или зарегаются где надо.
        Я правильно понял, что я верифицирую мыло и могу просто вбивая свой ящик входить на сайт? И какую инфу обо мне будет получать сайт?
          0
          а как о них узнают, ну допустим ты угнал почту и откуда ты знаешь где он зареган?
            0
            Поковырявшись в почте. Многие не трут бессмысленные письма вроде «Спасибо за регистрацию на сайте N».
              +1
              Значит с такой системой будут тереть…

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

              следовательно утеря почты ставит под угрозу мой аккаунт, но не полностью
          +8
          Почту защитить куда проще чем кучу аккаунтов на сотнях сайтов. У того же gmail'а есть очень удобная и надежная двухфакторная аутентификация.
            –9
            ага, а теперь это расскажи всем кто пользуется mail.ru, yandex.ru, rambler итд
              0
              Зачем?
              Ничто не мешает майлру тоже внедрить 2факторную авторизацию
                +2
                Они SSL-то не могут уже который год внедрить, о чём вы говорите…
          +1
          Угнали ноут\мобилу, что мне делать?
            0
            а это здесь причем?
              0
              Логично, что сменой пароля привязка сбрасывается (по крайней мере должна), а смена пароля в аккаунте на каком-то сайте должно запрашивать пароль.
                0
                Это проблема пока не решена, кстати. Сертификат-то «я обладатель адреса» в localstorage браузера останется, пока не истечет.
              0
              Привязывать email к мобильному телефону. В случае угона — восстанавливать доступ с помощью него. Вероятность угона и емайла и телефона ну крайне низкая.
                0
                Если это не жена или подруга решили посмотреть чем ты в Сети занимаешься.
            • UFO just landed and posted this here
                +4
                Охуенно. Надеюсь это приведет к концу зоопарка всяких авторизовалок через твиттер-фейсбук-мэйлру-вконтакле, которые следят за посещенными сайтами
                  +1
                  Вообще все вами перечисленные люди используют авторизацию Oauth 2.0 :) Которая вполне себе открытая.
                    +2
                    И, за исключением базовых принципов, у каждого своя.
                      0
                      У них своя только схема взять данные о пользователе, но эта штука я бы хотел заметить никоим образом не стандартизирована. Все остальное точно как в Draft Oauth 2.0
                    +30
                    Standards
                    –4
                    Логин/пароль как-то привычнее, по крайней мере, для меня.
                      –4
                      вот именно, как не прижился openid так и это пока только утопия
                        +2
                        OpenID не прижился потому, что это никому не понятно. А Facebook Login и прочие прижились.
                          –2
                          не путайте openID и oAuth!
                          facebook, vkontakte — oAuth — прижился
                          а openID — нет
                            +3
                            Я ничего не путаю. Пользователю пофиг как технология называется: oAuth или xAuth. Вот он видит Login with какой-то OpenID или Login with Facebook. Нетрудно догадаться, чем он охотнее воспользуется.
                              –5
                              так вы уж определить FaceBook логин (oAuth) или OpenID — для меня это разные технологии
                              авторизация и аутентификация — разные вещи, сколько уже можно объяснять
                                +3
                                Я ведь совсем про технологии. Плевать как устроено. Важно как для пользователя выглядит. OpenID — очень крутая идея, только вот никто не понял, что это. Логин через социалку работает точно также, только всем понятно, потому что в Фейсбуке/Вконтакте у всех есть учётка.
                                  0
                                  Я даже уверен, что в Фейсбуке вдохновились темой с OpenID.
                                  • UFO just landed and posted this here
                                +1
                                Вы, бесспорно, правы, но… любой «трешовый» сайт, который при заходе на него через «Facebook login» спрашивает доступ к контактам, даже не смотря на то, что у меня единственный фейковый аккаунт, не получает доступа.
                                Когда «не трешовый» сайт просит авторизацию, то пускаю его на Google. И если он просит доступ к контактам — он также отлетает через Deny.

                                Людям не пояснили вообще ничего и они этого ждут — это факт.
                            +6
                            Проглядев спеку возникает несколько вопросов.
                            • Ключи/сертификаты хранятся в браузере. Как они туда попадают понятно. А как их оттуда удалять? Как быть в ситуации, когда домашним компом и, соответственно, браузером пользуется несколько человек? Как быть с браузерами в публичных местах вроде инет-кафе?
                            • Ключевое преимущество перед OpenID (провайдер identity не знает на какие сайты вы ходите) сводится на нет возможностью внешней ленивой реализации assersion verification — тот сайт, который будет для вашего сайта это делать получит полную информацию кто и когда логинится к вам на сайт. А поскольку все ленивые, и любят юзать модные внешние сервисы, то такая практика скорее всего будет довольно распространена. При этом пользователь не может узнать, как именно реализована assersion verification на этом конкретном сайте куда он логинится, и не утекает ли информация точно так же, как и при использовании OpenID.
                            • Существование secondary authority вроде browserid.org фактически означает, что они могут кому угодно выдать сертификат на какой угодно email. И Большой Брат сможет с этими сертификатами логиниться в любой аккаунт на любом сайте, достаточно знать нужный email. (При этом на самом деле никакой реальной необходимости в их существовании нет вообще — для демонстрационных нужд можно было на browserid.org поднять любой webmail с поддержкой BrowserID и при регистрации юзеров не проверять их существующие email-ы а выдавать им новый email в домене @browserid.org — т.е. прикинуться обычным primary authority вроде Gmail.)

                            Для параноиков по большому счёту ничего не меняется. Раньше мы поднимали свои OpenID-сервера на своих доменах/серверах, чтобы во-первых никакие внешние провайдеры OpenID не знали на какие сайты мы логинимся, и во-вторых чтобы внешний провайдер не предоставил доступ (нечаянно/хакеры/большой брат) на эти сайты под нашим аккаунтом никому кроме нас. С BrowserID первая проблема решена частично (внешние сервисы assersion verification?!), вторая проблема не решена (и даже усугублена существованием secondary authority), плюс добавилась третья потенциальная проблема с сертификатами в общем браузере. А решение прежнее — поднять свой провайдер BrowserID на своём домене/сервере.

                            Возможно я что-то упускаю из виду, но пока всё выглядит так: BrowserID в плане безопасности скорее хуже OpenID, а в плане пользовательского интерфейса удобнее тем, что вместо необходимости набирать свой url-идентификатор OpenID можно мышкой выбрать свой email-идентификатор BrowserID. И что-то мне подсказывает, что используя те же технологии HTML5, которые использует BrowserID, можно реализовать выбор мышкой своего идентификатора и для OpenID.
                              0
                              3. Мне кажется, понятно, зачем нужен secondary authority. Никто не будет внедрять BrowserID в качестве способа авторизации, если не все email будут поддерживать этот метод (и скажем прямо — пока никто не поддерживает). Благодаря browserid.org все email будут работать сразу. А поддержка провайдеров email этого протокола только будет означать распределение нагрузки и повышение безопасности. Сравните с openid/oauth, которые требуют обязательной поддержки со стороны провайдера.

                              Но, считаю, пока BrowserID не будет поддержан двумя-тремя провайдерами, он так и останется экспериментом.
                                0
                                Нет никакой необходимости в поддержке BrowserID для «всех email», достаточно поддержки для «всех пользователей».

                                Конкретнее, сейчас поддержка «всех email» сводится к тому, что все должны открыть себе аккаунт на browserid.org, верифицировать свой email, и тогда они смогут логиниться на сайты используя свой email. Если browserid.org при регистрации юзера будет создавать для него новый email вида «user%his.verified.email@browserid.org» с автоматическим форвардингом с него на «user@his.verified.email», то единственное отличие от текущей схемы будет в том, что юзер будет логиниться на сайты используя менее красивый email «user%his.verified.email@browserid.org» вместо «user@his.verified.email», но при этом не придётся сильно ослаблять безопасность протокола вводя новую сущность secondary authority.
                                  0
                                  А в чем разница между схемами?
                                  Вот вы видите на сайте, что какое-то сообщение оставлено powerman%powerman.name@browserid.org
                                  Вам все равно придется доверится browserid.org в том, что это тот же человек, что и powerman@powerman.name

                                  Минусы вашего предложения:
                                  1. Когда powerman.org начнет поддерживать BrowserID нативно, ваш предпочитаемый логин изменится, и не все сайты смогут корректно отработать этот переход.
                                  2. В нынешней схеме, если browserid.org завтра выключится, то у сайта будет ваш настоящий email, по которому он вышлет ваш пароль. В вашей схеме у сайта не будет вашего настоящего email, а редирект с browserid.org будет выключен.
                                  3. Большая нагрузка ляжет на browserid.org, причем пустая нагрузка — не нужная пересылка email.
                                    0
                                    Всё так. Тем не менее, в разработке таких протоколов вроде бы ключевой момент это безопасность. Более того, уже ведь есть OpenID, и BrowserID в теории должен быть более защищённым, чем OpenID, для получения конкурентного преимущества… а наличие в протоколе secondary authority сильно ослабляет безопасность, на мой взгляд.

                                    А вот в плане пользовательского интерфейса BrowserID действительно лучше OpenID. Как по мне — это отличная возможность для стартапа: реализовать ввод пользователем своего OpenID в том же стиле, что и у BrowserID. Т.е. сделать сервис, позволяющий юзеру однократно ввести свой аккаунт в gmail/соц.сетях или любой OpenID url, запоминающий эти аккаунты в браузере юзера, и в будущем позволяющий выбрать один из этих аккаунтов мышкой, ничего не набирая.
                                      0
                                      BrowserID более защищен: в финальной полностью развитой версии протокола не происходит никакого общения между сайтами без участия пользователя, только через него.

                                      Про пользовательский интерфейс: для человека нелогично воспринимать в качестве идентификатора себя URL: email в этом плане привычнее и соответствует давним традициям представления: я такой-то оттуда-то.
                              0
                              BTW, на их пивном демо-сайте не работает Signup в Opera 11.60/Linux.
                                +5
                                >Opera 11.60/Linux
                                Представляю сколько пользователей сейчас с этим мучаются.
                                  0
                                  Хабражители, пожалуйста, подскажите каким образом отметить для себя коммент, который реально вызвал «ЛОЛ», при ситуации, когда не хватает кармы, или чего-то там, для зеленой галки, и писать «Спасибо, посмеялся» не позволяет не только окружение, но и воспитание?
                                    +1
                                    Для себя — в избранное занести, благодарность можно автору в личку (от кармы она, вроде, не зависит)
                                    0
                                    Важнее не то, сколько пользователей, а то, что представляя столь глобальную браузер-ориентированную технологию они поленились проверить её работоспособность хотя бы в последних версиях пяти основных браузерах под тремя основными операционками. Учитывая, что на такой тест нужно максимум час времени, можно сделать вывод, что они сами пока не очень серьёзно воспринимают свою новую технологию.
                                  0
                                  Скажем так: не похоже, чтобы Mozilla закончила разработку этого решения.
                                  Т.е. оно в перспективе привлекательно, но многое требует доработки.

                                  Only users with full accounts can post comments. Log in, please.