Es posible, pero requiere un ataque relativamente sofisticado. El correo electrónico es generalmente inseguro. Existen protocolos seguros para el intercambio de correo electrónico, pero muy pocos servidores lo utilizan.

Si el atacante es capaz de ejecutar lo que se conoce como un hombre en el ataque central, podrían cambiar lo que quisieran sobre el correo electrónico. Un hombre en el ataque central requiere que tengan control sobre alguna parte de la ruta del correo electrónico desde el remitente hasta el destinatario. Esto podría ser el servidor de correo de envío o recepción, el cliente de correo electrónico del usuario o cualquier enrutador de Internet por el que pase el correo electrónico en su camino.

Si el atacante puede ponerse en el medio, es trivial ajustarlo, pero es relativamente difícil ingresar al medio a menos que sea un pirata informático relativamente establecido con una cantidad decente de recursos disponibles para ellos.

En su caso, la medida más fácil es el uso de un enlace basado en HTTPS. Si usa SSL y el usuario se molesta en comprobar que la URL corresponde a su sitio, entonces el escenario de ataque no funciona. También puede decirles el dominio al que se dirigirá el enlace cuando elijan restablecer su contraseña, de esa manera sabrán si es válida. Esta es probablemente la solución más fácil.

La posibilidad que usted describe existe; como otros han señalado, es un "hombre en el ataque central".

Para frustrarlo, necesitará un secreto adicional que no se envíe por correo electrónico, como (una clave secreta pobre) como una clave de cookie. Puede pedirle al usuario que restablezca la contraseña usando la misma computadora y navegador que se usa para enviar el comando "Quiero restablecer mi contraseña".

Entonces, el atacante no podrá enviar la cookie apropiada, ya que su dominio es diferente al original, por lo que el navegador no le habrá indicado el valor de cookie apropiado para usar.

Una posibilidad más estricta es requerir que el usuario inserte en la página de "Restablecimiento de contraseña", sin cerrarla , un código que se envía por correo electrónico. El correo electrónico en ese punto ni siquiera contiene un enlace. El atacante conoce el código, pero no tiene control en la ventana abierta del navegador. La ventana puede contener un secreto oculto que el servidor está "diciendo" a sí mismo, o una cookie (que es básicamente lo mismo). Para evitar el uso de información persistente, el servidor podría almacenar en la página una cadena aleatoria y enviar la cadena aleatoria con un sal secreto. El usuario luego llenará un formulario que tiene ambos valores (uno oculto, uno copiado del correo electrónico). El servidor hash el código con su sal secreta. Si las dos cadenas son iguales, el cambio es aprobado. Para evitar "ataques repetidos" en este caso (es decir, la reutilización de un par de hash / desafío conocido), la verificación podría incluir el nombre de usuario y una marca de tiempo:

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

El usuario recibe el código "123456", al azar, de 100000 a 999999. Hay una posibilidad en aproximadamente novecientos mil de adivinarlo con éxito. El servidor concatena SERVERSECRETPASSWORD.lserni.20140108131005.123456 y verifica que hash a e2961ca083b4393690ec74b93d3c4b32 .

El atacante puede adivinar la marca de tiempo, pero no tiene acceso al hash. Conocer un hash y su código correspondiente solo funcionará con el nombre de usuario correcto, y solo hasta que la diferencia entre la marca de tiempo almacenada no se pueda cambiar y el reloj de pared no crezca demasiado, en cuyo punto el servidor ofrecerá para enviar otro correo electrónico.

Un problema posible (inevitable)

Por otra parte, si el atacante tiene el control del correo electrónico, él mismo puede iniciar una recuperación de contraseña y se le otorgará acceso completo al recurso al menos una vez. Para protegerse contra esto, se debe proporcionar alguna otra información (por ejemplo, una "pregunta secreta") para iniciar el restablecimiento de la contraseña. Además, se debe emitir una advertencia en caso de que la autenticación no exitosa se envíe al usuario, para que se le informe del problema ("Contraseña incorrecta. Recuerde que cambió la contraseña ayer a las 17:23 de IP 1.2.3.4. Si no lo hizo, tenga en cuenta que ... ");

Otro posible problema

En algunos sistemas, se le permitirá pedir al servidor que " se acuerde de usted ". El servidor hará esto al emitir una cookie que es, en todos los aspectos, una autenticación débil y podría ya no estar conectado con la contraseña.

Un cambio de contraseña debería invalidar todas estas cookies , de lo contrario, el atacante puede:   - Toma el control del correo electrónico.   - iniciar un restablecimiento de contraseña   - interceptar el código de restablecimiento de contraseña   - borrar el correo electrónico con la contraseña restablecida   - cambiar la contraseña   - pregunte al servidor "Recuérdeme" y obtenga una cookie "Get Home Free"   - lucro   - El usuario se descubrirá incapaz de iniciar sesión.   - él cambiará la contraseña y volverá a iniciar sesión   - el atacante still podrá iniciar sesión con su cookie.

