Encriptar tablas
Walter R. Ojeda Valiente
Hola a todos
�Alguien conoce alguna forma de encriptar las tablas para que no pueda verse
su contenido desde fuera de la aplicaci�n?
Una forma sencilla y tradicional es cambiar alg�n caracter de la cabecera
del .DBF, lo cual evita que la tabla pueda abrirse desde la ventana de
comandos o desde otro programa. Pero eso no sirve si el curioso abre la
tabla con el Notepad, Wordpad o alg�n otro editor de textos, ya que en ese
caso, aunque la informaci�n no le aparecer� ni ordenada ni clasificada, s�
le aparecer� visible. Por ejemplo, abriendo la tabla CLIENTES.DBF con
Wordpad �l podr�a conocer los nombres de todos los clientes.
Adem�s, cambiar algunos caracteres de la cabecera del .DBF no es tampoco muy
seguro. Sirve s� contra usuarios que no conocen mucho de inform�tica pero
contra uno experimentado y con tiempo y ganas de desencriptar la tabla no,
ya que no tardar� mucho en conseguirlo.
Desde hace a�os tengo una rutina que escrib� para encriptar tablas, funciona
muy bien, pero se vuelve lenta cuando la cantidad de registros pasa de
10.000 � 12.000.
Ahora me encargaron desarrollar un sistema que debe ser 100% seguro (o lo
m�s cerca posible) porque manejar�n grandes cantidades de dinero. Y r�pido,
porque habr� momentos en que estar�n muchos clientes formando la fila y no
se les puede hacer esperar.
Gracias de antemano por sus respuestas.
Saludos.
Walter.
legiofox
Y si desarrollas el sistema contra SQL Server o algo similar y utilizas las
opciones de encriptaci�n que traen los sistemas gestores de bases de datos?
Walter R. Ojeda Valiente
Hola legiofox
S�, exacto, esa es una de las alternativas. Pero si se puede hacer con las
tablas nativas del Visual FoxPro, mucho mejor.
Saludos.
Walter.
Dario
Se puede para el ususario comun, pero si es alguien mas avispado encontraria
la solucion.
Hay que modificar la cabecera, asi cuando se quiere abrir da el error de que
no es una tabla, ahi entraria el avispado.
Caso contrario hay librerias de encriptacion de registros, tablas etc.
Busca este articulo
Visual FoxPro - Encrypt and Decrypt Files
Copyright 2006 SweetPotato Software, Inc.
Viene con su Fll
Espero te sirva
--
Dario David Puccio
El Cyber_Gaucho
www.chispazodetradicion.com.ar
"Walter R. Ojeda Valiente" <wr...@hotmail.com> escribi� en el mensaje
news:uyC9LU9%23JHA...@TK2MSFTNGP04.phx.gbl...
Mendoza Mauricio
lo perdes aprendiendo con SQL, MySQL, etc.
En dbf ten�s que tener en cuenta que si te decompilan el exe fuiste!!!.
Y si logran llevar las tablas tienen todo el tiempo del mundo para ir
probando.
Lo m�s seguro de trabajar es SQL ( SQL Expres, SQL, MySQL, etc.) pero
tambi�n es lo m�s lento a la hora de desarrollar. (y si no estas
familiarizado con SQL peor)
Yo pondr�a en la balanza que tan privados son los datos, y a que nivel de
usuario me enfrento a la hora de vulnerar el sistema.
Mauricio Mendoza.
www.tecnosan.com.ar
"Walter R. Ojeda Valiente" <wr...@hotmail.com> escribi� en el mensaje
news:uyC9LU9%23JHA...@TK2MSFTNGP04.phx.gbl...
Walter R. Ojeda Valiente
Hola Mauricio
Gracias por el consejo.
Mira, la que estoy por desarrollar es una aplicaci�n que se utilizar� en
muchas localidades al mismo tiempo e independientemente unas de otras. En
cada una de esas localidades, la aplicaci�n estar� instalada en varias
computadoras. Las computadoras de cada localidad estar�n conectadas en red,
pero no se conectar�n con las de las otras localidades.
El problema potencial es que los montos de dinero que se manejar�n ser�n
muy, muy grandes, como m�nimo unos doscientos mil d�lares anuales en las
localidades peque�as y m�s de 20 millones de d�lares en las localidades
grandes. Y te estoy hablando de unas 60 localidades, quiz�s m�s.
Como la aplicaci�n ser� una sola, si alguien consigue averiguar como
modificar los datos en cualquiera de las localidades podr�a intentar hacer
alg�n tipo de desfalco all� y tambi�n ponerse de acuerdo con gente de las
otras localidades para hacer lo mismo.
Desde luego, hay muchos controles para que eso no ocurra, pero cuanto m�s
seguros est�n los datos, pues mucho mejor. Despu�s ya es tarde para los
lamentos.
Ya sabes, cuando hay mucho dinero en juego los muchachos se las ingenian
para agarrar una tajada y son creativos para eso. Quiz�s no tengan
creatividad para cosas buenas, pero s� para delinquir.
Como los usuarios ser�n cientos, sus niveles de conocimientos inform�ticos y
de cualquier otra cosa, ser�n muy variados. Lo mismo que su honestidad.
Saludos.
Walter.
Edwin Duran
Un amigo compro una librer�a en vfpstylemenuframework.com para trabajar
con SQL y hasta ahora no ha tenido problema, seg�n la publicidad los cambio
son muy m�nimos en la programaci�n.
Espero que esto te ayude.
"Walter R. Ojeda Valiente" <wr...@hotmail.com> escribi� en el mensaje
news:O20skEA$JHA....@TK2MSFTNGP03.phx.gbl...
Lic. J. Enrique Ramos Menchaca
tener una buena base de datos.
--
Lic. J. Enrique Ramos Menchaca
Guadalajara, Jalisco, M�xico.
"Edwin Duran" <Edwin_...@hotmail.com> escribi� en el mensaje de
noticias:uhILB4A$JHA....@TK2MSFTNGP05.phx.gbl...
> Un amigo compro una librer�a en vfpstylemenuframework.com para trabajar
> con SQL y hasta ahora no ha tenido problema, seg�n la publicidad los
> cambio son muy m�nimos en la programaci�n.
>
>
> Espero que esto te ayude.
>
>
>
>
> "Walter R. Ojeda Valiente" <wr...@hotmail.com> escribi� en el mensaje
> news:O20skEA$JHA....@TK2MSFTNGP03.phx.gbl...
>> Hola Mauricio
>>
>> Gracias por el consejo.
>>
>> Mira, la que estoy por desarrollar es una aplicaci�n que se utilizar� en
>> muchas localidades al mismo tiempo e independientemente unas de otras. En
>> cada una de esas localidades, la aplicaci�n estar� instalada en varias
>> computadoras. Las computadoras de cada localidad estar�n conectadas en
>> red, pero no se conectar�n con las de las otras localidades.
>>
>> El problema potencial es que los montos de dinero que se manejar�n ser�n
>> muy, muy grandes, como m�nimo unos doscientos mil d�lares anuales en las
>> localidades peque�as y m�s de 20 millones de d�lares en las localidades
>> grandes. Y te estoy hablando de unas 60 localidades, quiz�s m�s.
>>
>> Como la aplicaci�n ser� una sola, si alguien consigue averiguar como
>> modificar los datos en cualquiera de las localidades podr�a intentar
>> hacer alg�n tipo de desfalco all� y tambi�n ponerse de acuerdo con gente
>> de las otras localidades para hacer lo mismo.
>>
>> Desde luego, hay muchos controles para que eso no ocurra, pero cuanto m�s
>> seguros est�n los datos, pues mucho mejor. Despu�s ya es tarde para los
>> lamentos.
>>
>> Ya sabes, cuando hay mucho dinero en juego los muchachos se las ingenian
>> para agarrar una tajada y son creativos para eso. Quiz�s no tengan
>> creatividad para cosas buenas, pero s� para delinquir.
>>
>> Como los usuarios ser�n cientos, sus niveles de conocimientos
>> inform�ticos y de cualquier otra cosa, ser�n muy variados. Lo mismo que
>> su honestidad.
>>
>> Saludos.
>>
>> Walter.
>>
>>
>
>
dfoo
Si las tablas ser�n de acceso muti usuario deber�s encriptar los datos (no
las tablas) porque el sistema
al trtar de abrirlas no sabr� si ya estan desdencriptadas o si ya las
desencript� el primero usuario que las abri� (a menos que sea una
encriptacion muy simple - como cambiar unos caracteres de la cabecera)
La soluci�n que resta es la de encriptar el contenidop de los campos.
Si esa fuera la solucion yo utilizo las api de sindow para encriptar pero el
problema es que de WIN98 a WIN xp , el modo de encriptar cambi� y se me
rompieron la claves.
El otro problema es que el resultado encriptado por un buen algoritmo por lo
general es de largo mayor
al de la cadena original
por lo tanto el encriptado debes guardarlo en un memo o un char lo
suficientemente largo.
Fin de la completa, yo para encriptar mis claves deb� trducir el algoritmo
blowfish a VFP.
Saludos
Daniel
"Walter R. Ojeda Valiente" <wr...@hotmail.com> escribi� en el mensaje
news:u$oGLT8%23JHA...@TK2MSFTNGP02.phx.gbl...
Mendoza Mauricio
Los datos estan m�s seguro si los usuarios no tienen acceso f�sico a ellos.
Por ejemplo si NO tienen acceso a los archivos de la BD elimin�s el 80 o 90
% de usuarios con cualquier nivel de conocimiento.
Tendr�n el exe que adem�s lo podran copiar en un pendriver y llevarselo a
sus casas, pero no tendran la fuente de la informaci�n ya que no pueden
copiarla.
Para eso necesitaras un servidor con una BD como por ejemplo SQL o MySQL
(entre otras).
Sino, podr�as comprar un Win2003 Server con cantidad de usuario, que se
conecten mediante terminal server (escritorio remoto) y desde el servidor no
dejar que vean ni copien ninguna archivo, eliminando asi el pendriver. No
estoy seguro pero creo que el banco credicoop usa este sistema.
Ah� si podrias usar dbf sin tener que encriptarla siquiera.
Pero te repito.... la persona que tenga acceso al servidor tiene acceso a
los datos por m�s encryptaci�n que le pongas.
Tambi�n podr�as dividir el sistema en modulos, varios exe , dependiendo de
la cantidad de usuarios que necesites,
Saludos.
Mauricio Mendoza
www.tecnosan.com.ar
"Walter R. Ojeda Valiente" <wr...@hotmail.com> escribi� en el mensaje
news:O20skEA$JHA....@TK2MSFTNGP03.phx.gbl...
dfoo
Por ultimo, cuando todo falle, yo creo que la mejor solucion es pasar a SQL.
Nosotors utilizamos una biblioteca de clases que permite mediante
unos pocos comandos, obtener datos y grabarlos (relacionados) en Sql server
2000,2005 y 2008.
De hecho la biblioteca es bastante c�moda, se reconecta antes de cada
comando, por si
se interrumpe la conexion, y adem�s tiene una estructura pensada para la
replicaci�n de datos.
Debido a que la Replicacion de datos de Microsoft nunca funcin� hasta
ahora...
Saludos
"Walter R. Ojeda Valiente" <wr...@hotmail.com> escribi� en el mensaje
news:u$oGLT8%23JHA...@TK2MSFTNGP02.phx.gbl...
3rn3st0
datos al cual sólo podrán acceder los usuarios a través de tu
aplicación. Esto evitará de manera bastante cómoda y sencilla el
acceso a los datos de manera directa. En cuanto a la base de datos,
como ya se han dicho varios, es mejor usar algún manejador SQL, te
recomiendo MySQL o PostgreSQL, son bases de datos robustas, estables,
muy seguras y lo mejor de todo, gratuitas. Además de eso, deberías
pensar en la posibilidad de adquirir alguna de esas aplicaciones que
permiten encriptar los ejecutables de VFP, así evitarías la posible
descompilación de tu aplicación.
Walter R. Ojeda Valiente
Hola Mauricio
El gran problema es que ni yo ni nadie de mi equipo tendremos acceso a los
sistemas una vez instalados e implementados. Cada localidad tendr� su propia
red de computadoras y sus propios usuarios, los cuales pueden ir cambiando
con el tiempo. No puedo tener ning�n control sobre eso. Nuestra tarea
terminar� una vez que los sistemas est�n instalados y funcionando. Desde
luego, haremos mantenimiento peri�dico y todo eso, pero no estaremos en el
d�a a d�a.
Los usuarios (operadores) del sistema podr�n cambiarse en cualquier momento.
Los sistemas ser�n muy f�ciles de utilizar, muy amigables, con la m�nima
intervenci�n humana, eso har� que cualquier operador pueda ser facilmente
reemplazado. Y adem�s, ser�n cientos los operadores que los utilizar�n.
En muchas de esas localidades ya est�n usando sistemas inform�ticos en este
momento, pero todos tienen problemas o vulnerabilidades. O son muy
complicados de usar, o muy lentos, o los programadores son unos
irresponsables y no aparecen cuando se los necesita, o cobran muy caro cada
vez que aparecen, o los datos de los archivos pueden ser cambiados (cosa que
ya ocurri�). Justamente por todo eso es que est�n requiriendo de un sistema
nuevo, el cual si todo sale bien se implementar� tambi�n en muchas
localidades que a�n no cuentan con uno.
Saludos.
Walter.
Walter R. Ojeda Valiente
Hola 3rn3st0
S�, usar MySQL o PostgreSQL es una de las alternativas, pero tambi�n pueden
ser vulnerados. En cuanto a encriptar los ejecutables, tengo Refox y
Konxise, aunque debes saber que tambi�n son vulnerables y no proporcionan
una seguridad del 100%. Desde hace a�os tengo mi propio programa protector
de EXEs que tampoco es seguro al 100% pero al menos les dificulta mucho la
tarea a los curiosos, ya que no est� disponible para nadie m�s y solamente
lo uso yo.
Saludos.
Walter.
Walter R. Ojeda Valiente
http://www.portalfox.com/index.php?name=News&file=article&sid=2215
Saludos.
Walter.
Luis Martinez
Has pensado en encriptar los datos y no la tabla, es decir los campos que no
quiero revelar. Ser�a mas eficiente recuperar los datos, por ejemplo de un
cliente, y luego desencriptarlo para mostarlo.
Crea una rutina de encriptaci�n y has lo que se llama la doble vuelta. Ej.
vNombre = Encriptar(Nombre) y luego vNombre = Encriptar(vNombre) y almacena
este resultado en la tabla.
Ten presente que cuando hagas una consulta de recuperaci�n de datos las
variables a comprar deberas pasarlas por la rutina de desencriptaci�n.
Saludos
Luis Mart�nez
"Walter R. Ojeda Valiente" <wr...@hotmail.com> escribi� en el mensaje de
noticias news:u$oGLT8%23JHA...@TK2MSFTNGP02.phx.gbl...
Walter R. Ojeda Valiente
Hola Luis
S�, desde luego que pens� en eso, tambi�n en poner un checksum en cada
registro para detectar si los datos fueron cambiados desde afuera de mi
aplicaci�n.
Lo que quiero es complicarle la vida a los curiosos, hac�rsela lo m�s
dif�cil posible pero sin que eso afecte el rendimiento de la aplicaci�n, o
no tendr�a sentido.
Estoy investigando, buscando alternativas, se manejar� mucho dinero y no
faltar� alguno tentado a cometer un desfalco. Ser�n cientos los usuarios,
separados unos de otros por decenas o cientos de kil�metros, as� que ser�
muy dif�cil controlarlos a todos. Y tampoco es mi tarea.
Saludos.
Walter.