Re: encriptacion de datos

nota, el MD5 que es el punto final fue roto hace tiempo, pero no es un
punto a tratar aquí, tienes razón sobre enviar md5 por la red, si
sniffean solo veran la clave en formato md5, supuse que estabas usando
un podelo de tres capas y desde el cliente le envias la clave al motor
transaccional (webserver o similar), y el motor a su ves se conectaba
a la base de datos.

Ahora para las paginas web, hay un java script que te envia el md5 del
password, pero el punto es otro, si tienes el md5 de la password por
fuerza bruta te la pueden sacar. (ahora el punto si el sistema no
mueve plata no es critico el tema del como hacerlo seguro).

Pero si puedes conectarte via canal ssl usando

Pegale una mirada a estos dos link, ya los debes conocer, ignoro si
son viejos o no, ya no desarrollo desde hace un buen tiempo :(

http://www.freedownloadmanager.org/downloads/postgresql_info/
http://www.abcdatos.com/programas/programa/l4404.html

El 14/09/05, Siciliano, Pablo E.<psiciliano(at)puentenet(dot)com> escribió:
> Hola a todos,
>
> Sobre eso, esta bien que una persona pueda ver los datos que se van a
> proteger sniffeandolos si el canal no es seguro. Pero tengan en cuenta de
> que muchas cosas se hacen para evitar escaladas de privilegios.
>
> ¿Para que me voy a molestar en guardar las claves encriptadas, si alguien
> que tenga acceso a mi db de todos modos ve los datos?
> Para que, por ejemplo el administrador del sistema no pueda escalar
> privilegios sin que quede escrachado en campos de auditoría si es que los
> tengo.
> Si yo no guardo claves encriptadas, el se puede loguear DE MODO COMUN como
> cualquier usuario. En cambio, si por ejemplo el debe cambiar el password
> para loguearse, eso va a quedar registrado en otros lugares. De hecho,
> podría no tener mas que un usuario con permisos de lectura. Obviamente,
> ningún sistema es perfecto, ninguno es inviolable, pero ¿Para que vamos a
> hacer facil el romperlo, si hacerlo mas robusto cuesta tan poco?
>
> El otro caso es ¿No me pueden sniffear las claves si no me molesto en
> transmitirlo por un canal seguro? Si. Y evidentemente sería mejor usar un
> canal seguro. Pero, si por alguna extraña razón no se puede, ¿No sería mejor
> cambiar:
>
> INSERT INTO clave(usuario,password)VALUES ('pepe',md5('hola'))
>
> Por:
>
> INSERT INTO clave(usuario,password)VALUES
> ('pepe','4d186321c1a7f0f354b297e8914ab240')
>
> Eso se logra haciendo el md5 (En este caso Delphi) en el cliente, como hacen
> muchas aplicaciones. Con eso me protejo de que alguien use canales normales
> para conocer las claves.
>
> De hecho, mejor que eso, se puede pensar un poquitín mas y plantear una
> estructura en donde haya un reto, y se tenga que responder a ese reto para
> loguearse. De ese modo no bastaría con conocer el md5() de la clave para
> loguearse. Hace un tiempo salió un thread muy explicativo al respecto, sobre
> como es el mecanismo de identificación de los clientes de Postgresql.
>
> Otra cosa. No soy ni remotamente un entendido en criptografía (De hecho no
> me puedo considerar ni principiante en el tema), pero por las últimas cosas
> que leí, sería una buena idéa tomar además o en vez de md5, sha2. Si bien
> md5 todavía no fue roto y se lo considera seguro para muchas cosas, hay
> algunas noticias inquietantes acerca de métodos para facilitar el encuentro
> de coliciones.
>
> Saludos!
> Pablo E. Siciliano.
>
>
> ----- Original Message -----
> From: "Horacio Miranda" <hmiranda(at)gmail(dot)com>
> To: "Leonel Nunez" <lnunez(at)enelserver(dot)com>; <pgsql-es-ayuda(at)postgresql(dot)org>
> Sent: Wednesday, September 14, 2005 10:05 AM
> Subject: Re: [pgsql-es-ayuda] encriptacion de datos
>
>
> ademas si no usas una capa ssl en la comunicacion del password, da lo
> mismo que mecanismo uses para almacenar el password,
>
> El 14/09/05, Leonel Nunez<lnunez(at)enelserver(dot)com> escribió:
> > Victor Montenegro Isidin wrote:
> >
> > >¿ Como puedo guardar las claves encriptadas en una tabla?
> > >
> > >Almacenando el hash de la clave. Un hash es una función en
> > >un sólo sentido, es decir no hay una función inversa para
> > >obtener la clave a partir del hash. Cuando el usuario
> > >introduce el password por 1ra vez, calculas el hash y lo
> > >almacenas, posteriormente cuando el usuario se va a
> > >autenticar, calculas nuevamente el hash del password
> > >ingresado y lo comparas con el valor almacenado.
> > >
> > >Uno de los algoritmos de hash más utilizados es md5.
> > >
> > >¿ que tipo de dato debo usar para el campo?
> > >
> > >char de tamaño 32
> > >
> > >¿ que funcion debo utilizar para encriptar?
> > >
> > >md5 ()
> > >
> > >¿ cual funcion es la mejor ?
> > >
> > >De nuevo, md5(), yo recomiendo almacenar el hash del username
> > >concatenado con el password concatenado con una secuencia
> > >concatenado con un valor fijo, de manera que en caso de que
> > >logren acceso a tu base de datos (sql injection o lo que sea),
> > >e intercambian los passwords de 2 usuarios o bien calculan un
> > >hash y lo almacenen en el campo password, el usuario no pueda
> > >ser autenticado.
> > >
> > >En la práctica:
> > >
> > >Almacenar el password:
> > >
> > >insert into usuarios (id,login,password) values
> > >(nextval('secuencia'),login,md5 ('password' || 'login' ||
> > >currval('secuencia')|| 'tuvalorfijo' ) );
> > >
> > >Autenticar al usuario:
> > >
> > >select id from usuarios where password = md5('password_insertado' ||
> > >'login_insertado' || id || 'tuvalorfijo' ) and login =
> > >'login_insertado';
> > >
> > >
> > >
> >
> > Creo que si alquien puede entrar a tu base de datos de las formar que
> > comentas, no importa mucho como tengas encriptado ese password
> >
> >
> > Leonel
> >
> > ---------------------------(fin del mensaje)---------------------------
> > TIP 5: ¿Has leído nuestro extenso FAQ?
> >
> > http://www.postgresql.org/files/documentation/faqs/FAQ.html
> >
>
>
> --
> Saludos Horacio Miranda.
> RedHat Certified Engineer.
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 3: si publicas/lees desde Usenet, por favor envía "subscribe-nomail"
> a majordomo(at)postgresql(dot)org para que tus mensajes puedan llegar
> a los suscriptores de la lista
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.10.25/102 - Release Date: 2005/09/14
>
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 3: si publicas/lees desde Usenet, por favor envía "subscribe-nomail"
> a majordomo(at)postgresql(dot)org para que tus mensajes puedan llegar
> a los suscriptores de la lista
>

--
Saludos Horacio Miranda.
RedHat Certified Engineer.