# Регистрация и аутентификация без email и пароля

**URL:** https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737
**Category:** Feature
**Created:** [31.Октябрь.2021 17:19:45 UTC](https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737 "2021-10-31T17:19:45Z")
**Posts on this page:** 15
**Page:** 1

<div class="post-metadata">

### Author: ![Be0](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/be0/32/238518_2.png) [@Be0](https://meta.discourse.org/u/Be0)
#### Post date: [31.Октябрь.2021 17:19:45 UTC](https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737/1 "2021-10-31T17:19:45Z")

</div>

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

У электронной почты тоже много проблем. Подобно паролям, люди обычно используют один и тот же адрес электронной почты во множестве сервисов, что создаёт риск для конфиденциальности, если адрес будет раскрыт через какой-либо сервис. Всё сложнее получить адрес электронной почты, не предоставляя персонально идентифицируемую информацию серверу электронной почты. В качестве меры против спама (и, вероятно, также для упрощения таргетированной рекламы) бесплатные сервисы электронной почты обычно требуют указывать номер телефона, который легко связать с конкретным человеком. Платные сервисы могут не требовать номер телефона, но оплатить услугу, не раскрывая персонально идентифицируемую информацию, тоже непросто, а зависимость от платной подписки на сервис электронной почты уязвима к изменениям в финансовом положении. Кроме того, сегодня надёжно самостоятельно развернуть сервер электронной почты сложно. Помимо проблем с конфиденциальностью, централизация, возникающая при повторном использовании одного аккаунта электронной почты во многих сервисах, создаёт также риск безопасности: компрометация аккаунта электронной почты приведёт к компрометации множества других аккаунтов.

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

Однофакторная аутентификация с помощью FIDO может быть очень удобной, но она уязвима к потере или уничтожению единственного токена FIDO, аналогично проблеме регистрации с паролем, но без адреса электронной почты. Чтобы решить это, я предлагаю требовать от пользователей предоставления как минимум двух факторов при регистрации — любой комбинации из FIDO, TOTP и/или пароля. Пользователи, желающие аутентификацию без электронной почты и пароля, могут просто зарегистрировать два переносных аутентификатора FIDO, например YubiKey. Пользователям можно рекомендовать (или даже требовать, особенно для администраторов) регистрировать больше двух факторов, чтобы избежать потери доступа к своим аккаунтам.

Поскольку платформенные аутентификаторы FIDO всё чаще встраиваются в устройства благодаря Windows Hello, Apple Touch ID и Face ID, а также Android, система регистрации без электронной почты может стать доступной для нетехнических пользователей, не обладающих специализированным переносным оборудованием для аутентификации, например YubiKey. Пользователи могут зарегистрироваться с помощью платформенного аутентификатора FIDO и пароля. Однофакторная аутентификация с использованием платформенного аутентификатора FIDO в такой конфигурации может работать бесшовно. Однако это создаст проблему удобства при аутентификации на новых устройствах, поскольку у пользователя не будет доступа к платформенному аутентификатору FIDO на новом устройстве, а полагаться исключительно на пароль для настройки нового устройства небезопасно. Чтобы решить это, я предлагаю рабочий процесс, аналогичный тому, как Matrix аутентифицирует новых клиентов. Пользователь может попытаться войти на новом устройстве с помощью его платформенного аутентификатора FIDO (новый фактор) и своего пароля (уже зарегистрированный фактор). Это не приведёт к входу в систему, но создаст запрос на одобрение нового аутентификатора FIDO в аккаунте. Интерфейс на новом устройстве затем перенаправит пользователя на вход с уже зарегистрированного устройства для одобрения нового устройства. Благодаря встроенным в мобильные устройства платформенным аутентификаторам FIDO это может стать практически применимым для безопасной аутентификации без специализированного переносного оборудования и без потери возможности использовать любые устройства по требованию, например общественные киоски.

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

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [31.Октябрь.2021 18:12:22 UTC](https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737/9 "2021-10-31T18:12:22Z")

</div>

