Per prendere realmente in considerazione le implicazioni di ciò, è necessario considerare l'adozione e la diffusione di tale tecnologia prima di determinare quanto aumenterà o diminuirà la vulnerabilità. In questo momento, ciò che fa è inviare un messaggio e-mail all'indirizzo e-mail registrato dell'account (o in molti casi, l'indirizzo e-mail è il nome dell'account ... che è un altro problema interessante. ..) e l'utente utilizza quindi il collegamento di autenticazione monouso per accedere alla risorsa.
Alcuni problemi che riesco a vedere:
Le persone useranno lo stesso indirizzo e-mail per la loro autenticazione.
In questo momento, sembra conveniente. È semplice, comprensibile, facile e potrebbe ridurre il carico della password. Tuttavia, con quale frequenza le persone andranno a creare UN ALTRO indirizzo e-mail? Quasi mai.
L'adozione diffusa sposta la responsabilità
Questo è qualcosa di veramente osceno, secondo me. Quindi si invia un messaggio a un account e-mail che non può utilizzare l'autenticazione basata su e-mail (o se lo fa, deve terminare da qualche parte dove esiste una forma alternativa di autenticazione) e imporre al provider di posta elettronica di onere di autenticare i tuoi utenti per te. Brillante. Facciamo in modo che THEM (concorrenti) porti i database delle password hash e salati e usino i loro database per autenticare i nostri utenti. Non hai ANCORA bisogno di una password per accedere alla risorsa? Sì. Deve finire da qualche parte.
Non mi piace. A tutti.
Sarà meno sicuro in quanto aumenta l'adozione perché focalizza il punto di errore. Potrebbe anche essere meno sicuro ora, perché hai tutte le tue uova in un paniere e non hai nemmeno il beneficio di un danno compartimentato. Non va bene.