メール・パスワード不要の登録と認証

The insecurity and usability problems of passwords are well known. Passwords are something you know, so they are vulnerable to forgetting, which happens often. Thus, email is widely used as a backup to reset passwords.

Email has a lot of problems too. Similar to passwords, people typically reuse the same email address across lots of services, creating a privacy risk if the email is discovered from the service. It is increasingly difficult to get an email address without giving personally identifiable information to the email server. As a deterrent against spam (and probably also because it makes it easier to target ads at users), free email services typically require providing a phone number which is easy to associate with a particular person. Paid email services might not require a phone number, but paying for a service without personally identifiable information is difficult as well, and relying on paid email service subscription is vulnerable to changes in financial circumstances. Also, it’s difficult to reliably self host an email server today. In addition to the privacy issues, the centralization created by reusing an email account across many services also creates a security risk because a compromise of the email account would compromise lots of other accounts.

Nowadays, we don’t need passwords nor emails to register or authenticate to a service. Discourse already supports FIDO and TOTP, but it still requires a password and email address to register and authenticate. It would be great if Discourse made passwords and emails optional in favor of FIDO and TOTP.

One factor authentication with FIDO can be really convenient, but it is vulnerable to loss or destruction of the single FIDO token, similar to the issue of registering with a password but no email address. To resolve this, I propose that users would be required to provide at least two factors to register, which could be any combination of FIDO, TOTP, and/or password. Users who want emailless & passwordless authentication could simply register two FIDO roaming authenticators like Yubikeys. Users could be advised (or potentially required, especially for administrators) to register more than the minimum of two factors to avoid losing access to their accounts.

As FIDO platform authenticators are being built into more and more devices these days with Windows Hello, Apple Touch & Face ID, and Android, this email-less registration system could be usable by nontechnical users who do not own specialized roaming authenticator hardware like a Yubikey. Users could register with the FIDO platform authenticator plus a password. One factor authentication with the FIDO platform authenticator could work seamlessly with such a setup. However, this would create a usability problem for authentication on new devices because users wouldn’t have the FIDO platform authenticator available on a new device and relying solely on the password to setup a new device wouldn’t be secure. To resolve this, I propose a workflow similar to how Matrix authenticates new clients. The user could try to login on a new device with that device’s FIDO platform authenticator (a new factor) and their password (an already registered factor). This would not actually log in, but it would create a request to approve the new FIDO authenticator in the account. The UI on the new device would then direct the user to log in on a device they already have registered to approve the new device. With FIDO platform authenticators built into mobile devices, this could be practically usable for secure authentication without specialized roaming authenticator hardware or sacrificing the ability to use any ad-hoc device like a public kiosk.

I just came up with this anonymous registration & authentication system yesterday after receiving my Yubikeys. I am not aware of any systems which implement this. I would love to see a mature and already widely deployed web application such as Discourse pioneer a future without email or other personally identifiable information being required to use the Internet.

「いいね!」 3

That’s likely true. But it’s hard to imagine that anyone who would log in with the system that you propose don’t know what a password manager is. I’ve been using a password manager for a decade or so, have multiple fido keys, use Google authenticator, and don’t quite understand what you propose.

It seems improbable that such a system will be added unless at least a few enterprise customers want it. I think it’s on the order of at least 50 hours work for someone who knows a lot about the authentication system, and likely twice that with proper specs. There was an attempt a while ago to integrate with keybase, which could do some of what you want, but I don’t think it got very far.

It’s an interesting idea,though. Maybe it’s easier than I think.

「いいね!」 1

Anyone with a recent device that has a FIDO platform authenticator built in could use this quite easily. In a few more years this could be just about anyone.

I said it in the title: make email optional. Making passwords optional would be great too.

I’m sure it would take a decent amount of work to implement. I think most of the hard part would be getting the UX design really clear. Discourse already has the building blocks in place with 2FA supporting FIDO and TOTP.

「いいね!」 1

A small, first step towards implementing this could be adding the UI for registering FIDO and TOTP to the registration UI so it doesn’t need to be an extra step in the preferences after logging in for the first time. Later, the UI design could be improved further to make email and password optional.

「いいね!」 1

I’m curious about @codinghorror’s thoughts on this considering his various blog posts about passwords.

「いいね!」 3

E-mail はオプションにすべきです。E-mail はますます信頼性がなくなり、大手 E-mail プロバイダーの寡占により不可能になりつつあります。

今、突然 gmail が私のドメイン名をブロックしています。

  • 長年、すべての E-mail セキュリティ (SPF、DKIM、DMARC など) を完璧に設定した後でも
  • 完璧とはどういう意味ですか?すべての E-mail セキュリティテストおよびレポートツールは「100% OK」と表示されており、
  • ドメイン名は長年スパムリスト (spamhouse など) に入っていませんでした。

しかし、gmail に連絡できるのですか?もちろん…

Sender Contact Form - Gmail Help を引用

提供された情報を使用して、スパムおよび不正行為の検出システムを調査および改善します。残念ながら、調査中または調査後に、その結果に関する詳細を提供することはできません。

したがって、回答は「ええ、調べましたが、修正しませんでした。問題はあなたの側にあるのですが、スパムの例を共有していただけず、問題が何であるかを教えていただけません」のようになる可能性が高いです。それは、そもそも問題があった場合ですが。

とにかく、その連絡フォームを使用しました。返信に 2 週間かかると、フォームの最後に記載されていました。これは E-mail を事実上信頼できなくし、扱いにくくします。

これは私の経験だけではありません。

他の多くの人々も同様の経験についてブログを書いています。

これらのごまかしは、E-mail サーバーのセルフホスティングに関するすべての技術的な困難に加えて発生します。

