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

Question

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, servidor de base de datos MSSQL es Windows Server 2003, corriendo 2005.

PD: No veo alguna pregunta que este duplicados, pero si hay, no dude en para cerrar esta uno.

Answer 1

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 utilizar la misma protección para cada cliente diferente. Unos pasos: -

1. crear diferentes cuentas de base de datos para diferentes sistemas que tienen acceso a su base de datos
2. Limitar el acceso a la base de datos para sólo lo que necesitan utilizar sus subvenciones de bases de datos incorporadas
3. almacenar un triple DES (o lo que sea) clave 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 tener la solicitud de una frase de paso al inicio, pero no lo hemos implementado, ya que parece una molestia y el personal de operaciones necesita saber la contraseña. Probablemente sea menos seguro.

Answer 2

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 alguna otra manera que no sea una contraseña.

Answer 3

Puede usar un algoritmo de cifrado reversible, p. 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

Answer 4

En mi antiguo lugar de trabajo que solía tener un sistema mediante el cual se cifran todas las contraseñas (usando Triple DES o lo que sea que estaban 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 en claro" como el valor, y luego nuestro código lo cargaba, encriptaba y almacenaba el valor cifrado 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 si ese era el tipo de cosas que estaba pidiendo!

Answer 5

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 Java que parecen conectarse directamente a su base de datos. ¿Es eso correcto?

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

1) Cambiar todas las aplicaciones del lado del cliente que se conectan directamente a la base de datos para ir a través de un servicio. (Si ellos tienen para 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.

Answer 6

Para las cosas java, si está utilizando un servidor de aplicaciones vea si puede definir una fuente de datos, y sus aplicaciones pueden obtener en 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.

Answer 7

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

Puede significar una pequeña migración para su personal de operaciones, pero SSO para un conjunto de aplicaciones es agradable.

Answer 8

Supongamos el siguiente escenario común:

• utiliza la misma base de código para todos los ambientes y su base de código tiene las contraseñas de base de datos para cada entorno.

• El personal (administradores de configuración de sistemas) 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 desea que nadie que tenga 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 de 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

Answer 9

El uso del cifrado 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.

Answer 10

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.