Autenticación para aplicaciones externas

Question

Autenticación para aplicaciones externas

#1 de rook (4 votos)
#2 de tylerl (3 votos)

2

Necesito diseñar una aplicación para uso corporativo interno. La aplicación debe estar alojada externamente. Idealmente, me gustaría que esa aplicación pueda autenticarse y autorizarse contra el ActiveDirectory corporativo.

Sin embargo, hay 2 problemas aquí:

La autenticación debe funcionar incluso si la red corporativa no está disponible.
Prefiero no replicar ActiveDirectory en una ubicación externa por razones de seguridad. Por cierto, ¿es correcto?

Tengo algunas ideas estúpidas como tener un "proxy LDAP" alojado externamente que ahorraría hashes de credenciales por tiempo limitado. Ese tiempo debería ser suficiente para poner en marcha la red. Mientras la red no funciona, el "proxy LDAP" comprueba las credenciales contra los hash locales. Esta idea parece ser demasiado casera e insegura. ¿Es posible implementar con ActiveDirectory Lightweight Directory Services (AD LDS)?

Si el ideal anterior no es factible, ¿existe alguna solución de autenticación de terceros? Con gestión de cuentas, políticas de contraseña, API, etc.

web-application authentication active-directory

pregunta Sergey Romanovsky 06.11.2013 - 00:24

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application authentication active-directory

Logro de PFS con criptografía de clave pública Las mejores prácticas de seguridad en un cibercafé

score 4 · Answer 1

La forma única de tener un sistema de autenticación seguro para una compañía que aún puede funcionar mientras la red corporativa no está disponible, es no usar la red corporativa. Considere alojar este servicio en la nube o tener una copia de seguridad en caliente basada en la nube.

Tener una copia de la base de datos de autenticación en cada dispositivo es una vulnerabilidad, y una clara violación de CWE-602 . Por definición, este sistema le está dando a un usuario todas las claves del reino. La base de datos debe ser accesible para autenticar a un usuario fuera de línea, y en este punto un atacante no autenticado tiene acceso a todos los datos almacenados en el dispositivo (buss sniffing, adjuntando un depurador al proceso de autenticación o un ataque de arranque en frío , y hay otros ataques ...).

Intentar "cifrar la base de datos" es una manifestación del problema DRM, que no tiene ninguna solución . (El único hilo que mantiene DRM es la DMCA. La DMCA no protegerá una base de datos insegura contra el compromiso).

score 3 · Answer 2

Sus dos requisitos se excluyen mutuamente:

La autenticación debe funcionar incluso si la red corporativa no está disponible.
Esto significa que las credenciales deben deben almacenarse en caché en el servidor de autenticación.

Preferiría no replicar ActiveDirectory en una ubicación externa por razones de seguridad.
Esto significa que las credenciales no deben estar en caché en el servidor.

Así que ... elige uno. Mejor aún, tirar la idea por completo. ¿Por qué está exponiendo sus credenciales corporativas internas a Internet externo?

Supongamos, por ejemplo, que expone su sistema de Active Directory a Internet, pero solo para la autenticación. Por lo tanto, cualquier persona en Internet podría preguntarle a su servidor de AD si un nombre de usuario / contraseña era correcto o no, y tal vez obtener algunos metadatos adicionales si lo es. Entonces, ¿qué hay de malo en eso? ¿Qué tipo de amenazas puedes pensar que quieras evitar?

Bien, ahora vamos a cambiarlo y, en lugar de preguntarle a su servidor de AD si es correcto o no, le pregunta a esta aplicación externa si la contraseña es correcta, pero de alguna manera, la magia de seguridad coincide con sus contraseñas de AD. Entonces ... ¿hay ataques posibles en el escenario anterior que no son posibles ahora?

Si bien hay muchas maneras de lograr lo que estás hablando, la tecnología intermedia no hace que la idea sea más segura. Así que, o bien acepta que estás poniendo en riesgo tu seguridad interna y sigue adelante con ella; o cree una estrategia diferente y no use sus contraseñas internas en un servicio externo.