El uso de OpenID para autenticar usuarios crece en popularidad y, de hecho, hace que una aplicación web sea más fácil de usar.
Pero, ¿cuáles son las consideraciones de seguridad que se deben tener en cuenta al decidir si implementar un OpenID o no?
¿Es adecuado para cualquier tipo de aplicación web? ¿O existen categorías de aplicaciones web que no deberían usar una forma de manejar la autenticación de los usuarios?
¿Se puede usar OpenID para aplicaciones de comercio electrónico?
Creo que tiene sentido ofrecer registrarse a través de OpenId, pero no lo requiere , incluso para sitios web de comercio electrónico.
La razón de esto es que los usuarios expertos en tecnología (aún la base de usuarios central para openid) pueden decidir si tomar ese riesgo o no.
Los sitios que no recomendaría usar OpenId son sitios altamente sensibles, por ejemplo. sitios bancarios, o sistemas privados / corporativos donde también desea controlar las identidades de los usuarios (a diferencia de la Identidad centrada en la empresa, en lugar de la Identidad centrada en el usuario).
Hay una clara ventaja de usar OpenId, ya que no tiene que administrar las identidades de los usuarios, incluidas las contraseñas, el restablecimiento, la seguridad, etc., y aceptar el riesgo que implica.
Cada proveedor de OpenID tiene una compensación de características de seguridad y desventajas. Por ejemplo:
Rasgos
Google, Facebook, MyOpenID y Verisign ofrecen distintos grados de compatibilidad con dos factores. (Verisign es el IMHO más seguro)
Todos soportan operación sin Javascript (para usuarios paranoicos de seguridad)
Privacidad y anonimato mejorado con MyOpenID y LiveID (aunque no muchos otros)
Política de cambio de contraseña
Signin Seal (Yahoo, ADFSv2)
Flaws
Muchos sitios no ofrecen la misma seguridad de encabezado HTTP como se documenta aquí . Esto significa que algunos sitios son más vulnerables a MITM, FireSheep, repeticiones de token o Clickjacking que otros sitios.
Realmente no hay coherencia entre los distintos sitios.
Y esto es solo el comienzo. Tengo una publicación más detallada con muchos hipervínculos valiosos aquí . Allí, estoy comparando todas las características de seguridad de los principales proveedores de OpenID y solicitando a la comunidad cualquier otra característica o IDP que debamos tener en cuenta.
Si descubres un IDP con funciones de seguridad que no están en la lista, animaré a cualquier persona a que publique allí.
¿Es adecuado para cualquier tipo de aplicación web?
Diría que Verisign sería un nombre confiable para escenarios de mayor seguridad, suponiendo que el usuario final haya optado por todas las campanas y silbidos. No soy un fanático de la configuración de sus encabezados HTTP (enlace de repetición). Solo asegúrese de que su usuario de confianza (sitio web) se proteja de las cookies reproducidas del RP y de las sesiones anteriores.
Si está utilizando Windows / IIS como parte de confianza, puedo enviar más información a su manera de protegerse contra los escenarios que menciono en el párrafo anterior.
Investigación adicional
Microsoft tiene un documento técnico detallado de los problemas de seguridad de OpenID aquí . Envié un correo electrónico a los autores y publicaron un analizador en enlace . La herramienta de análisis está disponible aquí: enlace
No usaría OpenID para nada por la simple razón de que simplemente no conozco bien su funcionamiento interno. En general, aunque diría esto;
Al subcontratar la administración de su acceso, se está preparando para una caída en caso de que ocurra algo con uno de los proveedores principales.
Digamos, por ejemplo, que Google decide comenzar a ser malvado y vende las contraseñas de sus usuarios a un tercero, ese tercero obtiene acceso a su sitio y hace cosas en nombre de los usuarios.
El usuario no se enojará con Google, se enojará contigo.
Y aunque en esta situación extrema hay leyes detrás de usted, no sé si tendría un caso si su información de usuario se filtró de otras formas.
Lea otras preguntas en las etiquetas web-application authentication appsec openid federation