LINUX.ORG.RU

Дешевая авторизация

 , browserid, , persona,


0

2

Для ъ:
Посоветуйте способ авторизации без пароля. Преимуществом будет лёгкость и дешевизна в использовании. Далее, простота в реализации.

Не хочу возиться с паролями, проверками, хешированиями, хранениями, восстановлениями, уведомлениями и т.п. Однако таки ожидается, что пользователи будут манипулировать в рамках сервиса некими суммами, поэтому некоторые требования к безопасности предъявляются.

Дабы не тормозить разработку, на начальном этапе прикрутил Mozilla Persona Auth:

Mozilla Persona - это полностью децентрализированная и безопасная система авторизации на сайтах, основанная на открытом протоколе BrowserID.

Преимущества которой, стало быть, в следующем:

  • Отсутствие необходимости локального пароля на сайте;
  • Простота в использовании;
  • Простота в реализации;
  • Отсутствие lock-in.

Не смотря на наличие в Terms of Services (TOS) пункта, обязывающего согласиться со следующим фактом:

You will not use the Services for any purpose where an accurate verification of identity has critical or life-threatening consequences or has other significant or financial consequences such as in the context of financial services, banking, education, immigration, taxes, or other government functions, or healthcare.

и следующие недостатки:

  • Не работает без JS. При том, что для остального функционала моего сайта - отключение JS не критично и для этого были приложены некоторые усилия;
  • Открывается в сраном новом окне.

Однако, при реализации функционала, позволяющего добавлять / удалять / авторизироваться, используя разные E-mail адреса, выясняется, что «Разработчики Mozilla пока не придумали, как это сделать по-человечески», поэтому предлагают мне 2 пункта на выбор:

  • Самому высылать подтверждения на E-mail адреса. Но тогда не понятно, на кой ЙУ_ мне эта Персона. Я подключал её, чтобы она взяла на себя все обязательства по верификации;
  • Вызывать это сраное окошко, которое выглядит как говно. уже на все 146% завязать функционал на JS.

Я, конечно же, включил задний, а для оправдания сего действа нагуглил статейку "BrowserID is a step in the wrong direction", основные поинты которой:

  • Фишинговые атаки: «Для простого пользователя "Mozilla Foundation [US] https://login.persona.org/sign_in" всё равно, что "Godzilla Foundation [CN] https://login.personify.cn/sign_in"»;
  • Безумно учить пользователей, что «вводить пароли в всплывающем окне - это нормально»;
  • Фейковый Logout. Авторизация в persona.org никуда не девается, после того, как вы вышли с сайта. Единственный способ по настоящему выйти - после выхода снова попытаться авторизироваться и нажать «Это не я»;
  • Пароль переспрашивается через рандомное время, что упрощает фишинговые атаки;
  • Была уязвимость, которая позволяла логиниться под кем угодно.
  • Minor Bug;
  • Здравствуйте, 2002 годы. «Клиентский JS - небезопасный канал для передачи данных». «A username/password (albeit with a 2 minute expiration period) via client-side scripting». Любая XSS атака позволит перехватить эти данные;
  • Плохо иметь один пароль для всех сервисов;
  • Persona предъявляет единственное требование к паролям - 8 символов. «password» подходит. Вас не уведомляют о том, сколько неудачных попыток авторизации было сделано;
  • Ещё всякое разное.

Кроме того, Mozilla заявляет о том, что теперь вендоры (E-mail провайдеры) не будут знать, какими сайтами ты пользуешься. Однако, для верификации требуется отправлять запрос Mozilla (пока единственный центр верификации), т.е. они таки будут знать про всех всё.

Как вариант, рассматриваю такой способ: пользователь вводит e-mail, получает одноразовую авторизационную ссылку. Занавес. Преимущества способа вижу в следующем:

  • Простота в реализации;
  • Простота в использовании;
  • Авторизация доступна всем желающим;
  • Безопасность аккаунта зависит от безопасности используемого почтового ящика, а там хоть двуфакторную авторизацию используй, хоть свой сервер поднимай, использующий биометрическую аутентификацию.

Про последний вариант. Один из пользователей в "Web-development" отписывался с примером реализации входа/регистрации путём ввода одного лишь E-mail'а.

Sense
() автор топика
Ответ на: комментарий от alix

Очень интересно. Из недостатков вижу следующее:

  • Необходимость определять хост и порт imap сервера пользователя;
  • Что делать в случае включенной multifactor auth. В этом случае ведь залогиниться по логину-паролю не получится.

Однако, если речь про корпоративный сайт, то это, на мой взгляд, просто блестящее решение:

  • Просто в реализации;
  • Просто и удобно в использовании.
Sense
() автор топика
Ответ на: комментарий от Sense

+ Из минусов: нужно уже иметь какую-то степень доверия к ресурсу, чтобы ввести на нём данные к своей почте. К ресурсу предъявляются повышенные требования к безопасности.
С другой стороны, можно очень мило делегировать обязанности по восстановлению аккаунтов и т.п. почтовому сервису. Можно даже специально запустить свой сервис выдачи мыл и для доступа к сайту проекта требовать мыло на этом сервисе.

Sense
() автор топика

О чем речь? Бл зачем я прочел эту простыню утром вторника? Что сказать вообще хотел? Хочешь — бери и делай, я разрешаю. Способ отличный, сам пару раз точно такой же порывался внедрить, но обламывало, все-таки экзотика. Но я бы пользовался, особенно если бы не надо было каждый день новую ссылку запрашивать.

trashymichael ★★★
()
Ответ на: комментарий от trashymichael

Что сказать вообще хотел?

Сам то что хотел?

особенно если бы не надо было каждый день новую ссылку запрашивать

Про что речь? Какую ссылку нужно запрашивать?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.