Una forma de hacer esto es establecer la cookie en una cadena aleatoria más el hash de un secreto de servidor, la cadena aleatoria, el nombre de usuario y el hash de contraseña del usuario en la base de datos. Un cambio de contraseña luego hará que se vuelvan obsoletas automáticamente todas las cookies de autenticación existentes para ese usuario.

TL; DR : Sí. El correo electrónico no cifrado estándar es aproximadamente tan seguro como un mensaje escrito en el reverso de una tarjeta postal.

Respuesta más larga: Esto es completamente posible si el atacante tiene privilegios de administrador en al menos uno de los siguientes:

1. Los servidores de correo a través de los cuales viaja el mensaje (Abra un mensaje de correo electrónico, seleccione "encabezados completos" en el cliente de correo que use, cada línea Received: from [foo] by [bar] indica un servidor de correo al que pasó este mensaje). Si tiene privilegios de administrador para un servidor de correo, puede acceder a su cola, suspender un mensaje en la cola y editar el mensaje antes de enviarlo.

2. Cualquiera de los enrutadores TCP / IP por los que viajó el mensaje. En este caso, el atacante en teoría podría enrutar todo el tráfico SMTP a un servidor de retransmisión local que actuaría como un proxy transparente, pero etiquetar y mantener mensajes específicos en una cola para que el atacante los modifique antes de enviarlos. Difícil, pero factible.

NOTA : el segundo método puede a veces evitarse mediante el uso de smtp-over-ssl, pero esta práctica no es tan común como debería ser y smtps o smtp / tls solo funciona cuando ambos lados * lo soportan; El primer método puede no evitarse cifrando las transmisiones porque el ataque ocurre en un punto de control legítimo (si se subvierte).

Lo que funcionaría contra ambos vectores de ataque sería utilizar un par de llaves pública / privada para firmar el mensaje, pero eso requeriría que el destinatario tenga una copia de su clave pública, que puede ser algo así como un problema de la gallina y el huevo.

Si su correo electrónico se envía de forma clara, un atacante podría, en teoría, modificar el contenido del correo electrónico exactamente como lo ha descrito, con el resultado exacto.

Para interceptar y modificar este correo electrónico, el atacante tendría que tomar el control de un servidor de correo electrónico que manejará el correo electrónico en tránsito, o controlar un dispositivo de enrutamiento con la capacidad de modificar el correo electrónico. Esto no es trivial, si el atacante tendrá acceso a cualquier cosa que no sea el servidor de correo electrónico original, tendrían que saber la ruta exacta que tomará el correo electrónico, lo que significa saber quién es su base de clientes. La mejor manera de aprender su base de clientes sería hackear sus sistemas, y si pueden hacerlo, entonces tienen las contraseñas de sus usuarios de todos modos. Además, escribir un software de captura de pantalla y un sitio web para capturar los cambios de contraseña sería un esfuerzo significativo.

Algunos ataques de phishing ya utilizan un método de ataque muy similar, excepto que en lugar de interceptar y modificar correos electrónicos, simplemente envían correos electrónicos no deseados, lo cual es mucho más fácil. Los bancos han dedicado mucho tiempo a hacer que sus sitios sean resistentes a los ataques de pantalla-raspador. Si tiene alguna inquietud, le sugiero que haga una investigación sobre los diseños de sus sitios e incorpore algunas medidas en su sitio para dificultar más estos ataques.

Podríamos ver los méritos de interceptar y modificar correos electrónicos, ya que hará que el filtrado de spam sea mucho menos probable, y como el usuario ha solicitado un cambio de contraseña, es más probable que confíe en los enlaces del correo electrónico. Aún así, dada la complejidad del ataque, un sitio tendría que tener un valor bastante alto antes de que alguien esté dispuesto a invertir el tiempo y el esfuerzo para hacerlo. Si tu sitio sería un objetivo es algo que deberías decidir por ti mismo.

Puede protegerse contra este tipo de ataque utilizando SMIME o DKIM. Ambas tecnologías verifican el encabezado del mensaje y DKIM protege opcionalmente el cuerpo del mensaje (o los primeros X caracteres en él).

DKIM es una clave pública que se almacena en el DNS, y su administrador de correo electrónico "firma" el mensaje y lo imprime en el encabezado. Obtenga más información sobre DKIM aquí: enlace

Confiar en DKIM significa que el usuario final debe confiar en su propio administrador de correo electrónico para no modificar el mensaje. Hay paquetes de software del lado del cliente DKIM que verifican DKIM, pero no están ampliamente en uso (AFAIK).