Encriptación II

Gracias Dani por tu respuesta. Creo que has abierto una línea muy
interesante para debatir.

En mi aplicación almaceno datos de clientes e información financiera de
ellos. Con el fin de evitar que un robo de información se sepa a quién
pertenece la información finaciera, había pensado encriptar los datos
identificativos de los clientes: cif, nombre, domicilio y localidad.
La cuestión es que los usuarios de la aplicación hacen búsquedas con textos
incluidos en el nombre.

La aplicación asp corre en un servidor w2000 y los datos están MySql en otro
servidor Linux. Y los dos servidores están en un servicio externo de
hosting. Aquí puede estar una de las claves, ya que cualquier administrador
de los sevidores no creo que tenga ningún problema para entrar y cotillear
lo que hay.

Los clientes acceden a la aplicación mediante usuario y clave.
El código de la aplicación no contiene las password ya que éstas se
almacenan en la BD. Y para acceder a la BD hay que conocer las claves de
acceso a la misma.
El problema que quería evitar es que si acceden a la BD tienen toda la
información. Por eso mi idea era encriptar algunos datos identificativos
utilizando una Key que no se almacena en ningún sitio. Así, aunque
modifiques código dandote accesos, la información de la BD no se podría ver
desencriptada sin la Key.
El componente de encriptación trabaja a nivel de string completo, por eso
para EMPRESA 1 , S.A.puede dar un resultado ADF698E6638123498 y para EMPRESA
2, S.A. puede salir 854654564FFDA654645

No si si me estoy pasando con los temas de seguridad y que con lo que tengo
no es necesario andar encriptando. Estaré intentando matar moscas a
cañonazos?
:-))

Salu2

jeje posiblemente =) aunq no necesariamente, pocas aplicaciones se lo toman
tan enserio pero tampoco esta de mas hacer las cosas bien

bueno, veamos esquematicamente como lo plantearia yo (no lo haria q cansa
solo de escribirlo jajajaja ;)

existen datos de un cliente no criticos, otros no encriptables, y otros
criticos =)
por ejemplo

no criticos: la direccion (si son empresas es conocido, si son particulares
si q es critico)
no encriptable: el nombre o codigo de referencia en una factura, campos de
busqueda
critico: el contenido de la factura, importe, datos extra q no son
"buscables", nadie buscara las facturas de 34 euros ;), datos criticos de la
empresa (facturacion total, etc)

asi pues en la bbdd una "malapersona" veria solo
usuario y clave: basura encriptada
codigo de un cliente : 49 , nombre empresa y datos no criticos podrian ser
visibles
en por ejemplo facturas, veria
referencia: 2 , empresacliente: pepito gonzalez , concepto: encriptado,
importe encriptado, etc
(*nota1*)

esquema de funcionamiento:

entrada controlada con usuario y password, ambos encriptados con algoritmo
unidireccional (ejemplo: aspcrypt pero hay otros, ese es algo debil), un
algoritmo no reversible

el usuario entra en tu asp:
guarda su password encryptada y su user encriptado en session
busca si esos datos encriptados existen en la tabla de usuarios y devuelve
el codigo del cliente (un autonumerico q luego usas en otras tablas)
almacenandolo en session tambien

el usuario accedera a todos los registros que sean propios (marcados con un
campo "codigocliente= idautonumericodelcliente)

los datos criticos se recuperan y almacenan usando un algoritmo
bidireccional, que usa como clave la proporcionada por el cliente - la
encriptada que tienes guardada en session-

el resto de datos se mantienen como texto/numero o lo q sea, sin encriptar
para las busquedas, reduce estos al minimo imprescindible de funcionamiento

en caso de q el cliente desee cambiar su contraseña:
hay q validar su nueva contraseña, almacenarla encriptada en la tabla de
usuarios, desencriptar con la antigua todos sus datos criticos y
encriptarlos con la nueva

nivel de proteccion:
los datos "no encriptados" seran visibles por toda la gente con acceso
fisico al host
los datos de contraseña y usuarios no seran visibles por nadie (ni por ti)
(*1)
los datos de cada cliente solo pueden verse con su clave (*2)

debilidad general del sistema: como siempre el mas debil de los dos sistemas
de encriptacion (*1) y (*2), si se consigue saltar el (*1) el (*2) salta
automaticamente, con el (*2) se podria probar un ataque por diccionario o un
reventador normal de claves y se sacarian los datos, usualmente de un
cliente por cada paso , la encriptacion (*1) no debe ser reversible, la (*2)
necesariamente ha de serlo

(*nota1*) existen formas de "saltarse" las limitaciones en estos casos, lo
critico es la carga de busquedas que tengas, una empresa almacenara "x"
registros propios, si ese x es bajo, puedes optar por una busqueda con
do...loop , sin complicarte con tablas intermedias y encriptando todos los
datos, algo como
rs=recordset sobre select * from facturas where codigocliente=" &
session("codcli")
recuperas sobre un vector por acelerar (getrows) si quieres
haces la "busqueda"

do while not rs.eof
ok=false
if instr (desencripta(rs("nombrecliente"))),condicion)>0 then ok=true
etc con las condiciones
if ok then muestraelregistro
rs.movenext
loop

