¿Por qué la autenticación de certificado de cliente no es más común?

1

En mi entendimiento, la autenticación del certificado de cliente no es especialmente compleja de implementar y tiene varios beneficios en comparación con la autenticación de contraseña

  • El secreto (clave privada) no tiene que abandonar el equipo cliente.
  • La violación del lado del servidor no pone en peligro las cuentas de clientes en otros servicios
  • El usuario puede recordar una contraseña maestra única para su clave, o preferiblemente, puede desbloquear la clave con el inicio de sesión del sistema operativo, en lugar de intentar recordarla por cada inicio de sesión

Pero no recuerdo haber usado ningún sitio en Internet que ofrezca esta variante de autenticación (no estoy diciendo que no haya ninguno, pero mi impresión es que no son comunes). ¿Por qué no es más común?

Entiendo que

  • La configuración no es trivial desde el lado del usuario final
  • La portabilidad de las credenciales no es trivial
  • Es posible que algunos dispositivos no lo admitan (si recuerdo correctamente, android bellow 4.0 no los admitió de forma nativa, por ejemplo)

¿Pero todavía por qué no ofrecerlos para sitios que requieren alta seguridad donde el usuario está listo para hacer un esfuerzo adicional para garantizarlo (por ejemplo, sitios de bancos) o sitios que desean brindar una impresión de alta seguridad (por ejemplo, sitios de bancos)? >

¿O me equivoco y los certificados de cliente se usan más comúnmente de lo que imagino?

    
pregunta AGrzes 30.11.2018 - 20:58
fuente

3 respuestas

2

Tus tres puntos son bastante válidos.

En resumen: los certificados de cliente no son complicados para el promedio de usuarios de Internet.

tl;dr

El problema de raíz proviene del hecho de que la autenticación mutua (TLS) no funciona de la misma manera para ambas partes. La explicación a continuación supone una autenticación TLS mutua.

El cliente se conecta al servidor y espera algunas confirmaciones de identidad del servidor en forma de certificado de servidor emitido por una autoridad confiable. Si el certificado del servidor pasó la autenticación TLS, obtuvimos el servidor correcto.

Cuando el servidor está escuchando en el puerto y el cliente se conecta al servidor, el servidor debe autenticar y autorizar al cliente. El servidor debe asignar el cliente remoto a una base de datos de usuarios local para validar los permisos y proporcionar contenido personalizado. Aquí está la diferencia: el cliente solo autentica el servidor, pero el servidor autentica y autoriza al cliente.

Como puede ver, el cliente solo consume recursos y no necesita autorizar el servidor remoto. El servidor es productor de recursos y debe verificar si el cliente puede recibir los datos solicitados, por lo que la autorización debe estar habilitada en el lado del servidor. En un esquema de autenticación de correo electrónico / contraseña, el servidor asigna el correo electrónico / contraseña a una cuenta particular en la base de datos local. El servidor recibe esta información cuando el usuario se registra en el servidor. Inscripción con certificado:
  1. es difícil. Requiere herramientas sofisticadas con sintaxis críptica y conocimiento especial;
  2. requiere gestión de certificados.

Aquí es donde los usuarios sin educación fallarán. Puede recordar una combinación de correo electrónico / contraseña, por lo que cambiar de cuentas y dispositivos no es un problema. El cambio de dispositivo en la autenticación de cliente basada en certificados no irá a ninguna parte. ¿Qué tan fácil sería para un usuario promedio (que no es un experto en TI) mover el certificado de su computadora portátil con Windows a un teléfono / tableta iOS, por ejemplo? ¿Mover el certificado entre el teléfono / mesa Android y la computadora portátil Mac?

Como el cliente no autoriza el servidor (no mantiene una base de datos local de servidores válidos), el servidor puede rotar sus claves todos los días y nadie lo notará. El servidor funcionará como de costumbre.

No estoy de acuerdo con la declaración de @ SyntaxxxErr0r de que los usuarios finales son perezosos. No están listos para realizar la gestión de certificados por su cuenta. Y los intentos de enseñarles darán como resultado un alimento para posibles hackers. Una vez más, el usuario promedio de Internet no es un experto en TI y no es obligatorio que lo sea. Es un buen acuerdo que los usuarios finales entiendan la combinación de correo electrónico y contraseña y es imposible pedirles otra cosa.

  

¿Pero todavía por qué no ofrecerlos para sitios que requieren alta seguridad donde el usuario está listo para hacer un esfuerzo adicional para garantizarlo (por ejemplo, sitios de bancos) o sitios que desean brindar una impresión de alta seguridad (por ejemplo, sitios de bancos)? >

La misma historia. La banca por Internet se supone para todos, independientemente de su educación técnica. Es decir, mi abuela de 80 años debería poder usar los servicios bancarios de Internet para administrar su pensión y hacer pagos básicos. Sin embargo, algunos bancos emiten a los clientes un token de hardware personalizado, pero esta es una inversión adicional del lado del banco. Literalmente, ningún sitio en Internet salvaje invertirá en tokens de hardware para cada usuario.

Otra cosa a tener en cuenta: los sitios web ofrecen restablecimiento de contraseñas por correo electrónico. ¿Cómo se verá esto en el caso de los certificados? Intente responder a estas preguntas y descubrirá por qué la autenticación de cliente basada en certificados no está extendida en Internet salvaje y no lo estará por mucho tiempo.

    
respondido por el Crypt32 30.11.2018 - 22:25
fuente
1

El único contexto en el que he visto la autenticación de certificado de cliente, incluso ofrecida como opción, es para los permisos de API de servidor a servidor.
Incluso en este contexto, realmente no se ha puesto de moda. Las claves de API (básicamente pares muy largos de nombre de usuario y contraseña, aptos para ser utilizados por robots) son portátiles, fáciles de implementar (recuerde, los desarrolladores son tan vagos como todos los demás) y fáciles de mantener / rotar.

Algunos problemas particulares con el uso de certificados de cliente para la identificación / autenticación / autorización:

  • Puede transmitir el certificado público fuera de banda y usar su certificado privado para la identificación, pero luego realizar un ciclo de certificados es una tarea, y debe copiar el certificado entre todos los servidores paralelos del clúster.
  • Puede usar una cadena de confianza normal en la cual una firma en un certificado reemplazable promete que usted es quien dice ser, pero imagine el dolor de cabeza de lograr que eso funcione de manera confiable en sus entornos de desarrollo y de puesta en escena.

Podemos imaginar que todo esto sería más fácil si ya fuera una práctica normal, pero nunca sería tan fácil como las fichas / claves convencionales, y las ventajas serían pequeñas.

    
respondido por el ShapeOfMatter 30.11.2018 - 22:42
fuente
-1

Es probable que se deba en parte a que el proceso sea lo suficientemente simple para que cualquiera pueda y pueda implementar un certificado en cuestión de minutos, pero también lo suficientemente complicado para que las personas no lo configuren correctamente.

Sin embargo, las personas tienen la tendencia de no configurarlo, porque ya no estaba configurado. Básicamente, la mayoría de los usuarios finales tienden a ser perezosos.

    
respondido por el Syntaxxx Err0r 30.11.2018 - 21:23
fuente

Lea otras preguntas en las etiquetas