¿Es un riesgo de seguridad el envío de contraseñas de texto plano a una base de datos de SQL Server?

SQL Server tiene la opción de cifrar la conexión entre la aplicación y la base de datos . Cuando opera el servidor SQL en un entorno no confiable, se recomienda que lo habilite. Cuando lo haga, no será necesario codificar las contraseñas antes de enviarlas a la base de datos, siempre y cuando confíe en su administrador de base de datos.

Además, la mayoría de las implementaciones del servidor SQL tendrán un servidor de aplicaciones en una DMZ y el servidor SQL en la LAN, lo que significa que opera en un entorno confiable. A menos que tenga un estándar de seguridad muy alto, no tener cifrado no sería un gran riesgo de seguridad.

No confíes en nadie. Use cadenas seguras para mantener las contraseñas de texto sin formato y las modifique de forma inmediata. Se acabaron los tiempos en los que puedes esperar que tu sistema esté seguro. No lo es. Es solo cuestión de tiempo / dinero hasta que un atacante determinado pueda acceder a su sistema.

Incluso cuando el tráfico se encripta con SSL / TLS, se pueden presentar varios escenarios, cada uno de los cuales genera una pérdida de contraseñas, por ejemplo

• El gobierno captura el tráfico SSL y "solicita muy bien" una clave privada para descifrarlo. ¿Está todo en una red privada? ¿Está seguro de que no hay ninguna replicación configurada fuera del sitio?
• Su organización instala hardware que realiza descifrado de SSL en el medio para detectar qué tráfico de SSL atraviesa su red. De repente, más personas, hardware y software están involucrados, ¿confías en ellos? ¿No se ha instalado o quizás aún no?
• El servidor que contiene las claves privadas de SSL se piratea y la clave se filtra. En privado. En silencio.
• A un empleado descontento se le paga para copiar la clave privada y venderla al competidor

Sí, hay una variedad de riesgos o aumentos de riesgo aquí.

En primer lugar, ya sea que se pueda confiar en su DBA o no, deben poder decirle honestamente a cualquier auditor (o investigador reglamentario o abogado) que no, no es posible que se hicieran pasar por el usuario X, porque nunca fueron , siempre capaz de ver la contraseña del usuario X incluso si lo deseaban, e incluso si utilizaron su copia de la clave privada del servidor y un detector de paquetes.

En segundo lugar, si tiene contraseñas de hash en el servidor, debe:

• Lea la respuesta canónica ¿Cómo hacer hash de forma segura las contraseñas? por Thomas Pornin, que se reduce a "Usar BCrypt , SCrypt, o PBDF2 ".
  • Con un número tan grande de iteraciones como puede manejar bajo carga pico.
  • Con una longitud de salida que no sea más larga que la longitud de salida primitiva de hashing base.
• Ya que se trata de SQL Server, vea mi propia pura implementación de T-SQL PBKDF2 .
  • Tenga en cuenta que es terriblemente lento en comparación con las implementaciones reales, en particular las implementaciones de ataques como oclHashcat.
• Consulte oclHashcat para conocer las velocidades actuales de ataque fuera de línea de una sola máquina y múltiples GPU. Esto es lo que usarán los atacantes, los investigadores y los concursantes de la competencia de cracking después de que obtengan una copia de sus contraseñas de hash de alguna vulnerabilidad del front-end, o una computadora portátil con una base de datos en ella, o (elija su escenario favorito aquí). li>
• Tenga en cuenta, basándose en lo anterior, que cualquiera que sea su aplicación, puede usar muchas más rondas de BCrypt, SCrypt o PBKDF2 para controlar la contraseña que la base de datos de SQL Server durante la misma cantidad de tiempo de cálculo.
  • y casi siempre es más fácil y económico agregar más potencia de front-end al escalar que lo que es agregar más potencia de SQL Server.

Tenga en cuenta que una variedad de implementaciones de PBKDF2 se encuentran en mi repositorio de Github , incluido una variante de C # basada en el trabajo de Jither, que Jither lanzó bajo la licencia MIT.

Depende de la confiabilidad del medio ambiente. Si no tiene confianza en ello, quizás algún cifrado sería bueno. Además, el conjunto de configuración de rama baja probablemente sería restringir solo a los hosts que requieren conectividad SQL, aunque hay muchas razones diferentes por las que querría abrirlo para acceder.

TLDR : siempre que la conexión de red a la base de datos sea segura, y mientras los hashes con sal estén almacenados en sus tablas, llamar a un procedimiento almacenado con una contraseña de texto simple es correcto. Creo que su tiempo y esfuerzo se emplean mejor protegiendo la base de datos del acceso no autorizado del tipo que hace posible obtener un seguimiento de las llamadas a procedimientos almacenados.

Primero, entiendo que el escenario en cuestión es que un atacante puede recuperar la contraseña de texto simple revisando los valores de parámetros pasados al procedimiento almacenado, uno de los cuales es la contraseña de texto simple, y luego usar esa contraseña para comprometer una cuenta de usuario en su aplicación.

Si eso es correcto, entonces la única solución puramente técnica que veo es implementar un esquema de PK dentro del alcance del procedimiento almacenado, de modo que la contraseña se debe cifrar con la clave pública del procedimiento almacenado, el texto cifrado se transfiere al procedimiento, y el valor del parámetro, a continuación, descifrado por el propio proceso almacenado con una clave privada antes de ser utilizado. (O mejor, como TLS en sí mismo, podría negociar un intercambio Diffie-Hellman usando otros procedimientos almacenados, y usar una clave de sesión). A menos que pueda encontrar alguna implementación de código abierto de esto por ahí, en la que confíe, y la use, Esto será un levantamiento muy pesado. Y ahora tienes que proteger esa clave privada.

Pero considera de lo que realmente estás tratando de protegerte. En este escenario, el atacante puede leer sus llamadas a procedimientos almacenados y obtener los valores pasados. ¿Cualquier usuario con este privilegio también tendría acceso de lectura a cualquier clave privada que use, o seleccionará / insertará / actualizará el acceso a sus tablas? Si es así, incluso si pasas por el trabajo de implementar PKI en el nivel del procedimiento almacenado, tus esfuerzos se derrotarán instantáneamente.

También permítame responder específicamente a la idea de crear hash de la contraseña, por supuesto, con una sal, y pasar el valor de hash al procedimiento almacenado. Si haces esto, entonces el valor hash es ahora la contraseña. Todo lo que un atacante tiene que hacer, si realmente puede leer los parámetros proc almacenados, es repetir esos parámetros exactamente como los ve para comprometer el sistema. En realidad, no necesita revertir el hash y aprender cuál es la contraseña "simple"; el valor hasheado es la contraseña de texto sin formato ahora. Así que este esquema no tiene efecto.