evidentemente cuanto mas limites el primer select mejor, si haces tb una
limitacion por fecha de la factura (q da igual encriptarla q no) podrias
añadir un where codigocliente and fecha> tal and fecha < cual

para el nombredelclientealquefacturan por ejemplo puedes usar algo
intermedio, almacenas el idclientealquesefactura (sin encriptar) , en una
tabla aparte los clientes de cada empresa , con el nombre encriptado (no
seran demasiados...) la busqueda la haces primero en esa tabla, obtienes los
codigos q cumplen la condicion, y buscas esos codigos con select where



espero que te oriente ;)

-o|o|--
-o|o| dani castillo
-o|o| http://www15.brinkster.com/danic/
-o|o| tutorial y trucos asp, vb, diseño
-o|o|--
"Jimy" escribió en el mensaje
news:

Gracias Dani por tu respuesta. Creo que has abierto una línea muy
interesante para debatir.

En mi aplicación almaceno datos de clientes e información financiera de
ellos. Con el fin de evitar que un robo de información se sepa a quién
pertenece la información finaciera, había pensado encriptar los datos
identificativos de los clientes: cif, nombre, domicilio y localidad.
La cuestión es que los usuarios de la aplicación hacen búsquedas con

textos

incluidos en el nombre.

La aplicación asp corre en un servidor w2000 y los datos están MySql en

otro

servidor Linux. Y los dos servidores están en un servicio externo de
hosting. Aquí puede estar una de las claves, ya que cualquier

administrador

de los sevidores no creo que tenga ningún problema para entrar y cotillear
lo que hay.

Los clientes acceden a la aplicación mediante usuario y clave.
El código de la aplicación no contiene las password ya que éstas se
almacenan en la BD. Y para acceder a la BD hay que conocer las claves de
acceso a la misma.
El problema que quería evitar es que si acceden a la BD tienen toda la
información. Por eso mi idea era encriptar algunos datos identificativos
utilizando una Key que no se almacena en ningún sitio. Así, aunque
modifiques código dandote accesos, la información de la BD no se podría

ver

desencriptada sin la Key.
El componente de encriptación trabaja a nivel de string completo, por eso
para EMPRESA 1 , S.A.puede dar un resultado ADF698E6638123498 y para

EMPRESA

2, S.A. puede salir 854654564FFDA654645

No si si me estoy pasando con los temas de seguridad y que con lo que

tengo

no es necesario andar encriptando. Estaré intentando matar moscas a
cañonazos?
:-))

Salu2

Este post me lo imprimo y me lo estudio esta noche antes de dormir.

Daniel Álvarez




"danicastillo" escribió en el
mensaje news:

jeje posiblemente =) aunq no necesariamente, pocas aplicaciones se lo

toman

tan enserio pero tampoco esta de mas hacer las cosas bien

bueno, veamos esquematicamente como lo plantearia yo (no lo haria q cansa
solo de escribirlo jajajaja ;)

existen datos de un cliente no criticos, otros no encriptables, y otros
criticos =)
por ejemplo

no criticos: la direccion (si son empresas es conocido, si son

particulares

si q es critico)
no encriptable: el nombre o codigo de referencia en una factura, campos de
busqueda
critico: el contenido de la factura, importe, datos extra q no son
"buscables", nadie buscara las facturas de 34 euros ;), datos criticos de

