it-swarm-eu.dev

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?

32
Utku

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).

30
Hector

Ci sono tre problemi qui.

  1. 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.
  2. 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.
  3. 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.

23
Philipp