Sistema de autenticación contra el usuario

La autenticación mutua es la regla normal; de lo contrario, puede tener problemas como man in the middle attack .

Considere lo que sucede con un servidor web con SSL . El navegador primero se conecta al servidor y el servidor envía su certificado . Este certificado y las operaciones criptográficas relacionadas demuestran al cliente que habla con el servidor "correcto"; p.ej. habla con un servidor que es realmente "www.paypal.com". El navegador transmite esa información al usuario al mostrar el famoso ícono del candado verde y abstenerse de mostrar ventanas emergentes de miedo con advertencias de lectura intermitente. Luego, el usuario escribe su nombre de usuario y contraseña, que se envían al servidor (dentro del túnel SSL).

El certificado del servidor es realmente "autenticación del sistema contra el usuario", mientras que la contraseña del usuario se usa para la "autenticación del usuario contra el sistema". Ambos son importantes. Imagínese lo que podría pasar si no hubiera un certificado de servidor: el usuario creería que contactó con el servidor "www.paypal.com" genuino, pero en realidad sus paquetes de datos fueron secuestrados por un malvado desagradable que opera Un punto de acceso WiFi malicioso. Así que el usuario realmente está hablando con el servidor del atacante, y cuando escribe su contraseña, la contraseña va al servidor del atacante. Lo cual, como puedes imaginar, es un problema.

La autenticación mutua realmente sucede todo el tiempo.

Como todas las preguntas de autenticación, es una cuestión de confianza.

La autenticación es esencialmente alguien que demuestra que es quien dice ser: a menudo lo hacemos proporcionando un secreto compartido, una contraseña. es decir, cuando un usuario desconocido se conecta a su servidor de confianza, se identifican y proporcionan el secreto. El servidor confía en que el usuario es quien dice ser, porque conoce el secreto.

Ves esto en la otra dirección cuando un usuario se conecta a un servidor en el que no necesariamente confían, como su banco (quieren un mayor nivel de seguridad) mostrando su número de cuenta bancaria; algo que un tercero no sabría. Obtienes esto en menor medida cada vez que inicias sesión y ves tu nombre, avatar o lo que sea que aparezca en la pantalla; genera un sentimiento de confianza, aunque está mucho menos formalizado que "Confío en que la contraseña sea correcta".

Usted obtiene el intercambio de confianza formal completo cada vez que inicia sesión en algo que usa autenticación multifactor: si inicio sesión con mi nombre de usuario y contraseña, el servidor ahora confía en mí, si ingreso la clave en mi token RSA, o número que recibí en un SMS, ahora confío en el servidor a cambio.

La autenticación del servidor puede ayudar contra el phishing. Por ejemplo, si va a enlace y es conducido al sitio de phishing enlace , ambos con certificados de servidor válidos para su URL (el servidor se autentica como bank.com y b4nk.com respectivamente, por lo que solo sabemos que el sitio corresponde a la URL, que la mayoría de las personas pasa por alto).

Un nombre de la mascota del sistema (documentado aquí ) se puede establecer en su lugar, de modo que el usuario, al registrarse, asocie el sitio web de destino con un petname (ya sea una cadena de texto, una imagen reconocible o un sonido). Este nombre de mascota se presenta al usuario al acceder al sitio. Si no se puede encontrar el nombre de la mascota, el usuario se alarmará y deberá verificar la URL. Si la URL se ingresa correctamente, el sitio es seguro.

Editar: note el comentario de AJ Henderson a continuación.