la

empresa (facturacion total, etc)

asi pues en la bbdd una "malapersona" veria solo
usuario y clave: basura encriptada
codigo de un cliente : 49 , nombre empresa y datos no criticos podrian

ser

visibles
en por ejemplo facturas, veria
referencia: 2 , empresacliente: pepito gonzalez , concepto: encriptado,
importe encriptado, etc
(*nota1*)

esquema de funcionamiento:

entrada controlada con usuario y password, ambos encriptados con algoritmo
unidireccional (ejemplo: aspcrypt pero hay otros, ese es algo debil), un
algoritmo no reversible

el usuario entra en tu asp:
guarda su password encryptada y su user encriptado en session
busca si esos datos encriptados existen en la tabla de usuarios y

devuelve

el codigo del cliente (un autonumerico q luego usas en otras tablas)
almacenandolo en session tambien

el usuario accedera a todos los registros que sean propios (marcados con

un

campo "codigocliente= idautonumericodelcliente)

los datos criticos se recuperan y almacenan usando un algoritmo
bidireccional, que usa como clave la proporcionada por el cliente - la
encriptada que tienes guardada en session-

el resto de datos se mantienen como texto/numero o lo q sea, sin encriptar
para las busquedas, reduce estos al minimo imprescindible de

funcionamiento

en caso de q el cliente desee cambiar su contraseña:
hay q validar su nueva contraseña, almacenarla encriptada en la tabla de
usuarios, desencriptar con la antigua todos sus datos criticos y
encriptarlos con la nueva

nivel de proteccion:
los datos "no encriptados" seran visibles por toda la gente con acceso
fisico al host
los datos de contraseña y usuarios no seran visibles por nadie (ni por

ti)

(*1)
los datos de cada cliente solo pueden verse con su clave (*2)

debilidad general del sistema: como siempre el mas debil de los dos

sistemas

de encriptacion (*1) y (*2), si se consigue saltar el (*1) el (*2) salta
automaticamente, con el (*2) se podria probar un ataque por diccionario o

un

reventador normal de claves y se sacarian los datos, usualmente de un
cliente por cada paso , la encriptacion (*1) no debe ser reversible, la

(*2)

necesariamente ha de serlo

(*nota1*) existen formas de "saltarse" las limitaciones en estos casos, lo
critico es la carga de busquedas que tengas, una empresa almacenara "x"
registros propios, si ese x es bajo, puedes optar por una busqueda con
do...loop , sin complicarte con tablas intermedias y encriptando todos los
datos, algo como
rs=recordset sobre select * from facturas where codigocliente=" &
session("codcli")
recuperas sobre un vector por acelerar (getrows) si quieres
haces la "busqueda"

do while not rs.eof
ok=false
if instr (desencripta(rs("nombrecliente"))),condicion)>0 then ok=true
etc con las condiciones
if ok then muestraelregistro
rs.movenext
loop

evidentemente cuanto mas limites el primer select mejor, si haces tb una
limitacion por fecha de la factura (q da igual encriptarla q no) podrias
añadir un where codigocliente and fecha> tal and fecha < cual

para el nombredelclientealquefacturan por ejemplo puedes usar algo
intermedio, almacenas el idclientealquesefactura (sin encriptar) , en una
tabla aparte los clientes de cada empresa , con el nombre encriptado (no
seran demasiados...) la busqueda la haces primero en esa tabla, obtienes

los

codigos q cumplen la condicion, y buscas esos codigos con select where



espero que te oriente ;)

-o|o|--
-o|o| dani castillo
-o|o| http://www15.brinkster.com/danic/
-o|o| tutorial y trucos asp, vb, diseño
-o|o|--
"Jimy" escribió en el mensaje
news:
> Gracias Dani por tu respuesta. Creo que has abierto una línea muy
> interesante para debatir.
>
> En mi aplicación almaceno datos de clientes e información financiera de
> ellos. Con el fin de evitar que un robo de información se sepa a quién
> pertenece la información finaciera, había pensado encriptar los datos
> identificativos de los clientes: cif, nombre, domicilio y localidad.
> La cuestión es que los usuarios de la aplicación hacen búsquedas con
textos
> incluidos en el nombre.
>
> La aplicación asp corre en un servidor w2000 y los datos están MySql en
otro
> servidor Linux. Y los dos servidores están en un servicio externo de
> hosting. Aquí puede estar una de las claves, ya que cualquier
administrador
> de los sevidores no creo que tenga ningún problema para entrar y

