¿Protegiendo los hash de contraseña con procedimientos almacenados?

Question

¿Protegiendo los hash de contraseña con procedimientos almacenados?

#1 de Tom Leek (3 votos)
#2 de Eric G (1 votos)

5

Estaba pensando en las recientes brechas de seguridad (aparentemente semanales) que hemos visto en las que se han filtrado millones de hash de contraseñas y me preguntaba cómo se podría proteger su sitio contra un volcado de contraseñas, incluso si un hacker encontró una inyección de SQL. vulnerabilidad.

¿Qué sucede si el usuario que estaba utilizando el sitio web para iniciar sesión en la base de datos tenía permisos más limitados? Digamos que en todos los datos no críticos el usuario tenía permisos completos como los normales (CRUD). Pero, ¿qué sucede si al usuario se le negaron todas las operaciones CRUD a la tabla que almacenaba los hashes de inicio de sesión, las preguntas de seguridad, etc. y solo podía ejecutar procedimientos almacenados en esa tabla? Y digamos que esos procedimientos almacenados nunca devolvieron los hashes de contraseña a la capa de la aplicación, sino que usted pasaría el hash al procedimiento y el procedimiento devolvería un valor booleano que indicaba si había una coincidencia.

Me parece que esta configuración eliminaría la posibilidad de un volcado de hash de contraseña a través de la inyección SQL por completo. ¿Esta configuración proporciona seguridad adicional, es recomendable?

Actualizar

Consulte esta pregunta para obtener más detalles:

Merece la pena ¿Desde el punto de vista de seguridad hasta el usuario de servidor de base de datos para el sitio web ASP.NET, solo para EJECUTARSE en procedimientos almacenados?

passwords password-management sql-injection

pregunta John 10.05.2013 - 17:40

fuente

2 respuestas

1

Una forma diferente de ver el problema es asumir que la base de datos estará comprometida. Si la base de datos está comprometida y se obtiene la tabla de contraseñas, ¿cómo puede reducir el valor del ataque haciendo que los datos no tengan sentido?

Primero, por supuesto que desea usar un algoritmo de hash criptográfico fuerte ( bcrypt, scrypt, etc. ). Desea utilizar una sal aleatoria para reducir la capacidad de usar la tabla de arco iris de manera efectiva. También puede usar un mecanismo de salpicado y separación de uso a través de otro servidor o módulo de seguridad de hardware (HSM) , sin la pimienta, será mucho menos probable obtener algo significativo de la lista de hash. Puede lograr esto en menor medida utilizando un servidor bloqueado con solo la tabla de contraseñas presente, asegurándose de que haya un cifrado y una autenticación adecuados entre el servidor que realiza la solicitud y su servidor de verificación de contraseña.

respondido por el Eric G 10.05.2013 - 19:08

fuente

Lea otras preguntas en las etiquetas passwords password-management sql-injection

Evaluación de seguridad del Digipass Mobile SDK de Vasco para OTP? Un par de redirecciones después de hacer clic en un enlace, ¿qué buscan después?

score 3 · Accepted Answer

El esquema que describe es similar en concepto a hacer un servidor de verificación de contraseña dedicado (servidor local, no abierto al mundo en general) con su propia base de datos completamente distinta para el almacenamiento de contraseñas con hash. Esto puede funcionar. En realidad, ya tiene eso bajo la apariencia de "integración del sistema" cuando las cuentas de usuario se asignan, por ejemplo, a un servidor de Active Directory o cuentas locales de Unix.

El uso de un procedimiento almacenado en la base de datos para eso depende de que la base de datos aplique el aislamiento adecuado, una apuesta algo arriesgada, ya que está imaginando una situación en la que el atacante incluya sus propias declaraciones SQL.