¿Responder al correo electrónico o al texto como verificación?

Estoy de acuerdo contigo en que esto sería conveniente, pero supongo que podría haber algunas motivaciones para no hacer esto.

Problemas desde la perspectiva del usuario:

Primero, en el caso de la respuesta al mensaje de texto: es muy probable que tenga un impacto monetario. Donde vivo, y solo puedo asumir que en la mayoría de los demás países, se cobran los mensajes de texto. El costo puede ser insignificante, pero el proveedor del servicio no puede asumir que tiene dinero para poder responder en ese mensaje de texto.

En el caso del correo electrónico, la mayoría de estos correos electrónicos se envían desde direcciones o a través de proveedores de correo masivo que ni siquiera permiten respuestas en esos correos electrónicos (la motivación, por lo tanto, en parte basada en la seguridad, supongo). Esta práctica obviamente haría imposible responder con una confirmación.

Problemas desde la perspectiva de los proveedores de servicios:

Si permiten a los usuarios responder por correo electrónico o mensaje de texto, deben analizar esas respuestas, lo que podría ser una gran cantidad de trabajo y consumir recursos computacionales muy valiosos. Cualquiera que haya intentado analizar respuestas en correos electrónicos sabrá que los encabezados se modifican o se pierden y que el contenido del cuerpo puede cambiar fácilmente, y mucho menos los problemas de codificación de caracteres que le causan dolores de cabeza. Lo mismo con los mensajes de prueba, aunque en menor medida. Esas respuestas a los mensajes de texto deberán analizarse e higienizarse a expensas del proveedor del servicio.

Los usuarios confían en los correos electrónicos, pero desafortunadamente son intrínsecamente inseguros. Tenga en cuenta que no estoy diciendo que todo el correo electrónico sea inseguro, pero la cantidad de servidores SMTP que no emplean algún tipo de seguridad de capa de transporte es sorprendente. También se sabe que algunos protocolos de autenticación SMTP muy básicos como CRAM-MD5 no son muy seguros. Todo esto significa que los correos electrónicos pueden ser modificados fácilmente durante el transporte por un MItM, lo que hace extremadamente difícil para el proveedor de servicios confiar en esas respuestas. Preferirían que obtuvieras el código, lo copiaras y lo pegaras de forma segura en su sitio HTTPS, mucho menos para ellos. Por supuesto, esto es más relevante con procesos de alto valor y críticos, como una respuesta para autorizar una transacción de Bitcoin desde una billetera en línea.

Sin embargo, lo que he visto en ciertos sitios es un correo electrónico con un enlace que apunta a un sitio seguro con una cadena de consulta al final que contiene mi número de referencia. Al hacer clic en ese enlace, se publican en el sitio seguro y se envía su código. Esto funciona muy bien si asumes que el enlace no fue alterado de alguna manera.

Supongo que la mejor solución sería ofrecer una gama de opciones, ya que existen opciones alternativas sobre cómo le gustaría responder en esa notificación, pero eso implicaría que el sitio web trabaje más, lo que no siempre les gusta .

La respuesta por correo electrónico con un token único sigue siendo un estándar en todas las listas de correo que puedo imaginar. Y no veo cómo puede ser menos seguro que hacer clic en el enlace, ambos métodos se basan en la confidencialidad del correo electrónico, si el intruso puede acceder al contenido del correo electrónico, también puede usar un enlace. Por otro lado, podría ser técnicamente más difícil para un intruso enviar una respuesta válida a un correo electrónico, por lo que incluso puede mejorar la seguridad.

Aparentemente, algunos piensan que es más conveniente hacer clic en un enlace que pulsar el botón de respuesta y luego enviarlo. Además, al utilizar Link, tiene todas las aplicaciones lógicas en un solo lugar, no tiene que escribir lógica para procesar los correos electrónicos entrantes para el servidor de correo ni buscar un programador que sepa cómo hacerlo. Lo mismo ocurre con la respuesta de texto, pero cuando respondes, el teléfono móvil no citará el texto como lo hace el cliente de correo electrónico, por lo que aún tendrás que seleccionarlo, copiarlo y pegarlo en texto nuevo. No creo que alivie tu dolor :)