cotillear

> lo que hay.
>
> Los clientes acceden a la aplicación mediante usuario y clave.
> El código de la aplicación no contiene las password ya que éstas se
> almacenan en la BD. Y para acceder a la BD hay que conocer las claves de
> acceso a la misma.
> El problema que quería evitar es que si acceden a la BD tienen toda la
> información. Por eso mi idea era encriptar algunos datos identificativos
> utilizando una Key que no se almacena en ningún sitio. Así, aunque
> modifiques código dandote accesos, la información de la BD no se podría
ver
> desencriptada sin la Key.
> El componente de encriptación trabaja a nivel de string completo, por

eso

> para EMPRESA 1 , S.A.puede dar un resultado ADF698E6638123498 y para
EMPRESA
> 2, S.A. puede salir 854654564FFDA654645
>
> No si si me estoy pasando con los temas de seguridad y que con lo que
tengo
> no es necesario andar encriptando. Estaré intentando matar moscas a
> cañonazos?
> :-))
>
> Salu2
>
>

:-O eso significa q da sueño? jajaja es broma =)

el sistema ese es relativamente seguro (creo!, ando algo dormido ultimamente
xD)

de todas formas, alguien con acceso fisico al host, y buena dosis de mala
idea, puede llegar a capturar todo (ejemplo: un simple sistema de cache que
almacene todo lo que emite el servidor desencriptado!, o mas
concretamente, modificando el asp para que el proximo cliente que entre,
deje en un fichero su contraseña y usuario :| , esos ataques por mucha
seguridad q le demos no son evitables , a fin de cuentas el acceso fisico a
un sitio es completamente critico :(, de todas formas tener separados los
servidores ayuda algo en el tema

por otro lado el sistema q he puesto permite q , aunq conozcamos una clave q
ha quedado comprometida, no podemos "ver" el resto de datos, solo los de ese
cliente, como contrapartida reduce completamente nuestro "poder" de
administradores, ejemplo, el cliente pepito con 1000 registros guardados nos
llama y nos dice q se le ha olvidado la clave no podemos hacer nada, ni
siquiera recuperar sus datos , si cambiamos en la tabla de acceso su clave
por una nueva , el cliente accedera a la aplicacion, pero no podra ver
ninguno de los datos antiguos criticos (ya q fueron encriptados con su clave
anterior)


-o|o|--
-o|o| dani castillo
-o|o| http://www15.brinkster.com/danic/
-o|o| tutorial y trucos asp, vb, diseño
-o|o|--
"Daniel Álvarez" escribió en el mensaje
news:uB2g%

Este post me lo imprimo y me lo estudio esta noche antes de dormir.

Daniel Álvarez




"danicastillo" escribió en el
mensaje news:
> jeje posiblemente =) aunq no necesariamente, pocas aplicaciones se lo
toman
> tan enserio pero tampoco esta de mas hacer las cosas bien
>
> bueno, veamos esquematicamente como lo plantearia yo (no lo haria q

cansa

> solo de escribirlo jajajaja ;)
>
> existen datos de un cliente no criticos, otros no encriptables, y otros
> criticos =)
> por ejemplo
>
> no criticos: la direccion (si son empresas es conocido, si son
particulares
> si q es critico)
> no encriptable: el nombre o codigo de referencia en una factura, campos

de

> busqueda
> critico: el contenido de la factura, importe, datos extra q no son
> "buscables", nadie buscara las facturas de 34 euros ;), datos criticos

de

la
> empresa (facturacion total, etc)
>
> asi pues en la bbdd una "malapersona" veria solo
> usuario y clave: basura encriptada
> codigo de un cliente : 49 , nombre empresa y datos no criticos podrian
ser
> visibles
> en por ejemplo facturas, veria
> referencia: 2 , empresacliente: pepito gonzalez , concepto:

encriptado,