> [@Be0](#):
>
> Я не думаю, что большинство людей знают, что такое менеджеры паролей.

Скорее всего, это так. Но трудно представить, что кто-то, кто будет входить в систему с помощью предложенной вами схемы, не знает, что такое менеджер паролей. Я использую менеджер паролей уже около десяти лет, у меня есть несколько ключей FIDO, я использую Google Authenticator, и я не совсем понимаю, что именно вы предлагаете.

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

Идея, впрочем, интересная. Возможно, это проще, чем я думаю.

---

<div class="post-metadata">

### Author: ![Be0](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/be0/32/238518_2.png) [@Be0](https://meta.discourse.org/u/Be0)
#### Post date: [31.Октябрь.2021 18:17:10 UTC](https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737/10 "2021-10-31T18:17:10Z")

</div>

> [@pfaffman](#):
>
> Но трудно представить, что кто-то, кто будет входить в систему с помощью предлагаемой вами системы, не знает, что такое менеджер паролей.

Любой пользователь с современным устройством, в которое встроен аутентификатор платформы FIDO, может легко воспользоваться этим. Через несколько лет это станет доступно практически каждому.

> [@pfaffman](#):
>
> Я не совсем понимаю, что вы предлагаете

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

> [@pfaffman](#):
>
> Кажется маловероятным, что такая система будет добавлена, если хотя бы несколько корпоративных клиентов не проявят к ней интерес. По моим оценкам, это потребует как минимум 50 часов работы для человека, хорошо разбирающегося в системе аутентификации, и, вероятно, вдвое больше при наличии подробных спецификаций. Некоторое время назад была попытка интеграции с Keybase, которая могла бы реализовать часть того, что вы хотите, но, насколько я знаю, дело не сдвинулось далеко.
> 
> Это, однако, интересная идея. Возможно, это проще, чем я думаю.

Я уверен, что реализация потребует значительных усилий. Думаю, самая сложная часть — это сделать дизайн пользовательского интерфейса максимально понятным. В Discourse уже есть необходимые компоненты: двухфакторная аутентификация поддерживает FIDO и TOTP.

---

<div class="post-metadata">

### Author: ![Be0](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/be0/32/238518_2.png) [@Be0](https://meta.discourse.org/u/Be0)
#### Post date: [31.Октябрь.2021 18:32:06 UTC](https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737/11 "2021-10-31T18:32:06Z")

</div>

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

---

<div class="post-metadata">

### Author: ![Be0](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/be0/32/238518_2.png) [@Be0](https://meta.discourse.org/u/Be0)
#### Post date: [01.Ноябрь.2021 02:18:46 UTC](https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737/19 "2021-11-01T02:18:46Z")

</div>

Мне интересно, что думает по этому поводу @codinghorror, учитывая его различные посты в блоге о паролях.

---

<div class="post-metadata">

### Author: ![adrelanos](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/adrelanos/32/121409_2.png) [@adrelanos](https://meta.discourse.org/u/adrelanos)
#### Post date: [26.Сентябрь.2022 14:41:37 UTC](https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737/20 "2022-09-26T14:41:37Z")

</div>

Электронная почта должна быть опциональной. Использование электронной почты становится всё менее надёжным, а в некоторых случаях и вовсе невозможным из-за олигополии крупных провайдеров электронной почты.

Теперь Gmail внезапно заблокировал мой домен.

- Даже после многолетней идеальной настройки всех механизмов безопасности электронной почты (SPF, DKIM, DMARC и др.)
  - Что я имею в виду под «идеальной»? Все инструменты тестирования и отчётности по безопасности электронной почты показывают «100% OK».
  - Домен также не был занесён в списки спама (Spamhaus и др.) в течение многих лет.

Но можно ли связаться с Gmail? Конечно…

Цитата: [Sender Contact Form - Gmail Help](https://support.google.com/mail/contact/gmail_bulk_sender_escalation)

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

Так что, скорее всего, ответ будет примерно таким: «Да, мы разобрались, но ничего не исправили; проблема на вашей стороне, но мы не поделимся примерами спама и не скажем, в чём именно проблема»… То есть, если вообще есть какая-то проблема.

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

Это не только мой опыт.

> **[After self-hosting my email for twenty-three years I have thrown in the...](https://cfenollosa.com/blog/after-self-hosting-my-email-for-twenty-three-years-i-have-thrown-in-the-towel-the-oligopoly-has-won.html)**
>
> Many companies have been trying to disrupt email by making it proprietary. So far, they have failed. Email keeps being an open protocol. Hurray? No hurray. Email is not distributed anymore. You just cannot create another first-class node of this ne

Многие другие люди писали в блогах о подобном опыте.

Эти игры усугубляют все технические сложности самостоятельной настройки собственного почтового сервера.

Не могли бы вы сделать электронную почту опциональной?

- При регистрации с адресом электронной почты: восстановление пароля будет возможно.
- При регистрации без адреса электронной почты: восстановление пароля будет невозможно.
  - Если это разрешено администратором сайта (опциональная настройка), предупредить пользователя, но разрешить регистрацию без адреса электронной почты.
  - Только имя пользователя и пароль.

Похожие темы:

- [Run Discourse without email?](https://meta.discourse.org/t/run-discourse-without-email/179015)
- [Make email optional](https://meta.discourse.org/t/make-email-optional/227971)
- Вероятно, ещё много других.

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [26.Сентябрь.2022 18:22:34 UTC](https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737/21 "2022-09-26T18:22:34Z")

</div>

Быстрое и простое решение — использовать другую систему аутентификации через [Discourse Connect](https://meta.discourse.org/t/13045?silent=true).

Моя предыдущая оценка сложности создания системы без использования электронной почты оказалась крайне неверной. Использование другого идентификатора с доменным именем вида `not-email.invalid` для таких адресов должно быть выполнимо. Думаю, что [плагин «Вход с помощью Ethereum»](https://meta.discourse.org/t/sign-in-with-ethereum-plugin/231897) может решить вашу задачу, если вы готовы потребовать от пользователей использования Ethereum, но также может подойти что-то подобное. В любом случае необходим какой-то способ установления личности пользователя.

---

<div class="post-metadata">

### Author: ![adrelanos](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/adrelanos/32/121409_2.png) [@adrelanos](https://meta.discourse.org/u/adrelanos)
#### Post date: [26.Сентябрь.2022 20:52:00 UTC](https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737/22 "2022-09-26T20:52:00Z")

</div>

> Вам действительно нужен какой-то способ подтверждения личности.

Просто имя пользователя и пароль.

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [26.Сентябрь.2022 20:56:10 UTC](https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737/23 "2022-09-26T20:56:10Z")

</div>

> [@Adrelanos](#):
>
> Просто имя пользователя и пароль.

Значит, любой человек (или любой бот) из всего интернета может зайти на ваш форум и создать бесконечное количество аккаунтов, придумав имя пользователя и пароль?

---

<div class="post-metadata">

### Author: ![adrelanos](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/adrelanos/32/121409_2.png) [@adrelanos](https://meta.discourse.org/u/adrelanos)
#### Post date: [27.Сентябрь.2022 21:46:50 UTC](https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737/24 "2022-09-27T21:46:50Z")

</div>

Да.

По моему опыту работы с различными веб-приложениями, спам-боты без особых проблем создают аккаунты Gmail и другие адреса электронной почты. На моём сайте мы также не исключаем временные одноразовые адреса электронной почты. Существуют и другие программные решения для форумов / сами форумы, которые позволяют регистрироваться без указания адреса электронной почты или без его валидации, и это также не вызвало никаких проблем, которые я мог бы заметить. Поэтому я не считаю адреса электронной почты серьёзным барьером для предотвращения наплыва ботовых аккаунтов или атак типа «отказ в обслуживании» (DOS).

Однако я понимаю, откуда у вас могут возникнуть такие опасения. Разрешение регистрации без адреса электронной почты может привести к множеству сопутствующих проблем. Что, если произойдёт массовая волна ботовых атак и/или DOS-атак, в результате которой будет создано огромное количество аккаунтов форума?

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

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

Те же самые вопросы возникнут как у пользователей, использующих электронную почту, так и у тех, кто её не использует. В рамках данного обсуждения это теоретические вопросы.

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

---

<div class="post-metadata">

### Author: ![Be0](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/be0/32/238518_2.png) [@Be0](https://meta.discourse.org/u/Be0)
#### Post date: [17.Октябрь.2022 00:43:29 UTC](https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737/25 "2022-10-17T00:43:29Z")

</div>

> [@Be](#):
>
> Однако это создаст проблему удобства использования при аутентификации на новых устройствах, поскольку у пользователей не будет доступа к платформенному аутентификатору FIDO на новом устройстве, а полагаться исключительно на пароль для настройки нового устройства было бы небезопасно. Чтобы решить эту проблему, я предлагаю рабочий процесс, аналогичный тому, как Matrix аутентифицирует новых клиентов. Пользователь может попытаться войти на новом устройстве, используя его платформенный аутентификатор FIDO (новый фактор) и свой пароль (уже зарегистрированный фактор). Это не приведет к фактическому входу в систему, но создаст запрос на одобрение нового аутентификатора FIDO в учетной записи. Затем интерфейс на новом устройстве перенаправит пользователя на вход с уже зарегистрированного устройства для одобрения нового устройства. Поскольку платформенные аутентификаторы FIDO встроены в мобильные устройства, это может стать практически удобным способом безопасной аутентификации без использования специализированного оборудования для роуминга и без потери возможности использования любых случайных устройств, таких как общественные киоски.

Похоже, что Google придумал интересное решение этой проблемы с использованием QR-кодов и Bluetooth:

[![](https://global.discourse-cdn.com/meta/original/4X/d/5/4/d54ff9542cef1007c64a9ba88a96faf6b8195f2e.jpeg "Android solutions for seamless sign-in across devices") ](https://www.youtube.com/watch?v=xghjqgj4peA)

> **[Passkeys.io – A Real-World Passkey Demo & Info Page](https://www.passkeys.io/)**
>
> Try a Realistic Passkey Demo Login and User Profile. Browse the Passkey Directory and Find Websites With Passkey Support. Learn About Device Compatibility and Technical Details.

---

<div class="post-metadata">

### Author: ![icaria36](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/icaria36/32/426431_2.png) [@icaria36](https://meta.discourse.org/u/icaria36)
#### Post date: [21.Октябрь.2022 08:07:31 UTC](https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737/26 "2022-10-21T08:07:31Z")

</div>

> [@Джей Пфаффман](#):
>
> Быстрое и простое решение — использовать другую систему аутентификации с помощью [Discourse Connect](https://meta.discourse.org/t/13045).

См. также: [Users logging with SSO, without email address](https://meta.discourse.org/t/users-logging-with-sso-without-email-address/236747)

---

<div class="post-metadata">

### Author: ![fria](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/fria/32/488762_2.png) [@fria](https://meta.discourse.org/u/fria)
#### Post date: [18.Февраль.2025 04:11:03 UTC](https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737/27 "2025-02-18T04:11:03Z")

</div>

Теперь, когда ключи доступа стали настолько распространёнными, многие сервисы предлагают регистрацию без пароля, когда вам вообще не нужно создавать пароль. Наличие пароля в принципе обходит преимущества безопасности, которые обеспечивают ключи доступа. Аналогично, использование электронной почты как метода восстановления означает, что безопасность всех ваших учётных записей зависит от безопасности вашей учётной записи электронной почты. Требование паролей и электронной почты вредит безопасности и приватности пользователей, не говоря уже о том, насколько легко создавать новые учётные записи электронной почты. По собственному опыту могу сказать, что требование электронной почты вовсе не останавливает ботов, спамящих ваш форум. Одна из основных причин, по которой сервисы исторически требовали электронную почту, заключалась в возможности восстановления учётной записи в случае забывания пароля, но с ключами доступа они хранятся в менеджере паролей и синхронизируются между устройствами. Вы даже можете добавить несколько ключей доступа к одной учётной записи, что в значительной степени устраняет проблему забывания пароля. Вот несколько примеров сайтов, реализующих регистрацию без пароля:

> **[NFL Account Sign In](https://id.nfl.com/account/sign-in)**

> **[Target : Expect More. Pay Less.](https://www.target.com/)**
>
> Shop Target online and in-store for everything from groceries and essentials to clothing and electronics. Choose contactless pickup or delivery today.

[https://app.uninbox.com/](https://app.uninbox.com/) Этот, на мой взгляд, особенно хорош, так как не требует электронной почты  
[https://www.kayak.com/](https://www.kayak.com/)

---

<div class="post-metadata">

### Author: ![Jagster](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jagster/32/192154_2.png) [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [18.Февраль.2025 07:07:48 UTC](https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737/28 "2025-02-18T07:07:48Z")

</div>

Пожалуйста, объясните это так, будто мне 80 лет.

Target предлагает регистрацию только через ключ доступа, с опцией входа по email/паролю, а Discourse требует использование email или email через SSO. Kayak (кстати, я очень не люблю это доменное имя 😏) использует только Google SSO, и Discourse уже поддерживает такую возможность.

Так что теперь открытый вопрос здесь — добавить опцию, как у Target, поскольку вариант Kayak уже есть (я бы не ограничивал регистрацию только пользователями Google, но это моё личное мнение).

Что происходит, когда пользователь Target, например, меняет iPhone на Android?

---

<div class="post-metadata">

### Author: ![fria](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/fria/32/488762_2.png) [@fria](https://meta.discourse.org/u/fria)
#### Post date: [26.Февраль.2025 22:42:44 UTC](https://meta.discourse.org/t/email-less-and-password-less-registration-authentication/207737/29 "2025-02-26T22:42:44Z")

</div>

> [@Jakke Flemming](#):
>
> Kayak (кстати, я действительно не люблю это доменное имя 😏) использует только Google SSO, и Discourse уже предлагает такую возможность.

На самом деле Kayak позволяет зарегистрироваться с помощью ключа доступа, если ввести свой адрес электронной почты. К сожалению, почта всё ещё требуется.

> [@Jakke Flemming](#):
>
> Что произойдёт, если целевой пользователь, например, перейдёт с iPhone на Android?

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