La instalación, configuración, ejecución, prueba, monitoreo y actualización de un sistema seguro, robusto y eficiente para analizar y tomar medidas automáticamente en función de los correos electrónicos recibidos no es trivial.

Hacer esas cosas para un sistema web tampoco es trivial, pero alguien que ejecuta un sitio web ya tiene esa infraestructura instalada.

La distribución de su tiempo y experiencia en dos sistemas significa que es más probable que cometa errores.

Esto suele deberse a la forma en que funciona el sistema de correo electrónico. Si bien no es inmediatamente obvio para alguien que usa el sistema, el correo electrónico está compuesto de múltiples sistemas distintos que trabajan juntos para "correo electrónico". Usted tiene un servidor SMTP que es responsable de enviar y recibir correo en el protocolo SMTP, pero luego debe guardarse en algún lugar para procesarlo y recuperarlo, y eso se hace mediante diferentes protocolos y servidores.

A menudo, un sitio web en realidad no envía un correo electrónico desde un servidor de correo, sino que simplemente tiene una rutina de generación de mensajes SMTP y puede enviar el mensaje al servidor del destinatario correspondiente. En este caso, el sitio web no tiene la capacidad de recibir un mensaje, ya que en realidad no tiene un servidor SMTP asociado.

Además, incluso si el servidor web tiene un servidor SMTP asociado, necesitaría que se ejecute un filtro especializado en el servidor SMTP que también tendría que comunicarse con el servidor web o la base de datos que usa el servidor web. Esto no solo es mucho más complejo que tener un formulario HTML en el que el valor se ingresa en el propio servidor web, sino que potencialmente abre numerosos agujeros de seguridad en el sitio web ya que ahora tiene el doble de área de superficie de ataque.

Como a veces un web-dev, es mucho más fácil para mí enviar un correo electrónico que analizar uno. Es mucho más fácil para mí aceptar una solicitud entrante con un token de validación en un parámetro de consulta, que analizar el correo electrónico. Así que ... Usted recibe un correo electrónico con un enlace. Esto me permite validar que alguien con acceso al correo electrónico puede hacer clic en un enlace, es decir, puede que no sea un pirata informático astuto, pero en realidad puede ser el usuario. No es una técnica que usaría para nada sensible (por ejemplo, datos financieros). Quisiera otras garantías de identidad y recibo de mensaje.

Los sitios que usan mensajes de texto / SMS tienen una preocupación diferente. No se deben usar los mismos servicios de comunicación para pasar el inicio de sesión y la contraseña, o el token de inicio de sesión y autenticación. El factor secundario para el inicio de sesión con un mensaje de texto hace que sea menos probable que te estén falsificando. Si bien un pirata informático puede ganar el control de su cuenta de correo electrónico, pasar desapercibido y comprar algo ... si también necesitan robar su teléfono, y cualquier medida de seguridad que use para proteger su teléfono ... han tenido que ir a un excelente repartir más esfuerzo. Es posible que hayan tenido que robar a usted , por ejemplo.

El siguiente paso es esos tokens de autenticación de dos factores. Todo para que puedas afirmar que probablemente eres realmente tú. Esencialmente, es la protección del servicio o de usted, dependiendo de cómo su dominio legislativo trate el robo de identidad y las compras que no realizó en direcciones novedosas ...

Si puedes crear un mecanismo que demuestre quién eres, usando solo un canal, sin tener que hacer clic en un enlace o teclear algo, serás amado. Ha sido un problema durante décadas. Por lo tanto, todos esos dongles bancarios y aplicaciones de autenticación de 2 factores, incluso para World of Warcraft.