> importe encriptado, etc
> (*nota1*)
>
> esquema de funcionamiento:
>
> entrada controlada con usuario y password, ambos encriptados con

algoritmo

> unidireccional (ejemplo: aspcrypt pero hay otros, ese es algo debil), un
> algoritmo no reversible
>
> el usuario entra en tu asp:
> guarda su password encryptada y su user encriptado en session
> busca si esos datos encriptados existen en la tabla de usuarios y
devuelve
> el codigo del cliente (un autonumerico q luego usas en otras tablas)
> almacenandolo en session tambien
>
> el usuario accedera a todos los registros que sean propios (marcados con
un
> campo "codigocliente= idautonumericodelcliente)
>
> los datos criticos se recuperan y almacenan usando un algoritmo
> bidireccional, que usa como clave la proporcionada por el cliente - la
> encriptada que tienes guardada en session-
>
> el resto de datos se mantienen como texto/numero o lo q sea, sin

encriptar

> para las busquedas, reduce estos al minimo imprescindible de
funcionamiento
>
> en caso de q el cliente desee cambiar su contraseña:
> hay q validar su nueva contraseña, almacenarla encriptada en la tabla

de

> usuarios, desencriptar con la antigua todos sus datos criticos y
> encriptarlos con la nueva
>
> nivel de proteccion:
> los datos "no encriptados" seran visibles por toda la gente con acceso
> fisico al host
> los datos de contraseña y usuarios no seran visibles por nadie (ni por
ti)
> (*1)
> los datos de cada cliente solo pueden verse con su clave (*2)
>
> debilidad general del sistema: como siempre el mas debil de los dos
sistemas
> de encriptacion (*1) y (*2), si se consigue saltar el (*1) el (*2)

salta

> automaticamente, con el (*2) se podria probar un ataque por diccionario

o

un
> reventador normal de claves y se sacarian los datos, usualmente de un
> cliente por cada paso , la encriptacion (*1) no debe ser reversible, la
(*2)
> necesariamente ha de serlo
>
> (*nota1*) existen formas de "saltarse" las limitaciones en estos casos,

lo

> critico es la carga de busquedas que tengas, una empresa almacenara "x"
> registros propios, si ese x es bajo, puedes optar por una busqueda con
> do...loop , sin complicarte con tablas intermedias y encriptando todos

los

> datos, algo como
> rs=recordset sobre select * from facturas where codigocliente=" &
> session("codcli")
> recuperas sobre un vector por acelerar (getrows) si quieres
> haces la "busqueda"
>
> do while not rs.eof
> ok=false
> if instr (desencripta(rs("nombrecliente"))),condicion)>0 then ok=true
> etc con las condiciones
> if ok then muestraelregistro
> rs.movenext
> loop
>
> evidentemente cuanto mas limites el primer select mejor, si haces tb una
> limitacion por fecha de la factura (q da igual encriptarla q no) podrias
> añadir un where codigocliente and fecha> tal and fecha < cual
>
> para el nombredelclientealquefacturan por ejemplo puedes usar algo
> intermedio, almacenas el idclientealquesefactura (sin encriptar) , en

una

> tabla aparte los clientes de cada empresa , con el nombre encriptado (no
> seran demasiados...) la busqueda la haces primero en esa tabla, obtienes
los
> codigos q cumplen la condicion, y buscas esos codigos con select where
>
>
>
> espero que te oriente ;)
>
> -o|o|--
> -o|o| dani castillo
> -o|o| http://www15.brinkster.com/danic/
> -o|o| tutorial y trucos asp, vb, diseño
> -o|o|--
> "Jimy" escribió en el mensaje
> news:
> > Gracias Dani por tu respuesta. Creo que has abierto una línea muy
> > interesante para debatir.
> >
> > En mi aplicación almaceno datos de clientes e información financiera

de

> > ellos. Con el fin de evitar que un robo de información se sepa a quién
> > pertenece la información finaciera, había pensado encriptar los datos
> > identificativos de los clientes: cif, nombre, domicilio y localidad.
> > La cuestión es que los usuarios de la aplicación hacen búsquedas con
> textos
> > incluidos en el nombre.
> >
> > La aplicación asp corre en un servidor w2000 y los datos están MySql

en

