Registrazione e autenticazione senza email e senza password

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 Mi Piace

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 Mi Piace

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 Mi Piace

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 Mi Piace

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

3 Mi Piace

L’e-mail dovrebbe essere facoltativo. L’uso dell’e-mail sta diventando sempre più inaffidabile, impossibile a causa del grande oligopolio dei provider di posta elettronica.

Ora improvvisamente gmail sta bloccando il mio nome di dominio.

  • Anche dopo aver configurato perfettamente tutta la sicurezza e-mail (SPF, DKIM, DMARC, …) per anni
  • Cosa intendo per perfetto? Tutti gli strumenti di test e reporting della sicurezza e-mail mostrano “100% OK” e
  • il nome di dominio non è stato in nessuna lista di spam (spamhouse…) per anni.

Ma puoi contattare gmail? Certo…

Citazione Sender Contact Form - Gmail Help

Utilizzeremo le informazioni fornite per indagare e migliorare i nostri sistemi di rilevamento spam e abusi. Sfortunatamente, non possiamo fornire dettagli sui nostri risultati durante o dopo l’indagine.

Quindi probabilmente la risposta sarà simile a “sì, ci abbiamo guardato, non l’abbiamo risolto, il problema è dalla tua parte ma tu non condividi alcun esempio di spam e noi non ti diciamo qual è il problema”… Cioè, se c’è un problema.

Ho comunque utilizzato quel modulo di contatto. Ci vogliono due settimane per ricevere una risposta via e-mail, ha detto il modulo alla fine. Questo rende l’e-mail praticamente inaffidabile e troppo complicata da gestire.

Non è solo la mia esperienza.

Molte altre persone hanno scritto esperienze simili.

Questi imbrogli si aggiungono a tutte le difficoltà tecniche dell’auto-ospitare il proprio server di posta elettronica.

Potresti rendere l’e-mail facoltativa?

  • Al momento dell’iscrizione con indirizzo e-mail: sarà possibile il recupero della password.
  • Al momento dell’iscrizione senza indirizzo e-mail: il recupero della password sarà impossibile.
  • Se consentito dall’amministratore del sito (impostazione opzionale), avvisa l’utente ma consenti l’iscrizione senza indirizzo e-mail.
  • Solo nome utente + password.

Argomenti simili:

1 Mi Piace

Una soluzione rapida e semplice è utilizzare un altro sistema per l’autenticazione utilizzando Discourse Connect.

La mia precedente stima di quanto sarebbe stato difficile creare un sistema senza email è ampiamente errata. Utilizzare un altro identificatore con un nome host not-email.invalid per tali email dovrebbe essere fattibile. Penso che il plugin Sign-In with Ethereum possa fare ciò che desideri, se sei disposto a far utilizzare Ethereum alle persone, ma anche qualcosa di simile potrebbe funzionare. Hai bisogno di un modo per stabilire l’identità.

Hai bisogno di un modo per stabilire l’identità.

Solo nome utente + password.

Quindi chiunque (o qualsiasi bot) su tutta Internet può venire sul tuo forum e creare un numero infinito di account inventando un nome utente e una password?

Sì.

Nella mia esperienza con varie webapp, i bot spam non hanno molti problemi a creare indirizzi Gmail e di posta elettronica. Sul mio sito, inoltre, non escludiamo gli indirizzi email temporanei usa e getta. Esistono anche altri software per forum / forum che consentono la registrazione senza un indirizzo email (o senza uno valido) e anche questo non ha causato problemi, per quanto ho potuto vedere. Quindi, non vedo gli indirizzi email come una grande barriera per evitare un’inondazione di account bot / attacchi DOS.

Ma capisco da dove potresti venire. Consentire agli utenti di registrarsi senza indirizzo email potrebbe espandersi in molti problemi di follow-up. Cosa succede se c’è un’enorme inondazione di attacchi bot e/o attacchi DOS in cui viene creato un numero pazzesco di account del forum?

In tal caso, sarebbero necessarie misure di prevenzione antispam. Ma queste non sarebbero specifiche per quelle istanze di forum in cui l’email è opzionale rispetto a quelle in cui l’email è obbligatoria.

Questo perché gli spammer oggi hanno anche accesso a molti indirizzi email creati o hackerati. Potrebbero anche utilizzare provider di posta elettronica temporanea. Oppure acquistare/rubare un nome di dominio e configurare il proprio server di posta elettronica solo allo scopo di configurazioni di forum spam.

Le stesse domande sorgerebbero da entrambi, utenti che usano/non usano l’email. Ai fini di questa discussione, domande teoriche.

  • Come visualizzare tutti gli account creati da X giorni, che hanno effettuato l’accesso meno di X minuti fa, che hanno 0 post? Probabilmente account bot. Voglio trovarli e cancellarli tutti.
  • Come aggiungere una domanda personalizzata / puzzle / captcha / qualunque cosa prima di accettare una registrazione?
  • Il pannello di amministrazione potrebbe avere un pulsante facile con cui gli amministratori possono approvare/non approvare facilmente le nuove registrazioni in grado di gestire lo spam di massa?

Sembra che Google abbia trovato una soluzione interessante per questo utilizzando codici QR e Bluetooth:

1 Mi Piace

Correlato: Users logging with SSO, without email address

1 Mi Piace

Ora che le passkey sono così diffuse, molti servizi offrono la registrazione senza password, dove non è mai necessario creare una password. Avere una password vanifica i vantaggi di sicurezza delle passkey. Allo stesso modo, utilizzare l’email come metodo di recupero significa che la sicurezza di tutti i tuoi account dipende dalla sicurezza del tuo account email. Richiedere password/email è dannoso per la sicurezza e la privacy degli utenti, per non parlare di quanto sia facile creare nuovi account email. Posso dire per esperienza che il requisito dell’email non impedisce affatto ai bot di inviare spam al tuo forum. Uno dei motivi principali per cui i servizi hanno storicamente richiesto un’email è per consentirti di recuperare il tuo account in caso di dimenticanza della password, ma con le passkey queste vengono memorizzate nel tuo gestore di password e sincronizzate su più dispositivi. Puoi persino aggiungere più passkey a un account, eliminando quasi del tutto il problema delle persone che dimenticano la password. Ecco alcuni esempi di siti che implementano la registrazione senza password:

https://app.uninbox.com/ Questo, secondo me, è particolarmente valido poiché non richiede un’email
https://www.kayak.com/

1 Mi Piace

Per favore, spiegamelo come se avessi 80 anni.

Target offre la registrazione utilizzando solo passkey con opzione email/password) e Discourse impone l’uso di email o email tramite SSO. Kayak (tra l’altro, non mi piace affatto quel nome di dominio :smirking_face:) utilizza solo Google SSO, e Discourse lo offre già.

Quindi la domanda aperta qui è se esista un’opzione simile a quella che usa Target, perché l’opzione Kayak è già presente (non limiterei la registrazione solo agli utenti Google, ma questo sono solo io).

Cosa succede quando un utente Target passa, ad esempio, da iPhone ad Android?

Kayak in realtà ti permette di registrarti con una passkey se inserisci la tua email. Sfortunatamente l’email è ancora richiesta.

Le tue passkey dovrebbero essere sincronizzate con il tuo gestore di password in modo che siano disponibili. Puoi anche aggiungere più passkey a un account in modo da poterne creare una nuova anche con il nuovo telefono. Attualmente stanno lavorando per renderle esportabili in modo da poter passare più facilmente tra i gestori di password.

1 Mi Piace