¿Cómo SSO mejora la seguridad?

La idea con un buen inicio de sesión único es que hay menos lugares para que sus credenciales se vean comprometidas. Hay tres razones para usar contraseñas diferentes, primero, porque cada lugar único que almacena su contraseña (con suerte, hash) es otro lugar en el que podría verse comprometido. Segundo, porque si su contraseña está comprometida, cualquier otra cuenta que la use deberá actualizarse y eso es difícil de hacer. Tercero, porque si su contraseña está comprometida, podrían acceder a varias cuentas si fueran compartidas.

SSO es una gran ventaja para los dos primeros. Un buen sistema de SSO solo debe almacenar las credenciales de su cuenta en una ubicación (lo cual se espera que sea mucho más fortificado). Toda la autenticación se realiza contra esta tienda. Si su cuenta está comprometida, en lugar de tener muchos lugares para actualizar, solo se debe cambiar una contraseña y bloquear una cuenta.

No aborda particularmente la tercera preocupación, pero hace que el compromiso sea menos probable en primer lugar. Además, dependiendo de la cuenta, las diferentes contraseñas no necesariamente representan una barrera. Hay muchos ejemplos reportados de atacantes que usan una cuenta comprometida para encadenarse de una cuenta a otra hasta que puedan acceder a la cuenta real que desean. (Por ejemplo, si pueden acceder a su cuenta de correo electrónico, entonces pueden usar restablecimientos de contraseñas). Un buen sistema para reportar compromisos y permitir el cierre de la cuenta puede ser una ayuda decente para mitigar el riesgo, sin embargo, cuando la actividad sospechosa se detecta.

El argumento de que las credenciales completamente únicas pueden ser más seguras que una buena configuración de SSO es posiblemente válido, pero en el mundo real, la mayoría de las personas reutilizan las credenciales. El SSO mitiga gran parte del riesgo de este comportamiento y al mismo tiempo permite la conveniencia que las personas desean.

Cuantas más contraseñas tenga el usuario, más difícil será administrarlas.

Se olvidarán de sus contraseñas con mayor frecuencia, lo que significa que deberán ponerse en contacto con un servicio de asistencia o un sistema automatizado para restablecerla. Tales procedimientos de restablecimiento de contraseña a menudo son vulnerables a todo tipo de ataques diferentes. El personal del servicio de asistencia puede ser engañado a través de la ingeniería social y los correos electrónicos enviados por los sistemas de reinicio automático pueden ser interceptados.

La alternativa sería cuando el usuario usaría la misma contraseña para todo, lo que es una muy mala idea, porque un compromiso de contraseña en un sistema comprometería todos los sistemas. Puede parecer que SSO está haciendo exactamente lo mismo, pero la mayoría de los sistemas de SSO funcionan de manera tal que las aplicaciones que lo utilizan no conocen la contraseña real del usuario. Por lo general, el usuario solo se autentica en el sistema SSO, que luego envía un token de uso único al usuario y a la aplicación.

He defendido el uso de SSO en nuestras aplicaciones de intranet para aumentar la seguridad. En teoría, no es así. Muchas bases de datos bien aseguradas, cada una con una contraseña aleatoria sin relación con ninguna otra contraseña que tenga un usuario, son más seguras ... en teoría. Pero en la práctica, las personas reutilizan sus contraseñas y no todas las contraseñas se almacenan siguiendo las mejores prácticas. Esto significa que el acceso a su sistema más fuerte está protegido por la seguridad del sistema más débil. Al utilizar SSO, tenemos un sistema único que podemos garantizar mejor siguiendo las mejores prácticas.

Puede haber otras opciones, como forzar que las contraseñas sean diferentes, pero aún no he visto una que funcione bien (incluso una contraseña diferente no significa mucho si es My $ secret1, My $ ecret2, My $ ecret3, etc., pero ¿cómo va a determinar qué contraseñas similares se encuentran en el número de sistema 5 si tiene las contraseñas correctamente hash y hasted en los sistemas del 1 al 4)?

Pensándolo de otra manera, poner todos tus huevos en una canasta parece una tontería en general, pero tenemos un conjunto de huevos superpuestos cuantitativamente, donde si uno se rompe, todos se rompen. En tal caso, es mejor poner todos los huevos en la canasta más protegida.

Por lo tanto, un aspecto que se perdió un poco en esta publicación es el de agregar factores adicionales de autenticación al SSO. Por ejemplo, supongamos que tiene 10 sitios en los que inicia sesión, todos estos sitios solo tienen una contraseña de nombre de usuario, que es la más fácil de entender y descifrar. Como mencionó otro póster, un buen SSO establecerá grandes contraseñas aleatorias para el inicio de sesión, estoy pensando en más de 32 caracteres, aleatorizados con caracteres especiales, que luego se pueden cambiar cada 30 días. Esto es algo que una persona nunca recordaría o querría escribir, lo hace con contraseñas aleatorias regeneradas para cada sitio. Por lo tanto, aún tiene la falibilidad de la contraseña del nombre de usuario, pero al menos ahora es lo más seguro posible. Por otro lado, el IDVault en el que el usuario inicia sesión ahora puede protegerse con autenticación de 2 o 3 factores, por lo que el uso de bio o token o ambos para acceder al IDVault es mucho más seguro que las contraseñas de nombres de usuario que no son SSO en cada sitio.

Al final, se trata de proteger a los usuarios de ellos mismos, si requirió contraseñas largas y difíciles de guardar, las almacenarán en una hoja de cálculo o en una nota de papel el 99% del tiempo.

Por supuesto, como lo mencionó un póster anterior, esto abre un punto de falla, esto en sí mismo puede mitigarse pero nunca se puede descartar por completo. Al final, como profesional de seguridad, debe evaluar el riesgo de la falla (mitigada o no) y el riesgo de las contraseñas definidas por el usuario, fáciles de recordar. Para mí, la respuesta es obvia, pero esa es mi opinión y puede que no sea la tuya.