È possibile, ma richiede un attacco relativamente sofisticato. L'e-mail è generalmente insicura. Esistono protocolli sicuri per lo scambio di e-mail, ma in realtà pochissimi server lo utilizzano.

Se l'attaccante è in grado di eseguire ciò che è noto come un uomo nell'attacco centrale, potrebbe cambiare qualsiasi cosa volesse riguardo all'e-mail. Un uomo nell'attacco di mezzo richiede di avere il controllo su parte del percorso della posta elettronica dal mittente al destinatario. Questo potrebbe essere il server di posta di invio o di ricezione, il client di posta elettronica dell'utente o qualsiasi router Internet che l'e-mail riesce a trasmettere lungo il suo percorso.

Se l'attaccante può mettersi in mezzo, è banale da regolare, ma è relativamente difficile entrare nel mezzo a meno che non siano un hacker relativamente affermato con una discreta quantità di risorse a loro disposizione.

Nel tuo caso, la contromisura più semplice è l'uso di un link basato su HTTPS. Se si utilizza SSL e l'utente si preoccupa di verificare che l'URL corrisponda al proprio sito, lo scenario di attacco non funziona. Potresti anche dire loro il dominio a cui il link andrà quando scelgono di reimpostare la password, in questo modo sanno se è valida. Questa è probabilmente la soluzione più semplice.

La possibilità che descrivi esiste; come altri hanno notato, è un "uomo in mezzo all'attacco".

Per ostacolarlo, è necessario un ulteriore segreto che è non inviato via e-mail, ad esempio (un brutto segreto come è) una chiave cookie. Puoi chiedere all'utente di reimpostare la password utilizzando lo stesso computer e browser utilizzato per inviare il comando "Voglio reimpostare la mia password".

Quindi, l'attaccante non sarà in grado di inviare il cookie appropriato, poiché il suo dominio è diverso da quello originale, il browser non gli avrà detto il valore appropriato del cookie da utilizzare.

