L'e-mail nei link di accesso è una cattiva pratica?
Nella mia applicazione Spring, stavo programmando di rimuovere le password dal processo di autenticazione inviando un "link di accesso magico" all'indirizzo e-mail di un utente. Tuttavia, in questa domanda Rob Winch (responsabile di Spring Security) dice quanto segue:
Fai attenzione a sapere cosa stai facendo in termini di consentire l'accesso da un collegamento all'interno di un'e-mail. SMTP non è un protocollo sicuro e quindi è in genere male fare affidamento su qualcuno che ha una e-mail come forma di autenticazione.
È davvero così? In tal caso, come è più sicuro l'invio di un collegamento per la reimpostazione della password? L'accesso utilizzando un collegamento magico non equivale a inviare un collegamento magico per ripristinare una password?
Un collegamento magico da solo non è necessariamente negativo. Un valore del tutto casuale a 512 bit non sarà più facile da indovinare di una chiave privata a 512 bit. In generale si considera buona pratica farli scadere dopo un ragionevole lasso di tempo. Un buon approccio, che evita anche di dover archiviare le voci del database, è quello di incorporare i dati del token nell'URL e firmarli con una chiave privata. Cioè.
site.com/login?type=login&user=[username]&expires=[datetime]&sig=[signature of other parameters].
Tuttavia, l'e-mail come meccanismo di trasmissione non è sicura.
Per impostazione predefinita, SMTP offre pochissima protezione contro l'intercettazione. Il traffico può essere crittografato tra server ma non ci sono garanzie. Anche con la crittografia è ancora spesso possibile gestire la connessione nel mezzo (la crittografia non è la stessa dell'autenticazione).
In tal caso, come è più sicuro l'invio di un collegamento per la reimpostazione della password?
Non lo è. Questo è il motivo per cui diversi servizi richiedono ulteriori prove prima di inviare il link (o dopo averlo fatto clic).
Ci sono tre problemi qui.
- Come scrive la documentazione, l'e-mail non è un protocollo sicuro. Le e-mail sono stordite in chiaro sui server di posta. La crittografia tra server e tra server e client è facoltativa e al di fuori del tuo controllo. E molto probabilmente non ci si trova in uno scenario in cui è possibile utilizzare nessuno dei sistemi di crittografia end-to-end opzionali che le persone costruiscono sulla posta elettronica (PGP, S/MIME ecc.). Quindi non puoi garantire che nessuno tranne il destinatario previsto vedrà l'e-mail in chiaro.
- I segreti non appartengono agli URL. Gli URL vengono visualizzati nelle cronologie dei browser, nelle cache dei proxy, nei registri dei server e in molti altri luoghi in cui non si desidera visualizzare informazioni segrete.
- Gli utenti sanno come funzionano le password. Non è stato facile, ma dopo una lunga lotta abbiamo finalmente capito nella testa di tutti che le password devono essere mantenute segrete. Con il tuo sistema, gli utenti potrebbero non essere a conoscenza di qual è il segreto che è rilevante per l'autenticazione con il tuo servizio. Ciò li rende probabilmente in grado di gestire in modo errato tali informazioni e suscettibili agli attacchi di ingegneria sociale.
If invii i link con un token di accesso segreto con e-mail, quindi dovrebbero essere monouso e scadere piuttosto rapidamente.