Datos criptograficos en una columna de sql

Hola Jose Antonio:
Me parece que podrias enviarlo a un campo BINARY del tamano apropiado.
Encriptar contrasenas y guardarlas en tablas de SQL es una practica poco
recomentable. En principio lo mejor y mas facil seria usar los usuarios de
Active Directory.
Si no es posible trata de NO almacenar la clave y almacena un HASH de la
llave y comprueba que la clave que suministra el usuario genere el mismo
HASH, pero sin guardar nunca la clave.
Las tecnicas de encriptacion hacen dificil pero no imposible obtener la
informacion escondida. Pero con el tiempo, la capacidad de proceso de las
computadoras aumenta sensible (se duplica cada 18 meses Aprox), y lo que
antes te tomaba 1 mes en encontrar te toma 4 dias en solo 5 anos.
Saludos,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"Jose Antonio" wrote in message
news:uR$

En una tabla de usuarios en sql server, necesito encriptar la columna de

la

contraseña.

Estoy criptografiando los datos con una clase de clave privada de .Net, le
envio la cadena con al contraseña y me devuelve una cadena unicode con la
contraseña criptografiada.

El problema lo tengo cuando esta cadena es insertada en la base de datos

ya

que me pone en la columna contraseña varios interrogaciones '???????????'.

He provado a utilizar varchar, nvarchar,text,ntext y no me funciona.

¿Como puede insertar en la base de datos esta cadena criptografiada?.


Saludos.

"Javier Loria" wrote in message news:...

Hola Jose Antonio:
Me parece que podrias enviarlo a un campo BINARY del tamano apropiado.
Encriptar contrasenas y guardarlas en tablas de SQL es una practica poco
recomentable. En principio lo mejor y mas facil seria usar los usuarios de
Active Directory.
Si no es posible trata de NO almacenar la clave y almacena un HASH de la
llave y comprueba que la clave que suministra el usuario genere el mismo
HASH, pero sin guardar nunca la clave.

Y sin olvidar utilizar el *salt* correspondiente.

Las tecnicas de encriptacion hacen dificil pero no imposible obtener la
informacion escondida. Pero con el tiempo, la capacidad de proceso de las
computadoras aumenta sensible (se duplica cada 18 meses Aprox), y lo que
antes te tomaba 1 mes en encontrar te toma 4 dias en solo 5 anos.

Esto es irrelevante, aunque se duplicara cada mes o cada día.

Para que te hagas una idea, segun Bruce Schneider en el 96 a la
supercomputadora más potente le llevaría 500.000 años (si, están bien
los 7 ceros) encontrar la clave de un mensaje cifrado con una clave de
64 bits, por aquel entonces la norma era de 128 bits, hoy en dia un PC
no se inmuta utilizando claves de 256 o 512 bits.

y si se utiliza cifrado asimétrico, con una simple clave de 128 bits,
hoy se usan de 2048 o 4096 bits sin problema, según un estudio de la
universidad de Berkeley del 97 con 250 workstation de la época se
tardaría 9 billones (trillones americanos) de veces la edad del
universo de media (no se cómo es de viejo es el universo, pero no es
muy joven) y si los 29.634 estudiantes hicieran lo mismo tardarían
100.000 millones de veces la edad del universo de media.

divídase el tiempo por el incremento de potencia y múltiplíquese por
la complejidad de las claves actuales y se verá ahora es incluso más
complicado.

Desafortunadamente el chantaje, las amenazas o la estupidez de la
gente son mecanismos mucho más eficaces.

Un saludo.

Saludos,

Hola:
Comparto tus comentarios, pero lo efectivo de la llave, dependera del
algoritmo. Si hablas de algoritmos reconocidos comparto tu argumento, cuando
vi que Jose Antonio menciona una clase privada me inmagine un algoritmo
generado por el. Normalmente estos se quiebran con relativa facilidad y
estan sujetos a mi comentario inicial.
Saludos,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"el emperador" wrote in message
news:

"Javier Loria" wrote in message

news:...

> Hola Jose Antonio:
> Me parece que podrias enviarlo a un campo BINARY del tamano

apropiado.

> Encriptar contrasenas y guardarlas en tablas de SQL es una practica

poco

> recomentable. En principio lo mejor y mas facil seria usar los usuarios

de

> Active Directory.
> Si no es posible trata de NO almacenar la clave y almacena un HASH

de la

> llave y comprueba que la clave que suministra el usuario genere el mismo
> HASH, pero sin guardar nunca la clave.

Y sin olvidar utilizar el *salt* correspondiente.

> Las tecnicas de encriptacion hacen dificil pero no imposible obtener

la

> informacion escondida. Pero con el tiempo, la capacidad de proceso de

las

> computadoras aumenta sensible (se duplica cada 18 meses Aprox), y lo que
> antes te tomaba 1 mes en encontrar te toma 4 dias en solo 5 anos.

Esto es irrelevante, aunque se duplicara cada mes o cada día.

Para que te hagas una idea, segun Bruce Schneider en el 96 a la
supercomputadora más potente le llevaría 500.000 años (si, están bien
los 7 ceros) encontrar la clave de un mensaje cifrado con una clave de
64 bits, por aquel entonces la norma era de 128 bits, hoy en dia un PC
no se inmuta utilizando claves de 256 o 512 bits.