> otro
> > servidor Linux. Y los dos servidores están en un servicio externo de
> > hosting. Aquí puede estar una de las claves, ya que cualquier
> administrador
> > de los sevidores no creo que tenga ningún problema para entrar y
cotillear
> > lo que hay.
> >
> > Los clientes acceden a la aplicación mediante usuario y clave.
> > El código de la aplicación no contiene las password ya que éstas se
> > almacenan en la BD. Y para acceder a la BD hay que conocer las claves

de

> > acceso a la misma.
> > El problema que quería evitar es que si acceden a la BD tienen toda la
> > información. Por eso mi idea era encriptar algunos datos

identificativos

> > utilizando una Key que no se almacena en ningún sitio. Así, aunque
> > modifiques código dandote accesos, la información de la BD no se

podría

> ver
> > desencriptada sin la Key.
> > El componente de encriptación trabaja a nivel de string completo, por
eso
> > para EMPRESA 1 , S.A.puede dar un resultado ADF698E6638123498 y para
> EMPRESA
> > 2, S.A. puede salir 854654564FFDA654645
> >
> > No si si me estoy pasando con los temas de seguridad y que con lo que
> tengo
> > no es necesario andar encriptando. Estaré intentando matar moscas a
> > cañonazos?
> > :-))
> >
> > Salu2
> >
> >
>
>

Bueno ya me lo leí, no era por tema de sueño tranquilo Dani jaja.

Realmente yo pienso que es insuperable en cuanto al tema de la encriptación,
habras mas medidas de seguridad que se puedan tomar pero en cuanto
encriptacion no creo que se pueda hacer mucho más. Yo de momento no he
necesitado hacer nunca un sistema tan seguro, pero nunca se sabe cuando te
puede tocar algo asi sobre todo ahora con el miedo que tienen algunos
clientes a lo de la agencia de protección de datos que recomienda guardar
datos encriptados, que al minimo registro que guarden ya te vienen con el
cuento de que han leido.. y tu te quedas pensando pero si solo tienes
una tabla donde digo que el color de fondo es rojo ¿quiers que encripte el
rojo? jaja (es un ejemplo exagerado y no real claro), la gente tiene mucho
lío con eso pero eso es otro tema.

Como te decia nunca sabre cuando me pueda tocar crear un sistema así el
caso es que como tengas muchas tablas con información encriptada y el
usuario cambie la contraseña uffff el proceso de actualizar registros es
mortal. Aún así creo como te he dicho que esta muy bien, asi que me guardo
el sitema por si algun día me piden algo así.

Eres un crack!!

Otra cosa, ya que has hablado de seguridad ftp te pongo una pregunta, (la
postee ayer en las news de iis pero no me han dicho nada y como aqui ha
salido el tema pues tambien la planteo)

Yo tengo un servidor windows, habilitado para ftp a traves de sitios
(directorios) ftp virtuales

En el raiz del ftp no tengo nada. Es decir si alguien se mete por ftp://ip
no ve nada

Necesita meter el nombre de uno de esos directorios. Yo quiero saber si hay
alguna manera, bien mediante codigo, o bien mediante una aplicación que
diciendole la ip (por la que no se ve nada desde el internet explorer) te
saque la lista de directorios. Quiero saber hasta que punto alguien puede
adivinar que yo tengo un directorio ftp llamado mas o menos así, dado que
aqui, en mi empresa no le ponen seguridad de usuarios al ftp escudandose en
que nadie puede saber el nombre del directorio ftp (SIN COMENTARIOS). yo
solo quiero eso, una pequeña apliación o un codigo que me saque el nombre
para demostrar que tenemos un agujero como los socavones del ave a zaragoza.
Espero haberme explicado bien.


Daniel Álvarez




"danicastillo" escribió en el
mensaje news:ep%

:-O eso significa q da sueño? jajaja es broma =)

el sistema ese es relativamente seguro (creo!, ando algo dormido

ultimamente

xD)

