Autenticación de usuario autocodificada de seguridad

1

Actualmente estamos utilizando Apache Shiro para nuestras necesidades de autenticación de usuarios. Tenemos autorización dinámica \ necesidades de autenticación, en algunos casos los usuarios se autenticarán con Active Directory mientras que otros se autenticarán con JDBC, pero todos los usuarios se autorizarán con JDBC.

Shiro ha demostrado estar a la altura, pero no bien. Funciona, pero solo a veces. Los reinos programáticos que he creado no parecen funcionar de la misma manera cada vez. A veces, al intentar inicios de sesión varias veces fallará, solo para tener éxito. Esta es exactamente la misma solicitud con los mismos datos. La depuración muestra que a veces simplemente no llama a las funciones necesarias para obtener los datos de autenticación o autorización. El reinicio de la instancia generalmente solucionará esto, pero solo por un tiempo. También parece tener problemas serios con múltiples aplicaciones shiro existentes en la misma instancia de Glassfish.

Como tal, Shiro no parece ser una opción sostenible, especialmente dada la poca documentación que existe para ello. Ya estoy anulando los métodos de Shiro para decirle exactamente cómo obtener los datos, así que me gustaría simplemente codificar mis propias clases de autenticación de usuarios de Java.

Actualmente, el mejor argumento que he escuchado en contra de esto es que un sistema con código personalizado no será tan seguro como el estándar de la industria. Sin embargo, por lo que he leído en línea y me han enseñado en clase, la mayoría de los intentos de piratería se centran en obtener acceso a los nombres de usuario y contraseñas, o en averiguar cómo enviar un código Rouge al sistema. La mayoría de los métodos no infringen el software en sí; básicamente, solo verifica los datos que se proporcionan y, siempre que todas las entradas estén saneadas, el software de autenticación del usuario no suele ser el problema. ¿Es esa evaluación precisa?

Además, ¿hay algún error que deba tener en cuenta? Entiendo que hay otras opciones como Spring Security o JAAS, pero como ya tengo esencialmente el sistema que necesito tener integrado en Shiro y solo tengo que eliminarlo de ese software, parece que la mejor opción sería utilizarlo en este momento. el ciclo de desarrollo.

    
pregunta Marcel Marino 07.07.2017 - 14:04
fuente

2 respuestas

2

Los desarrolladores de software tienden a exponerse solo a la punta del iceberg de credenciales y autenticación porque el 98% de la aplicación involucra la lógica de negocios que implica la aplicación y solo el 2% de la aplicación maneja la autenticación del usuario. Los esquemas de autenticación deben ser capaces de frustrar los intentos de craqueo de fuerza bruta, interceptar las comunicaciones de la red, personas en el medio, etc. y muchas más formas de ingresar a un sistema cerrado. Además de la autenticación, también debe asegurarse de que la sesión del usuario, una vez autenticada, funcione en toda la aplicación y sea segura, por ejemplo. la sesión no puede ser robada, etc.

Todo esto es lo que Apache Shiro está manejando para usted, y aunque no tengo experiencia práctica usándolo, no puedo encontrar reclamos de falta de confiabilidad, errores, etc. Si fuera yo, lo haría. concéntrese en averiguar de dónde viene la falta de fiabilidad y resuélvalo en lugar de rodar el mío. Porque incluso si lo hace bien y está "seguro" para los estándares de hoy en día, eso no significa que aún se considerará seguro en un año, tres o cinco años en el futuro. Siempre deberá tener conocimiento de los desarrollos en el espacio de seguridad / cracking que se desarrollan con el tiempo, lo que puede poner en riesgo su metodología de autenticación, actualización, etc.

El conjunto de documentación se ve bastante bien: Documentación de Apache Shiro

    
respondido por el Thomas Carlisle 07.07.2017 - 18:01
fuente
0

Luego, la respuesta depende de cuán crítico sea el sistema que está desarrollando. Si se rompe no tiene un gran impacto en su negocio, entonces usted está bien. Si lo hace, entonces esta respuesta es relevante para usted.

Cuando implementa su propio sistema de seguridad, usted es el responsable de garantizar que sea realmente seguro, confiable y que lo siga siendo hasta que se retire.

Supongamos que usted ideó su propio sistema de autenticación, tendría que seguir adelante y realizar pruebas de penetración adecuadas contra él y también asegurarse de que todos los sistemas con los que interactuaría sean compatibles. (Una vez que desarrolle un sistema, la expectativa sería que las herramientas futuras relacionadas con este usarán su sistema de autenticación ya que es algo que ya está en uso).

Una vez que haya lanzado la versión 1 de este sistema, tendría que pasar por esto por cada nueva vulnerabilidad que se encuentre en las bibliotecas / lógica que está usando. Además, todos los futuros lanzamientos deberán pasar por este proceso.

El uso de un sistema que ya está en el mercado y de código abierto, le quita esta responsabilidad. Esa es una de las principales ventajas que las empresas ven al usar algo que ya está en el mercado.

TL; DR: Si implementas tu propio sistema de seguridad que resuelve un problema que ya ha sido resuelto por otros, esencialmente habrías pasado una cantidad considerable de tiempo desarrollando algo que requeriría una considerable cantidad de tiempo en el futuro en lugar de gastar una cantidad considerable de tiempo ahora y una pequeña cantidad de tiempo en el futuro.

    
respondido por el Limit 07.07.2017 - 20:05
fuente

Lea otras preguntas en las etiquetas