Комментарии 44
Угнали почту и что мне делать?
Ничего. С таким же успехом угонят все зареганные на эту почту аккаунты или зарегаются где надо.
Я правильно понял, что я верифицирую мыло и могу просто вбивая свой ящик входить на сайт? И какую инфу обо мне будет получать сайт?
Я правильно понял, что я верифицирую мыло и могу просто вбивая свой ящик входить на сайт? И какую инфу обо мне будет получать сайт?
а как о них узнают, ну допустим ты угнал почту и откуда ты знаешь где он зареган?
Поковырявшись в почте. Многие не трут бессмысленные письма вроде «Спасибо за регистрацию на сайте N».
Значит с такой системой будут тереть…
пример — вход на сайте по логину и паролю
угнали у меня допустим почту на которую зареген акк, пока человек не додумается восстановить пароль (если он вообще додумается что на эту почту может быть зареген кто-то) я уже смогу зайти на сайт и поменять почту
следовательно утеря почты ставит под угрозу мой аккаунт, но не полностью
пример — вход на сайте по логину и паролю
угнали у меня допустим почту на которую зареген акк, пока человек не додумается восстановить пароль (если он вообще додумается что на эту почту может быть зареген кто-то) я уже смогу зайти на сайт и поменять почту
следовательно утеря почты ставит под угрозу мой аккаунт, но не полностью
Почту защитить куда проще чем кучу аккаунтов на сотнях сайтов. У того же gmail'а есть очень удобная и надежная двухфакторная аутентификация.
Угнали ноут\мобилу, что мне делать?
Привязывать email к мобильному телефону. В случае угона — восстанавливать доступ с помощью него. Вероятность угона и емайла и телефона ну крайне низкая.
НЛО прилетело и опубликовало эту надпись здесь
Охуенно. Надеюсь это приведет к концу зоопарка всяких авторизовалок через твиттер-фейсбук-мэйлру-вконтакле, которые следят за посещенными сайтами
Логин/пароль как-то привычнее, по крайней мере, для меня.
вот именно, как не прижился openid так и это пока только утопия
OpenID не прижился потому, что это никому не понятно. А Facebook Login и прочие прижились.
не путайте openID и oAuth!
facebook, vkontakte — oAuth — прижился
а openID — нет
facebook, vkontakte — oAuth — прижился
а openID — нет
Я ничего не путаю. Пользователю пофиг как технология называется: oAuth или xAuth. Вот он видит Login with какой-то OpenID или Login with Facebook. Нетрудно догадаться, чем он охотнее воспользуется.
так вы уж определить FaceBook логин (oAuth) или OpenID — для меня это разные технологии
авторизация и аутентификация — разные вещи, сколько уже можно объяснять
авторизация и аутентификация — разные вещи, сколько уже можно объяснять
Я ведь совсем про технологии. Плевать как устроено. Важно как для пользователя выглядит. OpenID — очень крутая идея, только вот никто не понял, что это. Логин через социалку работает точно также, только всем понятно, потому что в Фейсбуке/Вконтакте у всех есть учётка.
Я даже уверен, что в Фейсбуке вдохновились темой с OpenID.
НЛО прилетело и опубликовало эту надпись здесь
Вы, бесспорно, правы, но… любой «трешовый» сайт, который при заходе на него через «Facebook login» спрашивает доступ к контактам, даже не смотря на то, что у меня единственный фейковый аккаунт, не получает доступа.
Когда «не трешовый» сайт просит авторизацию, то пускаю его на Google. И если он просит доступ к контактам — он также отлетает через Deny.
Людям не пояснили вообще ничего и они этого ждут — это факт.
Когда «не трешовый» сайт просит авторизацию, то пускаю его на Google. И если он просит доступ к контактам — он также отлетает через Deny.
Людям не пояснили вообще ничего и они этого ждут — это факт.
Проглядев спеку возникает несколько вопросов.
Для параноиков по большому счёту ничего не меняется. Раньше мы поднимали свои OpenID-сервера на своих доменах/серверах, чтобы во-первых никакие внешние провайдеры OpenID не знали на какие сайты мы логинимся, и во-вторых чтобы внешний провайдер не предоставил доступ (нечаянно/хакеры/большой брат) на эти сайты под нашим аккаунтом никому кроме нас. С BrowserID первая проблема решена частично (внешние сервисы assersion verification?!), вторая проблема не решена (и даже усугублена существованием secondary authority), плюс добавилась третья потенциальная проблема с сертификатами в общем браузере. А решение прежнее — поднять свой провайдер BrowserID на своём домене/сервере.
Возможно я что-то упускаю из виду, но пока всё выглядит так: BrowserID в плане безопасности скорее хуже OpenID, а в плане пользовательского интерфейса удобнее тем, что вместо необходимости набирать свой url-идентификатор OpenID можно мышкой выбрать свой email-идентификатор BrowserID. И что-то мне подсказывает, что используя те же технологии HTML5, которые использует BrowserID, можно реализовать выбор мышкой своего идентификатора и для OpenID.
- Ключи/сертификаты хранятся в браузере. Как они туда попадают понятно. А как их оттуда удалять? Как быть в ситуации, когда домашним компом и, соответственно, браузером пользуется несколько человек? Как быть с браузерами в публичных местах вроде инет-кафе?
- Ключевое преимущество перед 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.
3. Мне кажется, понятно, зачем нужен secondary authority. Никто не будет внедрять BrowserID в качестве способа авторизации, если не все email будут поддерживать этот метод (и скажем прямо — пока никто не поддерживает). Благодаря browserid.org все email будут работать сразу. А поддержка провайдеров email этого протокола только будет означать распределение нагрузки и повышение безопасности. Сравните с openid/oauth, которые требуют обязательной поддержки со стороны провайдера.
Но, считаю, пока BrowserID не будет поддержан двумя-тремя провайдерами, он так и останется экспериментом.
Но, считаю, пока BrowserID не будет поддержан двумя-тремя провайдерами, он так и останется экспериментом.
Нет никакой необходимости в поддержке 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.
Конкретнее, сейчас поддержка «всех 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.
А в чем разница между схемами?
Вот вы видите на сайте, что какое-то сообщение оставлено 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.
Вот вы видите на сайте, что какое-то сообщение оставлено 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.
Всё так. Тем не менее, в разработке таких протоколов вроде бы ключевой момент это безопасность. Более того, уже ведь есть OpenID, и BrowserID в теории должен быть более защищённым, чем OpenID, для получения конкурентного преимущества… а наличие в протоколе secondary authority сильно ослабляет безопасность, на мой взгляд.
А вот в плане пользовательского интерфейса BrowserID действительно лучше OpenID. Как по мне — это отличная возможность для стартапа: реализовать ввод пользователем своего OpenID в том же стиле, что и у BrowserID. Т.е. сделать сервис, позволяющий юзеру однократно ввести свой аккаунт в gmail/соц.сетях или любой OpenID url, запоминающий эти аккаунты в браузере юзера, и в будущем позволяющий выбрать один из этих аккаунтов мышкой, ничего не набирая.
А вот в плане пользовательского интерфейса BrowserID действительно лучше OpenID. Как по мне — это отличная возможность для стартапа: реализовать ввод пользователем своего OpenID в том же стиле, что и у BrowserID. Т.е. сделать сервис, позволяющий юзеру однократно ввести свой аккаунт в gmail/соц.сетях или любой OpenID url, запоминающий эти аккаунты в браузере юзера, и в будущем позволяющий выбрать один из этих аккаунтов мышкой, ничего не набирая.
BrowserID более защищен: в финальной полностью развитой версии протокола не происходит никакого общения между сайтами без участия пользователя, только через него.
Про пользовательский интерфейс: для человека нелогично воспринимать в качестве идентификатора себя URL: email в этом плане привычнее и соответствует давним традициям представления: я такой-то оттуда-то.
Про пользовательский интерфейс: для человека нелогично воспринимать в качестве идентификатора себя URL: email в этом плане привычнее и соответствует давним традициям представления: я такой-то оттуда-то.
BTW, на их пивном демо-сайте не работает Signup в Opera 11.60/Linux.
>Opera 11.60/Linux
Представляю сколько пользователей сейчас с этим мучаются.
Представляю сколько пользователей сейчас с этим мучаются.
Хабражители, пожалуйста, подскажите каким образом отметить для себя коммент, который реально вызвал «ЛОЛ», при ситуации, когда не хватает кармы, или чего-то там, для зеленой галки, и писать «Спасибо, посмеялся» не позволяет не только окружение, но и воспитание?
Важнее не то, сколько пользователей, а то, что представляя столь глобальную браузер-ориентированную технологию они поленились проверить её работоспособность хотя бы в последних версиях пяти основных браузерах под тремя основными операционками. Учитывая, что на такой тест нужно максимум час времени, можно сделать вывод, что они сами пока не очень серьёзно воспринимают свою новую технологию.
Скажем так: не похоже, чтобы Mozilla закончила разработку этого решения.
Т.е. оно в перспективе привлекательно, но многое требует доработки.
Т.е. оно в перспективе привлекательно, но многое требует доработки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
BrowserID: почтовый адрес как ID пользователя