Para todos los problemas que conlleva, ¿por qué la administración de contraseñas no es manejada por la base de datos?

Question

Para todos los problemas que conlleva, ¿por qué la administración de contraseñas no es manejada por la base de datos?

#1 de Lucas Kauffman (6 votos)
#2 de David (2 votos)
#3 de Steve DL (1 votos)
#4 de Fleche (1 votos)

1

Ahora mismo, podríamos hacer algo como password varchar(72), al definir una columna de contraseña, por ejemplo con BCrypt. Pero hay mucha gente que no lo hace de manera muy efectiva. Tal vez solo pongan el texto sin formato, o un solo hash md5 sin sal, o alguna otra estrategia terrible.

Pero prácticamente todos estos delincuentes siguen utilizando bases de datos. Entonces, ¿por qué este tipo de funcionalidad no se incluye en las bases de datos? Algo como mypass password('BCrypt:10'), y acceso como INSERT INTO people(name, mypass, other_data) VALUES(?, ?, ?) que tomaría la contraseña de texto sin formato del usuario y la pasaría a la tabla. Pero la tabla almacenaría el valor hash de BCrypt apropiado. Luego, podríamos hacer algo como SELECT other_data FROM people WHERE name = ? AND mypass = ? : esto nuevamente tomaría el texto simple del inicio de sesión del usuario, pero cargaría la sal y realizaría el análisis para determinar si la contraseña fue un éxito o no.

Cuando se trata de almacenar datos, utilizamos bases de datos en lugar de archivos sin formato o lo que tenemos porque son confiables, probados y simples (en comparación con los nuestros). Ya que está claro que en el mundo salvaje hay innumerables lugares donde el almacenamiento de contraseñas no es confiable y no se ha probado, ¿por qué este tipo de almacenamiento de datos no se realiza por la propia base de datos?

password-management databases

pregunta corsiKa 26.06.2014 - 22:46

fuente

4 respuestas

Lea otras preguntas en las etiquetas password-management databases

¿Es peligroso este SMS de spam que contiene un archivo de audio? Con RSA, ¿se puede garantizar que dos entidades no tendrán la misma clave privada?

score 6 · Answer 1

Sería posible pero:

No es un SQL estándar (tendría que convertirse en una característica, parte del producto)
Toda la potencia de procesamiento se centralizará en la base de datos
No todas las aplicaciones web utilizan bases de datos SQL

Está cambiando el problema, hace 10 años hubiera sido aceptable usar sal MD5 +. Entonces, ¿tu base de datos implementaría MD5 + sal, verdad? Muy bien, 10 años después, usted como desarrollador necesita usar la contraseña nuevamente en el nivel de la base de datos, ahora la base de datos admite bcrypt, pero seguirá usando sal MD5 + porque es lo que sabe, ¿verdad?

¿Por qué es necesario que aún sea compatible con sal MD5 + que puede pedir? Simplemente porque probablemente todavía estés usando la misma aplicación. La migración al nuevo esquema aún requerirá la intervención del desarrollador, no se producirá de forma automática.

No es posible convertirlo en una función para usar solo un algoritmo de hashing de contraseña automático porque habrá implementado un esquema anterior para aplicaciones más antiguas. Esto requeriría que el producto de la base de datos implemente repentinamente una función de migración automática. Esto es complejo de implementar.

Como puede ver, el problema cambia de ser un problema de desarrollador a un problema de desarrollador de base de datos.

score 2 · Answer 2

Hay varias razones:

Necesitaría modificar el planificador de consultas para comprender los tipos de columna, ya que tendría que seleccionar el nombre de usuario, leer el salt y luego manejar el hash de la contraseña.
Está agregando una carga adicional a la base de datos, que suele ser el punto caliente en las aplicaciones, para el trabajo que se puede realizar con la misma facilidad.
Necesitaría una forma de actualizar los tipos de hash: ¿es eso una modificación del esquema de la base de datos?

Si alguien no sabe cómo escribir una aplicación, darles una columna de base de datos "mágica" no solucionará el problema.

score 1 · Answer 3

Buena pregunta! Honestamente mi opinión es "porque nadie lo hizo". Probablemente no haya mucho mercado para los desarrolladores de bases de datos, ya que los desarrolladores de sitios web que no son estúpidos ya tienen su propio código.

Dicho esto, es una muy buena idea colocar el código de seguridad (desinfección, almacenamiento secreto, desclasificación ...) en bibliotecas confeccionadas en lugar de en el lado del cliente porque significa que ahora hay uno lugar donde debe hacerse correctamente en lugar de decenas de miles ; Por supuesto, la biblioteca de la base de datos es transparente en cuanto a la forma en que las contraseñas se procesan y se procesan y ofrece valores predeterminados y opciones de personalización razonables para los desarrolladores.

Edición después de ver las respuestas de los demás: hacerlo dentro del propio servidor de base de datos podría causar más problemas de rendimiento que en la parte frontal porque los DB son menos escalables que los frontales; también significa que mantienes la "papa hirviendo" por más tiempo, ya que la contraseña de texto sin cifrar viaja desde tu servidor de aplicaciones a tu base de datos.

Sin embargo, todavía no veo cómo una biblioteca cliente a una base de datos no puede recibir una contraseña como tipo de datos y convertirla en algo picado y con sal. Sin embargo, todavía se necesitaría algún tipo de caché de contraseñas de texto simple para manejar las actualizaciones de la función hash (pero ese habría sido el caso de todos modos en el mismo proceso de usuario que ejecutaría el código de la biblioteca).

score 1 · Answer 4

La gente hace todo tipo de cosas estúpidas. Eso no significa que debamos tomar todo lo que pueda salir mal en la aplicación y delegarlo en el sistema de base de datos.

El trabajo de un sistema de base de datos es administrar datos. Por supuesto, los sistemas modernos tienen todo tipo de características adicionales que difuminan la línea entre la aplicación y la base de datos. Pero esperar que ellos manejen la autenticación de usuario de su sitio web parece un poco exagerado. Ese es el trabajo de la aplicación.

Pasar la contraseña de texto simple al sistema de la base de datos también tiene implicaciones para la seguridad: ahora debe asegurarse de que la contraseña no aparezca en el registro de consultas o sea interceptada en el camino desde el servidor web al sistema de la base de datos (a menos que están en la misma máquina).