Registrierung & Authentifizierung ohne E-Mail und Passwort

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 „Gefällt mir“

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 „Gefällt mir“

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 „Gefällt mir“

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 „Gefällt mir“

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

3 „Gefällt mir“

E-Mail sollte optional sein. Die Nutzung von E-Mail wird immer unzuverlässiger und ist aufgrund des großen Oligopols der E-Mail-Anbieter unmöglich.

Jetzt blockiert Gmail plötzlich meinen Domainnamen.

  • Selbst nachdem alle E-Mail-Sicherheitsmaßnahmen (SPF, DKIM, DMARC, …) seit Jahren perfekt eingerichtet sind
    • Was meine ich mit perfekt? Alle Test- und Berichterstattungstools für E-Mail-Sicherheit zeigen “100% OK” und
    • die Domain war auch seit Jahren nicht auf Spamlisten (Spamhouse…)
  • Aber man kann Gmail kontaktieren? Sicher…

Zitat Sender Contact Form - Gmail Help

Wir werden die von Ihnen bereitgestellten Informationen verwenden, um unsere Spam- und Missbrauchserkennungssysteme zu untersuchen und zu verbessern. Leider können wir während oder nach der Untersuchung keine Details zu unseren Ergebnissen mitteilen.

Die Antwort wird also wahrscheinlich lauten: “Ja, wir haben es uns angesehen, wir haben es nicht behoben, das Problem liegt auf Ihrer Seite, aber Sie werden keine Spam-Beispiele teilen und wir sagen Ihnen nicht, was das Problem ist”… Das heißt, wenn überhaupt ein Problem besteht.

Ich habe das Kontaktformular trotzdem benutzt. Es dauert zwei Wochen, bis eine E-Mail antwortet, sagte das Formular am Ende. Das macht E-Mail ziemlich unzuverlässig und zu umständlich für die Arbeit.

Das ist nicht nur meine Erfahrung.

Viele andere Leute haben über ähnliche Erfahrungen gebloggt.

Diese Machenschaften kommen zu all den technischen Schwierigkeiten des Self-Hostings eines E-Mail-Servers hinzu.

Könnten Sie E-Mail bitte optional machen?

  • Bei der Anmeldung mit E-Mail-Adresse: Passwortwiederherstellung ist möglich.
  • Bei der Anmeldung ohne E-Mail-Adresse: Passwortwiederherstellung ist unmöglich.
    • Wenn vom Website-Administrator erlaubt (optionale Einstellung), warnen Sie den Benutzer, aber erlauben Sie die Anmeldung ohne E-Mail-Adresse.
    • Nur Benutzername + Passwort.

Ähnliche Themen:

1 „Gefällt mir“

Eine schnelle und einfache Lösung ist die Verwendung eines anderen Systems zur Authentifizierung mit Discourse Connect.

Meine frühere Einschätzung, wie schwierig es wäre, ein E-Mail-freies System zu erstellen, ist weit daneben. Die Verwendung einer anderen Kennung mit einem Hostnamen not-email.invalid für diese E-Mails sollte machbar sein. Ich denke, dass das Sign-In with Ethereum Plugin das tun könnte, was Sie wollen, wenn Sie bereit sind, Leute Ethereum benutzen zu lassen, aber etwas Ähnliches könnte auch funktionieren. Sie benötigen eine Möglichkeit, die Identität festzustellen.

Sie benötigen eine Möglichkeit, die Identität festzustellen.

Nur Benutzername + Passwort.

Kann also jeder (oder jeder Bot) im gesamten Internet in Ihr Forum kommen und unendlich viele Konten erstellen, indem er sich einen Benutzernamen und ein Passwort ausdenkt?

Ja.

Meiner Erfahrung nach mit verschiedenen Webanwendungen haben Spam-Bots kein großes Problem damit, Gmail- und andere E-Mail-Adressen zu erstellen. Auf meiner Website schließen wir auch keine temporären E-Mail-Adressen aus. Es gibt auch andere Forensoftware / Foren, die eine Anmeldung ohne (oder ohne gültige) E-Mail-Adresse erlauben, und das hat auch keine Probleme verursacht, die ich sehen konnte. Daher sehe ich E-Mail-Adressen nicht als große Hürde, um eine Flut von Bot- / DOS-Angriffskonten zu vermeiden.

Aber ich verstehe, woher Sie kommen könnten. Die Zulassung von Benutzern zur Anmeldung ohne E-Mail-Adresse könnte zu vielen Folgeproblemen führen. Was ist, wenn es eine riesige Flut von Bot-Angriffen und/oder DOS-Angriffen gibt, bei denen eine verrückte Anzahl von Forenkonto erstellt wird?

