El problema que intenta resolver es que el cliente debe ser identificado por el servidor (para saber qué usuario es éste), pero el cliente también debe ser identificado de manera confiable para detectar el phishing. Estoy de acuerdo en que simplemente usar HTTPS para la identificación del servidor no es suficiente, ya que un atacante puede simplemente poseer un dominio de aspecto similar (por ejemplo, paipal.com vs. paypal.com) y obtener un certificado para el mismo y, por lo tanto, también puede hacer HTTPS. / p>
El proceso habitual de identificación del cliente por parte del servidor involucra algún tipo de secreto compartido, donde el cliente envía este secreto al servidor y el servidor lo verifica (es decir, al iniciar sesión con una contraseña). Este proceso es obviamente vulnerable al phishing.
Las respuestas existentes a estas preguntas, por lo tanto, ofrecen formas de hacer que el usuario detecte al menos el phishing al tener un segundo secreto compartido que luego es presentado por el servidor y verificado por el usuario, es decir, usa el número de teléfono del cliente o algún usuario elegido. La imagen como segundo secreto. Pero este segundo secreto no es suficiente porque una vez que el atacante suplantó al usuario para obtener el secreto inicial (la contraseña), podría determinar el segundo secreto después de iniciar sesión.
Por lo tanto, la imagen elegida por el usuario propuesto por sí sola no es suficiente porque el atacante puede descubrir el secreto y reutilizarlo. Solo la propuesta basada en SMS resuelve este problema al no mostrar el segundo secreto al cliente (y, por lo tanto, al atacante registrado). En su lugar, solo usa el secreto de forma indirecta para generar otro (tercer) secreto (un token) y hacer que este secreto sea conocido por el usuario de una manera que es de esperar que el atacante no pueda acceder. El cliente debe presentar este token secreto al servidor y, por lo tanto, demostrar el conocimiento del secreto. Por supuesto, también puede usar un canal diferente como correo electrónico o chat o una llamada telefónica real (automatizada) para transmitir el tercer secreto, siempre que el atacante no pueda acceder al canal en sí.
Pero si bien la propuesta con el segundo canal suena bien, tiene el problema, depende de este segundo canal por seguridad. Si este canal se ve comprometido por el atacante (es decir, un troyano en el teléfono inteligente que intercepta SMS), se rompe la seguridad. Y si este canal no está disponible (como con un teléfono perdido o robado), no es posible iniciar sesión y, por lo tanto, tampoco hay cambios en el canal seguro. Históricamente, este es un punto débil y, con frecuencia, los atacantes tienen acceso al sitio llamando al servicio de asistencia y engañando a la persona de soporte para que cambie el número de teléfono o el correo electrónico por uno controlado por el atacante, por supuesto, después de responder algunas preguntas de seguridad donde las respuestas podrían a menudo se puede descubrir fácilmente.
Aparte de eso, ninguna de estas soluciones resuelve el problema cuando el atacante crea su propio sitio de phishing (por ejemplo, paipal.com) y simplemente retransmite inicialmente todos los datos al sitio original (por ejemplo, paypal.com) y, después de una autorización exitosa, corta fuera de los clientes originales y utiliza la sesión establecida para el propósito de los atacantes. El HTTPS simple tampoco ayudará aquí porque el atacante podría obtener un certificado para su sitio de phishing también.
Una forma alternativa de proteger la comunicación es usar HTTPS junto con los certificados de cliente. Mediante el uso de la criptografía de clave pública subyacente, el cliente puede identificar el cliente y el cliente puede identificarlo. El atacante aún puede crear un sitio de phishing pero no puede capturar el secreto (es decir, la clave privada del certificado de los clientes) necesario para su posterior reutilización. Debido a que a menudo no es tan obvio para el cliente que un certificado de cliente esté involucrado, por lo que aún se necesita algún tipo de detección de phishing, pero en este caso la presentación de la imagen elegida por el usuario podría ser suficiente. Y dado que el atacante no puede usar el certificado del cliente real para identificarse contra el sitio original, no puede determinar la imagen elegida por el usuario ni es posible el ataque de transmisión descrito anteriormente. Desafortunadamente, el proceso de uso de certificados de clientes no es fácil de usar y también se debe incluir el certificado en cada navegador que utilice el cliente. Además, el certificado se comparte entre todos los usuarios del perfil del navegador, lo que también podría ser un problema si varios usuarios usan la misma computadora.