[Python-es] Python y Base de Datos

[Hernan M Foffani]

2010/3/16 Francisco Javier Cuadrado <fcocuadrado en gmail.com>

> El día 16 de marzo de 2010 12:42, Hernan M Foffani
> <hfoffani en gmail.com> escribió:
> > 2010/3/16 Soto <scots4ever en gmail.com>
> >>
> >> Parece ser que se trata de poner obstáculos al hipotético ente maléfico
> >> que trata de putearnos y que tiene que ser una puta máquina.
> >> Lo de cambiar la función de coficación me parece una idea bastante
> buena.
> >> Supongo usando eso y estableciendo permisos 600 al archivo en cuestión
> >> supondrán una buena barrera de seguridad.
> >
> > Para ser mas preciso: *la* barrera de seguridad son los permisos. La
> > codificación es para aquellos que no entienden de temas de seguridad
> tengan
> > una sensación de protección extra.
> >
>
> Lo que puede ser todavía peor, ya que «creer tener» no es lo mismo que
> «tener».
>

Creen tener y tienen, aunque por razones distintas de las que creen.
*Nunca* dije que uno fuera sustitución de lo otro.



> Creo que todo este asunto ha derivado en una serie de mensajes con
> poco sentido, ya que si no puedes proteger el acceso al archivo de la
> contraseña de la base de datos, cifrarlo u ofuscarlo no servirá de
> nada ya que podrán ir a los archivos de tu código fuente y ver qué
> haces para descifrar esa contraseña.
>
> Y creo que lo de que te quitarás un alto porcentaje de gente con bajo
> nivel aquí no vale, ya que si no tienen buen nivel para conseguir el
> código de descifrado no creo que tengan nivel suficiente para que con
> la contraseña se pongan a «jugar» con la base de datos.
>

No se trata de quitar a nadie. Si el que paga reclama mas protección porque
"¡que barbaridad! la clave está en claro", le intentas explicar que la
seguridad
no va por ahí. Si sigue con la misma cantinela, ROT13 y a por otra cosa.

Además, si hubiera un método más seguro cualquier aplicación de uso
> extendido lo usaría, pero es que las aplicaciones que hacen uso de
> bases de datos (como aplicaciones web), mantienen un archivo con la
> contraseña de la base de datos sin ningún tipo de ofuscación,
> codificación y/o cifrado. Sólo te piden que tengan el mínimo de
> permisos una vez hayas editado el archivo, es decir, sólo lectura para
> el usuario que ejecute la aplicación.
>

Si sólo te piden eso es que saben de lo hablan y no hace falta mas.

El problema, como dije antes, es cuando el cliente te dice que no es
suficiente porque "¡él puede ver la clave!". El coste de esa educación
no suele estar presupuestado y la "solución" (ROT13) es muy barata.




>
> >>
> >> Aún así seguiré investigando.
> >> Un saludo y mil gracias a todos
> >> El 16 de marzo de 2010 12:03, Hernan M Foffani <hfoffani en gmail.com>
> >> escribió:
> >>>
> >>> 2010/3/16 lasizoillo <lasizoillo en gmail.com>
> >>>>
> >>>>
> >>>> El 16 de m
> >>>>
> >>>> arzo de 2010 08:22, Soto <scots4ever en gmail.com> escribió:
> >>>>>
> >>>>> Otra opción podría ser encriptar la contraseña en un fichero. Pero
> hay
> >>>>> métodos que te permiten descriptar contraseñas con bastante rapidez
> como
> >>>>> puede ser John the Ripper.  http://www.openwall.com/john/
> >>>>>
> >>>>
> >>>> Si hay métodos para descifrar contraseñas con bastante rapidez cambia
> de
> >>>> algoritmo de cifrado. El problema no es la calidad del algoritmo de
> cifrado.
> >>>> Si puedes almacenar la contraseña de descifrado de forma segura,
> puedes
> >>>> almacenar la contraseña del mysql de forma segura. Si no puedes
> almacenar la
> >>>> contraseña del mysql de forma segura, olvidate de métodos que
> requieran
> >>>> contraseña como un algoritmo de cifrado/descifrado.
> >>>> Si no puedes usar permisos para securizar el fichero con las claves
> >>>> quedan algunas opciones (basadas en pasar el marron a otros sistemas):
> >>>>   * Usar un anillo de claves http://pypi.python.org/pypi/keyring
> >>>>   * Tratar de kerberizar tu servicio. No se hasta que punto se puede
> >>>> kerberizar mysql o tu script.
> >>>> Seguro que hay muchas más opciones. Pero a mi la de controlar los
> >>>> permisos donde estan los ficheros con las passwords me funciona
> bastante
> >>>> bien ;-)
> >>>
> >>> Exacto.
> >>> El otro gran problema es lo difícil hacer entender estos argumentos.
> >>> Cuando las discusiones se tornan interminables e improductivas, antes
> de
> >>> perder la paciencia termino por aplicar una codificación trivial a la
> clave,
> >>> por ejemplo rot13 o similar, con lo que me evito discusiones
> interminables.
> >>> Aquel que entienda verá que el sistema de seguridad usado depende de
> >>> servicios del S.O. (permisos del FS, etc.), como debe ser, y el que no
> >>> entienda nada también se quedará tranquilo.
> >>> -H.
> >>>
> >>> _______________________________________________
> >>> Python-es mailing list
> >>> Python-es en python.org
> >>> http://mail.python.org/mailman/listinfo/python-es
> >>> FAQ: http://python-es-faq.wikidot.com/
> >>>
> >>
> >> __________________________________________________________
> >>
> >> "La ocasión hay que crearla, no esperar que llegue."
> >> Francis Bacón
> >>
> >> _______________________________________________
> >> Python-es mailing list
> >> Python-es en python.org
> >> http://mail.python.org/mailman/listinfo/python-es
> >> FAQ: http://python-es-faq.wikidot.com/
> >>
> >
> >
> > _______________________________________________
> > Python-es mailing list
> > Python-es en python.org
> > http://mail.python.org/mailman/listinfo/python-es
> > FAQ: http://python-es-faq.wikidot.com/
> >
> >
>
>
>
> --
> Saludos
>
> Fran
> _______________________________________________
> Python-es mailing list
> Python-es en python.org
> http://mail.python.org/mailman/listinfo/python-es
> FAQ: http://python-es-faq.wikidot.com/
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20100316/6470d615/attachment.html>