In diesem Fall wären Maßnahmen zur Spam-Vermeidung erforderlich. Diese wären jedoch nicht spezifisch für die Foreninstanzen, bei denen E-Mail optional ist, im Gegensatz zu denen, bei denen E-Mail obligatorisch ist.

Das liegt daran, dass Spammer heutzutage auch Zugriff auf viele erstellte oder gehackte E-Mail-Adressen haben. Sie könnten auch temporäre E-Mail-Anbieter nutzen. Oder eine Domain kaufen/stehlen und ihren eigenen E-Mail-Server nur für die Zwecke von spammy Foreneinrichtungen einrichten.

Die gleichen Fragen würden sich sowohl für Benutzer ergeben, die E-Mails verwenden als auch nicht verwenden. Der Einfachheit halber, theoretische Fragen.

  • Wie kann ich alle Konten anzeigen, die seit X Tagen erstellt wurden, die weniger als X Minuten eingeloggt waren und 0 Beiträge haben? Wahrscheinlich Bot-Konten. Ich möchte all diese finden und löschen.
  • Wie kann ich eine benutzerdefinierte Frage / ein Rätsel / ein Captcha / was auch immer hinzufügen, bevor eine Anmeldung akzeptiert wird?
  • Könnte das Admin-Panel bitte einen einfachen Knopf haben, mit dem Administratoren neue Anmeldungen einfach genehmigen/ablehnen können, um Massenregistrierungs-Spam zu bewältigen?

Es scheint, dass Google hierfür eine interessante Lösung mit QR-Codes und Bluetooth gefunden hat:

1 „Gefällt mir“

Verwandt: Users logging with SSO, without email address

1 „Gefällt mir“

Da Passkeys mittlerweile weit verbreitet sind, bieten viele Dienste passwortlose Anmeldungen an, bei denen Sie niemals ein Passwort erstellen müssen. Ein Passwort zu haben, umgeht die Sicherheitsvorteile von Passkeys. Ebenso bedeutet die Verwendung von E-Mail als Wiederherstellungsmethode, dass die Sicherheit all Ihrer Konten von der Sicherheit Ihres E-Mail-Kontos abhängt. Die Anforderung von Passwörtern/E-Mails ist schlecht für die Sicherheit und Privatsphäre der Benutzer, ganz zu schweigen davon, wie einfach es ist, neue E-Mail-Konten zu erstellen. Aus Erfahrung kann ich sagen, dass die E-Mail-Anforderung Bots überhaupt nicht davon abhält, Ihr Forum mit Spam zu überfluten. Einer der Hauptgründe, warum Dienste historisch eine E-Mail verlangt haben, ist, dass Sie Ihr Konto wiederherstellen können, falls Sie Ihr Passwort vergessen. Mit Passkeys werden diese jedoch in Ihrem Passwortmanager gespeichert und geräteübergreifend synchronisiert. Sie können sogar mehrere Passkeys zu einem Konto hinzufügen, was das Problem des Vergessens von Passwörtern weitgehend beseitigt. Hier sind einige Beispiele für Websites, die passwortlose Anmeldungen implementieren:

https://app.uninbox.com/ Dies ist meiner Meinung nach besonders gut, da keine E-Mail erforderlich ist
https://www.kayak.com/

1 „Gefällt mir“

Bitte erklären Sie mir das, als wäre ich 80 Jahre alt.

Target bietet die Registrierung nur mit Passkey (mit der Option E-Mail/Passwort) an, und Discourse zwingt zur Verwendung von E-Mail oder E-Mail über SSO. Kayak (ich mag diesen Domainnamen übrigens wirklich nicht :smirking_face:) verwendet nur Google SSO, und Discourse bietet das bereits an.

Die offene Frage ist also, ob es eine ähnliche Option wie bei Target gibt, da die Kayak-Option bereits vorhanden ist (ich würde die Registrierung nicht nur auf Google-Nutzer beschränken, aber das bin nur ich).

Was passiert, wenn ein Target-Nutzer beispielsweise von einem iPhone zu Android wechselt?

Kayak erlaubt es Ihnen tatsächlich, sich mit einem Passkey anzumelden, wenn Sie Ihre E-Mail-Adresse eingeben. Leider ist die E-Mail-Adresse immer noch erforderlich.

Ihre Passkeys sollten mit Ihrem Passwort-Manager synchronisiert werden, damit sie verfügbar sind. Sie können auch mehrere Passkeys zu einem Konto hinzufügen, sodass Sie einfach einen neuen mit dem neuen Telefon erstellen können. Derzeit arbeiten sie daran, sie exportierbar zu machen, damit Sie einfacher zwischen Passwort-Managern wechseln können.

1 „Gefällt mir“