E-mail をオプションにしていただけませんか?

  • E-mail アドレスでサインアップする場合: パスワードの復旧が可能になります。
  • E-mail アドレスなしでサインアップする場合: パスワードの復旧は不可能になります。
  • サイト管理者が許可する場合 (オプション設定)、ユーザーに警告しますが、E-mail アドレスなしでのサインアップを許可します。
  • ユーザー名 + パスワードのみ。

同様のトピック:

「いいね!」 1

簡単な解決策は、Discourse Connect を使用して別の認証システムを利用することです。

メールを使わないシステムを作成することの難しさについての私の以前の見積もりは、大きく外れていました。それらのメールには not-email.invalid ホスト名を持つ別の識別子を使用すれば、実現可能でしょう。Sign-In with Ethereum プラグイン は、Ethereum の使用をユーザーに求めるのであれば、お望みのことを達成できるかもしれませんが、同様のものが機能する可能性もあります。本人確認の方法は必要です。

ユーザー名とパスワードだけで本人確認をする方法が必要です。

ユーザー名とパスワードのみ。

では、インターネット上の誰でも(またはボットでも)あなたのフォーラムに来て、ユーザー名とパスワードを適当に決めるだけで無限にアカウントを作成できるということですか?

はい。

様々なWebアプリケーションでの経験から、スパムボットはGmailなどのEメールアドレスを作成することにあまり問題はありません。私のサイトでも、一時的な使い捨てEメールアドレスを除外していません。また、Eメールアドレスなし(または有効でないEメールアドレス)でサインアップできるフォーラムソフトウェア/フォーラムもいくつかありますが、それも問題を引き起こしたことはありませんでした。そのため、Eメールアドレスはボット/DoS攻撃アカウントの洪水を防ぐための障壁とはあまり考えていません。

しかし、あなたの懸念は理解できます。ユーザーがEメールアドレスなしでサインアップできるようにすると、多くのフォローアップ問題につながる可能性があります。もし、とんでもない数のフォーラムアカウントが作成されるような、大規模なボット攻撃やDoS攻撃が発生したらどうなるでしょうか?

その場合、スパム対策が必要になります。しかし、これらはEメールが任意であるフォーラムインスタンスと、Eメールが必須であるインスタンスに特化したものではありません。

なぜなら、スパマーは現在、作成済みまたはハッキングされた多くのEメールアドレスにアクセスできるからです。また、一時的なEメールプロバイダーを使用したり、ドメイン名を購入/盗んで、スパム目的のフォーラム設定用に独自のEメールサーバーをセットアップしたりすることもできます。

Eメールを使用するユーザーと使用しないユーザーの両方から、同じような質問が生じるでしょう。この議論のために、理論的な質問です。

  • X日以降に作成され、X分未満しかログインしておらず、投稿が0件のアカウントをすべて表示するにはどうすればよいですか?おそらくボットアカウントでしょう。これらをすべて見つけて削除したいです。
  • サインアップを承認する前に、カスタム質問/パズル/キャプチャなどを追加するにはどうすればよいですか?
  • 管理パネルに、管理者が大量登録スパムに対応できる新規サインアップの承認/非承認を簡単に行えるボタンを追加することは可能でしょうか?

Googleはこの問題に対して、QRコードとBluetoothを使用した興味深いソリューションを考案したようです。

「いいね!」 1

関連記事: Users logging with SSO, without email address

「いいね!」 1

パスキーが普及し、多くのサービスでパスワードを作成する必要のないパスワードレスサインアップが提供されています。パスワードを持つこと自体が、パスキーのセキュリティ上の利点を損ないます。同様に、メールをリカバリ方法として使用することは、すべてのアカウントのセキュリティがメールアカウントのセキュリティに依存することを意味します。パスワード/メールを要求することは、ユーザーのセキュリティとプライバシーにとって悪影響であり、新しいメールアカウントの作成がいかに簡単であるかは言うまでもありません。経験上、メール要件はボットがフォーラムにスパムを送信するのをまったく止められないと言えます。サービスが歴史的にメールを要求してきた主な理由の1つは、パスワードを忘れた場合にアカウントをリカバリできるようにするためですが、パスキーはパスワードマネージャーに保存され、デバイス間で同期されます。アカウントに複数のパスキーを追加することもでき、パスワードを忘れるという問題をほぼ解消できます。パスワードレスサインアップを実装しているサイトの例をいくつか紹介します。

https://app.uninbox.com/ このサイトは特に優れていると思います。メールを必要としないからです。
https://www.kayak.com/

「いいね!」 1

80歳の方にもわかるように説明してください。

Targetではパスキーのみ(メール/パスワードオプションあり)で登録できますが、DiscourseではメールまたはSSO経由のメールを使用する必要があります。Kayak(ちなみに、そのドメイン名は本当に嫌いです :smirking_face:)はGoogle SSOのみを使用しており、Discourseにはすでにその機能があります。

したがって、Targetが使用しているようなオプションがここにあるのか、という疑問が残ります。Kayakのオプションはすでに存在しますが(Googleユーザーのみに登録を限定したくはありませんが、それは私個人の意見です)。

TargetのユーザーがiPhoneからAndroidに変更した場合、どうなりますか?

Kayakは、メールアドレスを入力するとパスキーでサインアップできます。残念ながら、メールアドレスは依然として必要です。

パスキーはパスワードマネージャーに同期されるため、利用可能になります。また、アカウントに複数のパスキーを追加できるため、新しい電話で新しいパスキーを作成することもできます。現在、パスキーをエクスポート可能にする作業が行われており、パスワードマネージャー間での移行がより容易になります。

「いいね!」 1