Re: Encriptar campo

Yo pienso que te estas complicando mucho con la solución.

En primera no deberia haber nadie que accese a tu base de datos, debes
ponerle alguna contraseña fuerte para que sea dificil obtenerla por fuerza
bruta. Ahora si es realmente necesario que otros accesen a la bd para traer
alguna otra información, pues crea usuarios restringidos, que no puedan
leer la tabla donde almacenas la información de los documentos.

Si piensas que aun así te pudieran robar las credenciales de los usuarios
privilegiados para ver esa información, entonces no te sirve de mucho
encriptar pues tambien se podrian apodar de la llave para desencriptar.

En conclusión creo que debes solucionar un problema de seguridad, no de
encriptado.

Saludos

2013/2/28 Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>

> Conrado Blasetti escribió:
> > Gente, buenos días.
> >
> > Estoy trabajando sobre Win7 con una app desktop con c# (.net) y
> PostgreSQL 9.0.
> > Tengo una tabla con un campo del tipo character varying(20), el cual
> representa un Nro de Documento (Argentina).
> > Necesito encriptar este campo de manera tal que, desde la base de datos,
> no pueda ser legible y que solo pueda ser consumida desde la misma app
> desktop.
> >
> > El campo será indexado y de busquedas constantes.
> > Qué tipo de encryptado o técnica me sugieren?
>
> Este es un problema bastante complejo que requiere pensar muy bien antes
> de hacer nada. Lo que estás diciendo básicamente es que quieres que en
> la BD la info esté cifrada, y que no se pueda obtener el valor sin
> cifrar mirando sólo la BD. Es decir, la llave de cifrado debe estar en
> la aplicación. Entonces la aplicación debe extraer el valor cifrado
> desde la BD, y descifrarlo a posteriori *sin involucrar a la BD para esto*.
>
> Una de las primeras cosas que tienes que preguntarte cuando tratas con
> temas de cifrado es cómo manejarás las llaves. ¿Qué pasa si la llave se
> filtra y necesitas cambiarla? En la BD tendrás que cambiar todos los
> valores almacenados, pero necesitas saber cuáles valores están cifrados
> con la llave antigua y cuáles con la llave nueva ... de lo contrario una
> caída en medio del cambio resultará catastrófica (recuerda que no puedes
> pasarle la llave a la BD para hacer un UPDATE masivo, por lo tanto
> tienes que cambiar una por una). En conclusión, de alguna forma debes
> almacenar una "versión de llave" junto con los valores. La aplicación
> debe almacenar todas las llaves con su versión.
>
> (Observa que lo anterior no aplica sólo a llaves que se filtran;
> deberías tener una política de crear llaves nuevas en forma periódica)
>
> El tema de las búsquedas usando los valores cifrados es simple: la
> aplicación debe pasar el valor cifrado a buscar. Obviamente no puedes
> darle un prefijo del valor, es decir búsquedas con LIKE o similares son
> imposibles; todo eso deberás implementarlo en la aplicación, de ser
> necesario.
>
> ¿Cómo harás respaldos? De la BD es fácil, porque no hay nada que
> esconder dado que los datos están todos cifrados; pero el almacén de
> llaves de la aplicación es muy delicado.
>
> El tema de si usarás un algoritmo de cifrado simétrico o asimétrico no
> es súper relevante. Procura usar un algoritmo moderno, quizás alguno de
> NESSIE (posiblemente AES/Rijndael).
>
> --
> Álvaro Herrera http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
> -
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org
> )
> Para cambiar tu suscripción:
> http://www.postgresql.org/mailpref/pgsql-es-ayuda
>

--
Lindolfo Iván Perales Mancinas
Solo existen 10 tipos de personas en el mundo, las que saben binario y las
que no.