Una possibilità più rigida è di richiedere all'utente di inserire nella pagina "Reimpostazione password", senza chiuderla , un codice che viene inviato tramite e-mail. L'email a quel punto non contiene nemmeno un link. L'hacker conosce il codice, ma non ha il controllo sulla finestra del browser aperta. La finestra può contenere un segreto nascosto che il server sta "dicendo" a se stesso, o un cookie (che è fondamentalmente la stessa cosa). Per evitare l'uso di informazioni persistenti, il server potrebbe archiviare nella pagina una stringa casuale e inviare l'hash della stringa casuale con un salt segreto. L'utente compilerà quindi un modulo che ha entrambi i valori (uno nascosto, uno copiato dall'email). Il server esegue il hash del codice con il suo sale segreto. Se le due stringhe sono uguali, la modifica è approvata. Per evitare "attacchi ripetuti" in questo caso (ad esempio, riutilizzo di una coppia di challenge / hash nota), il controllo potrebbe includere il nome utente e un timestamp:

form
    username    hidden (e.g. "lserni")
    timestamp   hidden (e.g. 20140108131005)
    hash        hidden (e.g. "e2961ca083b4393690ec74b93d3c4b32")
    code        input

L'utente riceve il codice "123456", a caso tra 100.000 e 999999. C'è una possibilità in circa novecentomila di indovinarlo con successo. Il server concatena SERVERSECRETPASSWORD.lserni.20140108131005.123456 e verifica che lo hash su e2961ca083b4393690ec74b93d3c4b32 .

L'attaccante può indovinare il timestamp, ma non ha accesso all'hash. Conoscere un hash e il codice corrispondente funzionerà solo con il nome utente corretto, e solo fino alla differenza tra il timestamp memorizzato, che non può essere modificato, e il wall clock non diventerà troppo grande, a quel punto il server offrirà per inviare un'altra email.

Un possibile problema (inevitabile)

D'altra parte, se l'utente malintenzionato ha il controllo dell'email, può avviare personalmente un recupero della password e ottenere il pieno accesso alla risorsa almeno una volta. Per evitare questo, dovrebbero essere fornite alcune altre informazioni (ad esempio una "domanda segreta") per avviare la reimpostazione della password. Inoltre, un avviso in caso di autenticazione non riuscita dovrebbe essere rilasciato all'utente, in modo che venga messo a conoscenza del problema ("Password errata. Ricorda che hai cambiato la password ieri alle 17:23 da IP 1.2.3.4 Se non l'hai fatto, tieni presente che ... ");

Un altro possibile problema

Su alcuni sistemi, ti sarà permesso di chiedere al server di " ricordarti ". Il server lo farà emettendo un cookie che è, sotto ogni aspetto, una autenticazione debole e potrebbe non essere più connesso alla password.

Una modifica della password dovrebbe invalidare tutti questi cookie , altrimenti l'attaccante può:   - prendere il controllo della posta elettronica   - avviare una reimpostazione della password   - intercetta il codice di reimpostazione della password   - cancella l'email con la reimpostazione della password   - cambia la password   - chiedi al server "Ricordami" e ottieni un cookie "Get Home Free"   - profitto   - l'utente scoprirà di non essere in grado di accedere   - cambierà la password e ricollegherà   - l'utente malintenzionato ancora potrà accedere con il suo cookie.

Un modo per farlo è impostare il cookie su una stringa casuale più l'hash di un server segreto, la stringa casuale, il nome utente e l'hash della password dell'utente nel database. Una modifica della password annullerà automaticamente tutti i cookie di autenticazione esistenti per quell'utente.

TL; DR : Sì. L'e-mail standard non crittografata è approssimativamente sicura quanto un messaggio scarabocchiato sul retro di una cartolina.

Risposta più lunga: Questo è del tutto possibile se l'attaccante ha i privilegi di amministratore almeno in uno dei seguenti:

1. I server di posta in cui viaggia il messaggio (apri un messaggio e-mail, seleziona "intestazioni complete" in qualsiasi client di posta che usi, ogni riga Received: from [foo] by [bar] indica un server di posta che ha attraversato questo messaggio). Se disponi di privilegi di amministratore per un server di posta, puoi accedere alla sua coda, sospendere un messaggio in coda e modificare il messaggio prima di inviarlo a modo suo.

2. Tutti i router TCP / IP che il messaggio ha attraversato. In questo caso, l'autore dell'attacco può teoricamente indirizzare tutto il traffico SMTP a un server di inoltro locale che fungerà da proxy trasparente, ma tagga e mantiene specifici messaggi in una coda che l'autore dell'attacco deve modificare prima di inviarlo. Ingannevole, ma fattibile.

NOTA : il secondo metodo può a volte essere prevenuto usando smtp-over-ssl, ma questa pratica non è così comune come dovrebbe essere e smtps o smtp / tls funziona solo quando entrambi lati * lo supportano; Il primo metodo può non essere prevenuto crittografando le trasmissioni perché l'attacco avviene su un checkpoint legittimo (se sovvertito).

Ciò che vorrebbe lavorare contro entrambi i vettori di attacco sarebbe utilizzare una coppia di chiavi pubblica / privata per firmare il messaggio, ma ciò richiederebbe al destinatario di avere una copia della tua chiave pubblica, che può essere qualcosa di un problema di pollo e uova.

Puoi proteggere da questo tipo di attacco usando SMIME o DKIM. Entrambe le tecnologie verificano l'intestazione del messaggio e DKIM protegge facoltativamente il corpo del messaggio (o i primi caratteri X in esso contenuti).

DKIM è una chiave pubblica che viene archiviata in DNS e il tuo amministratore di posta elettronica "firma" il messaggio e lo timbra nell'intestazione. Ulteriori informazioni su DKIM qui: link

Affidarsi a DKIM significa che l'utente finale deve fidarsi del proprio amministratore di posta elettronica per non modificare il messaggio. Esistono pacchetti software lato client DKIM che verificano DKIM, ma non sono ampiamente utilizzati (AFAIK).