database - pound - ¿Cuál es la mejor manera de mantener las contraseñas configurables, sin tenerlas fácilmente disponibles para el lector humano casual?

i have been pound (10)

En mi antiguo lugar de trabajo solíamos tener un sistema por el cual todas las contraseñas estaban encriptadas (usando Triple DES o lo que estábamos usando en ese momento). Las contraseñas a menudo se almacenaban en archivos de propiedades (esto era en un sistema Java).

Cuando era necesario cambiar la contraseña, simplemente podíamos usar "! Texto plano" como el valor, y luego nuestro código lo cargaba, encriptaba y almacenaba el valor encriptado en el archivo de propiedades.

Esto significaba que era posible cambiar la contraseña sin saber cuál era el valor original, ¡no estoy seguro de si ese era el tipo de cosa que estaba pidiendo!

Tengo una base de datos a la que se conectan muchas aplicaciones de cliente diferentes (una combinación de servicios web, algunas aplicaciones de Java y algunas aplicaciones de punto neto). No todos estos se ejecutan en Windows (lamentablemente, de lo contrario, sería una pregunta de respuesta fácil con solo habilitar la autenticación de Windows para conexiones de bases de datos). Por el momento, las contraseñas se almacenan en varios archivos de configuración / propiedades que se encuentran alrededor de los sistemas. Idealmente, solo el personal de soporte tiene acceso a los servidores donde se ejecutan los archivos, pero si alguien más obtiene acceso a uno de los servidores, tendrían suficientes permisos de base de datos para obtener un buen número de datos tal como están ahora.

Mi pregunta entonces, ¿cuál es la mejor manera de mantener las contraseñas configurables, sin tenerlas demasiado fácilmente disponibles para el lector humano casual?

Editar Solo para aclarar, el servidor de bases de datos es Windows Server 2003, que ejecuta MSSQL 2005.

PD: No veo ninguna pregunta que esto duplique, pero si las hay, siéntanse libres de cerrar esta.

La autenticación NTLM o la autenticación basada en LDAP (Active Directory) deberían estar disponibles para usted con un poco de esfuerzo. Esto le permitiría usar su "autenticación de Windows" en todas las aplicaciones.

Puede significar un poco de migración para el personal de operaciones, pero SSO para un conjunto de aplicaciones es bueno.

No use contraseñas, la autenticación de servidor a servidor generalmente se puede realizar utilizando un archivo de clave o un certificado de cliente o de otra manera que no sea una contraseña.

Para las cosas java, si está utilizando un servidor de aplicaciones, vea si puede definir una fuente de datos, y sus aplicaciones pueden acceder a la fuente de datos usando JNDI. De esta forma, la administración de la fuente de datos (incluidos los detalles de la conexión) es manejada por el servidor de aplicaciones, y el código de la aplicación tiene que ver con solicitar una fuente de datos.

Parece que no hay una respuesta fácil (debido a los diferentes tipos de aplicaciones que se conectan) ... realmente, el único problema que veo son las aplicaciones de Java que parecen conectarse directamente a su base de datos. ¿Es eso correcto?

Si es así, esto es lo que puedes hacer:

1) Cambie las aplicaciones del lado del cliente que se conectan directamente al DB para pasar por un servicio. (Si tienen que conectarse directamente, al menos déles un primer paso para "obtener contraseña" de un servicio, luego pueden conectarse directamente).

2) Almacene las contraseñas en el archivo web.config (si elige hacer servicios web .Net), y luego encripte la sección "cadenas de conexión" del archivo.

Puede usar un algoritmo de cifrado reversible, por ejemplo, Blowfish, para almacenar las contraseñas como una medida provisional. Debería haber una cantidad de librerías gratuitas que puede usar para construir esto en todos sus programas que necesitan este acceso.

La página de Bruce Schneier en Blowfish

Artículo de Wikipedia sobre Blowfish

Sí, tengo que aceptar la opción de almacenar los hashes (salados). Recomendaría un hash SHA256 (salado) de la contraseña almacenada en la base de datos. Además, no olvide aplicar las reglas de contraseña segura.

Supongamos el siguiente escenario común:

Utiliza la misma base de código para todos los entornos y su base de código tiene las contraseñas de la base de datos para cada entorno.
El personal (administradores de sistemas, administradores de configuración) que tienen acceso a su servidor de aplicaciones de producción puede conocer las contraseñas de la base de datos de producción y nadie más.
No quiere que nadie con acceso al código fuente sepa cuáles son las contraseñas de producción.

En un escenario como este, puede encriptar y almacenar las contraseñas de producción en los archivos de propiedad que su aplicación. Dentro de la aplicación puede incluir una clase que lea las contraseñas del archivo de propiedades y las descifre antes de pasarlas al controlador de la base de datos. Sin embargo, la clave y el algoritmo utilizados para descifrar la contraseña no son parte del código fuente, sino que pasan a la aplicación como una propiedad del sistema en tiempo de ejecución. Esto desacopla el conocimiento de la clave del código fuente de la aplicación y cualquiera que tenga acceso solo al código fuente de la aplicación ya no podrá descifrar la contraseña porque no tiene acceso al entorno de ejecución de la aplicación (servidor de aplicaciones).

Si está utilizando Java, eche un vistazo a this para obtener un ejemplo más concreto. El ejemplo usa Spring y Jasypt. Estoy seguro de que algo así se puede extrapolar a otros entornos, como .Net

Supongo que quiere ocultar las contraseñas de los observadores casuales. Si fueran observadores malvados y con ojos de acero con acceso a todo el código fuente en una de las máquinas que se conectan, entonces pueden obtener la contraseña con un poco de ingeniería inversa.

Recuerde que no necesita usar la misma protección para cada cliente diferente. Algunos pasos:

Crea diferentes cuentas de base de datos para diferentes sistemas que acceden a tu base de datos
Limite el acceso en la base de datos a solo lo que necesitan utilizando su base de datos incorporada GRANTs
Almacene una clave DES triple (o lo que sea) dentro de una clase de administrador de contraseñas en su base de datos. Use esto para descifrar un valor encriptado en su archivo de propiedades.

También hemos considerado solicitar la solicitud de una contraseña al inicio, pero no la hemos implementado, ya que parece una molestia y el personal de operaciones necesita saber la contraseña. Probablemente sea menos seguro.

Usar encriptación no es una buena idea. Si alguien pone en peligro la clave, puede descifrarla. Use un algoritmo hash con sal para almacenar contraseñas. Los algoritmos Hash son de una sola manera, por lo que no son reversibles. Pero son vulnerables a ataques de diccionario, así que use sal (texto sin formato concatenario con algo largo y detallado que lo hash). También protege la base de datos contra ataques internos.