Password encriptado en database.yml

Necesito guardar en forma encriptada el password de la base de datos en
database.yml.
Asumo que asimismo necesito parchar alguna funcion de activerecord (u
otra
clase, o la función que lee de database.yml) para que antes de pasarle el
password a connect() lo desencripte correctamente.

Investigué antes de formular esta pregunta, ya conozco la práctica de
llamar la función desencriptadora desde el database.yml:

production:
adapter: oci
username: usuario
password: <%= desencriptar(‘password’) %>
host: host

Pero así no me sirve, ya que cualquiera que tenga acceso a los fuentes
puede entrar a >ruby script/console, ejecutar “desencriptar(‘password’)”
y
averiguar el password en un dos por tres (6 :).

Parchar connect() o la función que lee de database.yml me parece más seguro.

Gracias de antemano.

On Feb 9, 2007, at 9:49 PM, Esteban wrote:

llamar la función desencriptadora desde el database.yml:
averiguar el password en un dos por tres (6 :).

Parchar connect() o la función que lee de database.yml me parece
más seguro.

El fichero se carga en initializer.rb, en el metodo
database_configuration. Seria cuestion de meter Rails en vendor con
ese parche.

En ese caso la informacion sigue estando disponible en consola
inspeccionando el valor de

ActiveRecord::Base.configurations

pero yo creo que si un tipo es capaz de saber eso tambien sera capaz
de buscar la desencriptacion mas cerca del establecimiento de
conexion, asi que ya es el nivel de indireccion que se quiere.

– fxn

Redefiniendo database_configuration me ahorré tener que modificar los
fuentes de Rails (gracias Xavier)

class Rails::Configuration
alias old_database_configuration database_configuration

def database_configuration
c = old_database_configuration
[‘development’, ‘production’, ‘test’].each do |env|
password = c[env][‘password’]
c[env][‘password’] = Mi_Clase.desencriptar(password) if password
end
c
end
end

Esto puede agregarse en boot.rb, environment.rb

O si solo se quiere encriptar el password de produccion entonces en
environments/production.rb ponemos

class Rails::Configuration
alias old_database_configuration database_configuration

def database_configuration
c = old_database_configuration
password = c[‘production’][‘password’]
c[‘production’][‘password’] = Mi_Clase.desencriptar(password) if
password
c
end
end

On 2/9/07, Sebastian D. [email protected] wrote:

 Base64.decode64(self).unpack("s*").map{ |e| key += 1; e -=

end
def database_configuration

On Feb 9, 2007, at 9:49 PM, Esteban wrote:

Investigué antes de formular esta pregunta, ya conozco la
fuentes


Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es

Solo decir que la solución que presentas tiene la misma seguridad que
tener la contraseña en claro, ya que aún tienes acceso a la función de
desencriptación y a la contraseña encriptada (y la clave, que está en
esa función o se le pasará en algún momento en el código). Las
soluciones que propones sólo ofrencen falsa seguridad.

La única forma de proteger la contraseña de database.yml es utilizar
una contraseña aleatoria única y proteger el archivo con los permisos
correctos (únicamente lectura para el usuario que ejecutará la
aplicación, p. ej. www-data).

Recomiendo el párrafo “Password encryption in .fetchmailrc” de
http://www.catb.org/~esr/fetchmail/design-notes.html (más o menos en
el 1/4 de la página).

La idea de “obfuscar” la contraseña no es ofrecer falsa seguridad. Es
minimizar el riesgo que alguién la vea por sobre tus hombros si
tienes el archivo abierto.

Puedes proteger tus archivos todo lo que quieras, pero si tienes que
editarlo y en ese momento pasa detras de ti una persona, podría ver
la contraseña en tu pantalla. Y no siempre es posible usar una
contraseña aleatoria (que tendria el mismo efecto de hacerla dificil
de memorizar en 2 segundos).

La “obfuscacion” tambien puede usarse para proteger la privacidad de
los usuarios. Las contraseñas de usuarios siempre deberian
almacenarse con encripción unidireccional (md5 con salt, por ejemplo)
pero hay ciertos atributos que podrias preferir mantenerlos visibles,
pero no tan visibles. El usuario puede querer ver la respuesta a
“quien es la persona que mas odias” pero eso no significa que es una
buena idea permitir que todos tus programadores vean las respuestas
de todos tus usuarios aun por accidente. Podrias considerar la
“obfuscacion” como una ayuda a ti mismo y tus colaboradores para
evitar la tentación de ver los secretos de los demas. Es como una
cortina en frente de la letrina :slight_smile: Sabes lo que esta haciendo la
persona detras de la cortina, y podrias abrirla sin hacer el menor
esfuerzo, pero prefieres dejarla cerrada por comodidad, modestia y
respeto.

Pero tienes mucha razon. Es importante tener claro que la obfuscacion
no es mas que eso, una cortina, no es siquiera una puerta con una
llave barata, no es un mecanismo de seguridad. Repito: NO ES UN
MECANISMO DE SEGURIDAD, es un mecanismo de comodidad, para no tener
que estar mirando sobre tu hombro cada vez que quieras abrir un
archivo ni tener que asegurarte que nadie te este espiando.

On Feb 9, 2007, at 9:15 PM, Daniel R. Troitiño wrote:

Por si les interesa o les resulta util, aqui esta nuestra
implementacion del “Mi_Clase.desencriptar” :

class String
def obfuscate(key = 1337)
Base64.encode64(self.unpack(“C*”).map{ |e| key += 1; e +=
key }.pack(“s*”))[0…-2] # base64 adds an extra \n we don’t need
end

def clarify(key = 1337)
Base64.decode64(self).unpack(“s*”).map{ |e| key += 1; e -=
key }.pack(“C*”)
end
end

On 2/10/07, Sebastian D. [email protected] wrote:

La “obfuscacion” tambien puede usarse para proteger la privacidad de
persona detras de la cortina, y podrias abrirla sin hacer el menor

Sí, eso es lo que intentaba decir, y veo que lo entedías
perfectamente, siento habertelo recordado. En el caso que planteas
(ofuscar para que no sea visible a simple vista) es un mecanísmo
totalmente válido.