de todas formas, alguien con acceso fisico al host, y buena dosis de mala
idea, puede llegar a capturar todo (ejemplo: un simple sistema de cache

que

almacene todo lo que emite el servidor desencriptado!, o mas
concretamente, modificando el asp para que el proximo cliente que entre,
deje en un fichero su contraseña y usuario :| , esos ataques por mucha
seguridad q le demos no son evitables , a fin de cuentas el acceso fisico

a

un sitio es completamente critico :(, de todas formas tener separados los
servidores ayuda algo en el tema

por otro lado el sistema q he puesto permite q , aunq conozcamos una clave

q

ha quedado comprometida, no podemos "ver" el resto de datos, solo los de

ese

cliente, como contrapartida reduce completamente nuestro "poder" de
administradores, ejemplo, el cliente pepito con 1000 registros guardados

nos

llama y nos dice q se le ha olvidado la clave no podemos hacer nada,

ni

siquiera recuperar sus datos , si cambiamos en la tabla de acceso su clave
por una nueva , el cliente accedera a la aplicacion, pero no podra ver
ninguno de los datos antiguos criticos (ya q fueron encriptados con su

clave

anterior)


-o|o|--
-o|o| dani castillo
-o|o| http://www15.brinkster.com/danic/
-o|o| tutorial y trucos asp, vb, diseño
-o|o|--
"Daniel Álvarez" escribió en el mensaje
news:uB2g%
> Este post me lo imprimo y me lo estudio esta noche antes de dormir.
>
> Daniel Álvarez
>
>
>
>
> "danicastillo" escribió en el
> mensaje news:
> > jeje posiblemente =) aunq no necesariamente, pocas aplicaciones se lo
> toman
> > tan enserio pero tampoco esta de mas hacer las cosas bien
> >
> > bueno, veamos esquematicamente como lo plantearia yo (no lo haria q
cansa
> > solo de escribirlo jajajaja ;)
> >
> > existen datos de un cliente no criticos, otros no encriptables, y

otros

> > criticos =)
> > por ejemplo
> >
> > no criticos: la direccion (si son empresas es conocido, si son
> particulares
> > si q es critico)
> > no encriptable: el nombre o codigo de referencia en una factura,

campos

de
> > busqueda
> > critico: el contenido de la factura, importe, datos extra q no son
> > "buscables", nadie buscara las facturas de 34 euros ;), datos criticos
de
> la
> > empresa (facturacion total, etc)
> >
> > asi pues en la bbdd una "malapersona" veria solo
> > usuario y clave: basura encriptada
> > codigo de un cliente : 49 , nombre empresa y datos no criticos

podrian

> ser
> > visibles
> > en por ejemplo facturas, veria
> > referencia: 2 , empresacliente: pepito gonzalez , concepto:
encriptado,
> > importe encriptado, etc
> > (*nota1*)
> >
> > esquema de funcionamiento:
> >
> > entrada controlada con usuario y password, ambos encriptados con
algoritmo
> > unidireccional (ejemplo: aspcrypt pero hay otros, ese es algo debil),

un

> > algoritmo no reversible
> >
> > el usuario entra en tu asp:
> > guarda su password encryptada y su user encriptado en session
> > busca si esos datos encriptados existen en la tabla de usuarios y
> devuelve
> > el codigo del cliente (un autonumerico q luego usas en otras tablas)
> > almacenandolo en session tambien
> >
> > el usuario accedera a todos los registros que sean propios (marcados

con

> un
> > campo "codigocliente= idautonumericodelcliente)
> >
> > los datos criticos se recuperan y almacenan usando un algoritmo
> > bidireccional, que usa como clave la proporcionada por el cliente - la
> > encriptada que tienes guardada en session-
> >
> > el resto de datos se mantienen como texto/numero o lo q sea, sin
encriptar
> > para las busquedas, reduce estos al minimo imprescindible de
> funcionamiento
> >
> > en caso de q el cliente desee cambiar su contraseña:
> > hay q validar su nueva contraseña, almacenarla encriptada en la

tabla

de
> > usuarios, desencriptar con la antigua todos sus datos criticos y
> > encriptarlos con la nueva
> >
> > nivel de proteccion:
> > los datos "no encriptados" seran visibles por toda la gente con

acceso

> > fisico al host
> > los datos de contraseña y usuarios no seran visibles por nadie (ni

por

> ti)
> > (*1)
> > los datos de cada cliente solo pueden verse con su clave (*2)
> >
> > debilidad general del sistema: como siempre el mas debil de los dos
> sistemas
> > de encriptacion (*1) y (*2), si se consigue saltar el (*1) el (*2)
salta
> > automaticamente, con el (*2) se podria probar un ataque por

diccionario

o
> un
> > reventador normal de claves y se sacarian los datos, usualmente de un
> > cliente por cada paso , la encriptacion (*1) no debe ser reversible,

la

> (*2)
> > necesariamente ha de serlo
> >
> > (*nota1*) existen formas de "saltarse" las limitaciones en estos

casos,

lo
> > critico es la carga de busquedas que tengas, una empresa almacenara

"x"

> > registros propios, si ese x es bajo, puedes optar por una busqueda con
> > do...loop , sin complicarte con tablas intermedias y encriptando todos
los
> > datos, algo como
> > rs=recordset sobre select * from facturas where codigocliente=" &
> > session("codcli")
> > recuperas sobre un vector por acelerar (getrows) si quieres
> > haces la "busqueda"
> >
> > do while not rs.eof
> > ok=false
> > if instr (desencripta(rs("nombrecliente"))),condicion)>0 then