y si se utiliza cifrado asimétrico, con una simple clave de 128 bits,
hoy se usan de 2048 o 4096 bits sin problema, según un estudio de la
universidad de Berkeley del 97 con 250 workstation de la época se
tardaría 9 billones (trillones americanos) de veces la edad del
universo de media (no se cómo es de viejo es el universo, pero no es
muy joven) y si los 29.634 estudiantes hicieran lo mismo tardarían
100.000 millones de veces la edad del universo de media.

divídase el tiempo por el incremento de potencia y múltiplíquese por
la complejidad de las claves actuales y se verá ahora es incluso más
complicado.

Desafortunadamente el chantaje, las amenazas o la estupidez de la
gente son mecanismos mucho más eficaces.

Un saludo.

> Saludos,
>

"Javier Loria" wrote in message news:...

Hola:
Comparto tus comentarios, pero lo efectivo de la llave, dependera del
algoritmo. Si hablas de algoritmos reconocidos comparto tu argumento, cuando

La ventaja de esos algoritmos es que son abiertos, aunque en algunos
casos tengas que pagar regalías, y cualquiera puede hacer una
implementación, sin tener que comprar una en concreto o bin porque no
exista una situación especial.

vi que Jose Antonio menciona una clase privada me inmagine un algoritmo
generado por el. Normalmente estos se quiebran con relativa facilidad y
estan sujetos a mi comentario inicial.

Tienes toda la razón, aquí en España hay un herramienta de desarrollo
que se llama Velázquez Visual, hablando con uno de los desarrolladores
me comenta que el protocolo de red que utilizan es segurísimo, que
todo va encriptado y además como comprime pues es muy rápido. Cuando
le pregunto por la bibliotecas que utilizan me dice que es de
desarrollo propio, viendo las orejas al lobo le pregunto cual es el
algoritmo utilizado a lo que me responde que es secreto. Que es un
ejemplo claro de "Security Through Obscurity". O el caso de un
directivo que preocupado por el reglamento de seguridad pregunta a la
empresa proveedora si son seguras las comunicaciones, esta lo que hace
es enseñarle las tramas de red capturadas con un *sniffer* y en
hexadecimal, posteriormente en una reunión para justificar al
proveedor le dice a sus jefes, "Es segurisimo, no dios que lo
entienda".

Un saludo.

Saludos,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

Precisamente por ser algoritmos propietarios pueden ser mas dificiles de
descifrar, si estos son implementados correctamente. Desde los mas simples
(sumar un numero, operaciones a bits (Or, Xor, etc), transposicion de
Tablas, etc).

Por mi parte sugiero transponer una serie de valores no relacionados. (Por
ejemplo, podria sumar a cada valor ASCII del mensaje el valor de cada letra
en la pagina 385 del Quijote, segun coincidan respectivamente, al finalizar
reinicio nuevamente). Y asi lo puedo dificultar aun mas, por ejemplo tomando
a partir del 2do parrafo y al resultado realizarle una operacion a bits, y
al resultado trasponiendolo en una tabla.

O porque no utilizar una foto llave?, donde cada pixel sera el valor a
trasponer a cada caracter de nuestro mensaje a encriptar. Se complicaria mas
si la persona a obtener el mensaje seria la unica a saber el renglon y
columna de pixel donde inicia la llave.


bueno, realmente este es todo un tema, muy apasionado por cierto.


Saludos,


Antonio Ortiz Ramirez
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com



"el emperador" escribió en el mensaje
news:

"Javier Loria" wrote in message

news:...

> Hola:
> Comparto tus comentarios, pero lo efectivo de la llave, dependera

del

> algoritmo. Si hablas de algoritmos reconocidos comparto tu argumento,

cuando

La ventaja de esos algoritmos es que son abiertos, aunque en algunos
casos tengas que pagar regalías, y cualquiera puede hacer una
implementación, sin tener que comprar una en concreto o bin porque no
exista una situación especial.

> vi que Jose Antonio menciona una clase privada me inmagine un algoritmo
> generado por el. Normalmente estos se quiebran con relativa facilidad y
> estan sujetos a mi comentario inicial.

Tienes toda la razón, aquí en España hay un herramienta de desarrollo
que se llama Velázquez Visual, hablando con uno de los desarrolladores
me comenta que el protocolo de red que utilizan es segurísimo, que
todo va encriptado y además como comprime pues es muy rápido. Cuando
le pregunto por la bibliotecas que utilizan me dice que es de
desarrollo propio, viendo las orejas al lobo le pregunto cual es el
algoritmo utilizado a lo que me responde que es secreto. Que es un
ejemplo claro de "Security Through Obscurity". O el caso de un
directivo que preocupado por el reglamento de seguridad pregunta a la
empresa proveedora si son seguras las comunicaciones, esta lo que hace
es enseñarle las tramas de red capturadas con un *sniffer* y en
hexadecimal, posteriormente en una reunión para justificar al
proveedor le dice a sus jefes, "Es segurisimo, no dios que lo
entienda".

Un saludo.

> Saludos,
>
> Javier Loria
> Costa Rica
> Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
> que pueda ser copiado y pegado al Query Analizer.
> La version de SQL y Service Pack tambien ayuda
>