Quanto è sicuro lo schema di login "senza password"?

Il meccanismo di protezione nell'utilizzo di una password quando si parla di nome utente + password è quello di fornire l'autenticazione. Se è sufficiente dipende dal modello di minaccia.

Quando si utilizza uno "schema senza password" come descritto, si sposta l'autenticazione iniziale sull'account di posta elettronica con cui è stato creato l'account. L'invio di un collegamento all'account di posta fornisce possibili vettori di attacco, ma se li ignoriamo e ci concentriamo esclusivamente sul meccanismo di utilizzo di un collegamento con un token di sessione, può essere un modo valido per fornire l'autenticazione. In linea di principio, stai utilizzando l'account di posta elettronica per la federazione dell'identità, vale a dire che tu come utente confidi nel tuo provider di posta e la tua consapevolezza sull'utilizzo della posta quando utilizzi uno "schema senza password".

Poni la domanda se lo "schema senza password" sia più vulnerabile al dirottamento dell'account di posta. Poiché l'account di posta è l'unico mezzo per fornire identità e autenticazione, è più vulnerabile al dirottamento dell'account tramite il provider di posta che a uno schema in cui è possibile fornire un nome utente + una password. Tuttavia, la username + password non è un punto vulnerabile nel modello per l'account del sito web.

La tua domanda per stabilire se si tratta di un punto debole, dipende dal fatto che l'utente fornisca un mezzo sicuro per l'utilizzo dell'account di posta. L'obiettivo dell'accesso viene rimosso dal sito Web e l'utente attribuisce fiducia al provider di posta e allo stabilimento di sessione tramite un collegamento con un token di sessione inviato (in base al modello di minaccia e alle possibilità) una posta crittografata o sicura.

Rendere migliore uno schema come lo "schema senza password" potrebbe essere quello di introdurre un componente a due fattori. Se ritieni che il tuo collegamento con un token di sessione sia un fattore, puoi introdurre un meccanismo di convalida fuori banda, come Google Authenticator, FIDO U2F o un concetto simile, ad esempio chiavi stampate dal sito web. Ciò potrebbe rafforzare la sicurezza, ma non renderebbe l'esperienza più semplice.

La maggior parte dei siti web che utilizzano una combinazione di nome utente e password standard consentono di reimpostare la password tramite un collegamento e-mail *, quindi in pratica proteggere l'account e-mail di un utente è fondamentale per la sicurezza sul Web.

Lo schema di Medium è molto simile all'utilizzo di Google (o di un altro provider di posta elettronica) in uno schema di OAuth: si spinge la responsabilità di proteggere l'account sull'altra parte. Questo introduce un singolo punto di errore, ma consente anche all'utente di fare affidamento su Google (o chiunque) anziché su una moltitudine di piccole imprese, che non hanno le stesse competenze tecniche o risorse di monitoraggio della sicurezza attive.

Una svolta dai sistemi basati su e-mail che ho visto è che tendono a utilizzare sessioni permanenti o di lunga durata. Un sito Web che utilizza OAuth può disconnettersi ogni 30 giorni ed è facile accedere nuovamente (è sufficiente fare clic sul pulsante, poiché probabilmente si è già stati autorizzati con il proprio provider), ma si è passati alla posta elettronica per trovare il messaggio giusto e fare clic è sufficiente una barriera, in particolare sui dispositivi mobili, che non sembrano disconnettere automaticamente gli utenti con frequenza semantica. Ciò a sua volta rende molto più facile per qualcuno che una volta ha ottenuto l'accesso a mantenere tale accesso.

* La reimpostazione della password dà l'avviso all'utente dell'attacco, tuttavia, la prossima volta che tentano di accedere.