ok=true

> > etc con las condiciones
> > if ok then muestraelregistro
> > rs.movenext
> > loop
> >
> > evidentemente cuanto mas limites el primer select mejor, si haces tb

una

> > limitacion por fecha de la factura (q da igual encriptarla q no)

podrias

> > añadir un where codigocliente and fecha> tal and fecha < cual
> >
> > para el nombredelclientealquefacturan por ejemplo puedes usar algo
> > intermedio, almacenas el idclientealquesefactura (sin encriptar) , en
una
> > tabla aparte los clientes de cada empresa , con el nombre encriptado

(no

> > seran demasiados...) la busqueda la haces primero en esa tabla,

obtienes

> los
> > codigos q cumplen la condicion, y buscas esos codigos con select where
> >
> >
> >
> > espero que te oriente ;)
> >
> > -o|o|--
> > -o|o| dani castillo
> > -o|o| http://www15.brinkster.com/danic/
> > -o|o| tutorial y trucos asp, vb, diseño
> > -o|o|--
> > "Jimy" escribió en el mensaje
> > news:
> > > Gracias Dani por tu respuesta. Creo que has abierto una línea muy
> > > interesante para debatir.
> > >
> > > En mi aplicación almaceno datos de clientes e información financiera
de
> > > ellos. Con el fin de evitar que un robo de información se sepa a

quién

> > > pertenece la información finaciera, había pensado encriptar los

datos

> > > identificativos de los clientes: cif, nombre, domicilio y localidad.
> > > La cuestión es que los usuarios de la aplicación hacen búsquedas con
> > textos
> > > incluidos en el nombre.
> > >
> > > La aplicación asp corre en un servidor w2000 y los datos están MySql
en
> > otro
> > > servidor Linux. Y los dos servidores están en un servicio externo de
> > > hosting. Aquí puede estar una de las claves, ya que cualquier
> > administrador
> > > de los sevidores no creo que tenga ningún problema para entrar y
> cotillear
> > > lo que hay.
> > >
> > > Los clientes acceden a la aplicación mediante usuario y clave.
> > > El código de la aplicación no contiene las password ya que éstas se
> > > almacenan en la BD. Y para acceder a la BD hay que conocer las

claves

de
> > > acceso a la misma.
> > > El problema que quería evitar es que si acceden a la BD tienen toda

la

> > > información. Por eso mi idea era encriptar algunos datos
identificativos
> > > utilizando una Key que no se almacena en ningún sitio. Así, aunque
> > > modifiques código dandote accesos, la información de la BD no se
podría
> > ver
> > > desencriptada sin la Key.
> > > El componente de encriptación trabaja a nivel de string completo,

por

> eso
> > > para EMPRESA 1 , S.A.puede dar un resultado ADF698E6638123498 y para
> > EMPRESA
> > > 2, S.A. puede salir 854654564FFDA654645
> > >
> > > No si si me estoy pasando con los temas de seguridad y que con lo

que

> > tengo
> > > no es necesario andar encriptando. Estaré intentando matar moscas a
> > > cañonazos?
> > > :-))
> > >
> > > Salu2
> > >
> > >
> >
> >
>
>