Se pueden esconder las tablas dbf?
3,061 views
Skip to first unread message
Miguel Castillo
Jun 30, 2011, 9:35:38 PM6/30/11
to publice...@googlegroups.com
el asunto es que estoy preparando un programa para su distribucion pero al entrar a la carpeta del programa me encuentro con todas las tablas dbf a la vista y siento como que si mi programa esta medio desnudo pues cualquiera puede entrar en ellas
Saludos a todos
Saludos a todos
Walter R. Ojeda Valiente
Jun 30, 2011, 9:47:04 PM6/30/11
to publice...@googlegroups.com
Pues ese es justamente uno de los grandes problemas de las tablas .DBF
Otro, no menos importante, es que pueden ser abiertas con casi cualquier programa: Word, Excel, Notepad, etc.
Una alternativa es que migres a SQL, allí podrás tenerlas ocultas a los ojos de los curiosos.
Otra alternativa es que les cambies el atributo a oculto. No es muy efectivo, pero en algo puede ayudar.
Otra alternativa es que uses algunos de los programas que te permiten ocultar carpetas, las cuales solamente se pueden abrir con una contraseña.
Otra alternativa más, es que las coloques en la subcarpeta, de la subcarpeta, de la subcarpeta, de la subcarpeta, de la subcarpeta de tu aplicación.
Aunque siempre lo mejor sigue siendo que migres a SQL.
Saludos.
Walter.
From: mike7...@hotmail.com
To: publice...@googlegroups.com
Subject: [vfp] Se pueden esconder las tablas dbf?
Date: Thu, 30 Jun 2011 20:35:38 -0500
Otro, no menos importante, es que pueden ser abiertas con casi cualquier programa: Word, Excel, Notepad, etc.
Una alternativa es que migres a SQL, allí podrás tenerlas ocultas a los ojos de los curiosos.
Otra alternativa es que les cambies el atributo a oculto. No es muy efectivo, pero en algo puede ayudar.
Otra alternativa es que uses algunos de los programas que te permiten ocultar carpetas, las cuales solamente se pueden abrir con una contraseña.
Otra alternativa más, es que las coloques en la subcarpeta, de la subcarpeta, de la subcarpeta, de la subcarpeta, de la subcarpeta de tu aplicación.
Aunque siempre lo mejor sigue siendo que migres a SQL.
Saludos.
Walter.
From: mike7...@hotmail.com
To: publice...@googlegroups.com
Subject: [vfp] Se pueden esconder las tablas dbf?
Date: Thu, 30 Jun 2011 20:35:38 -0500
extremo
Jul 1, 2011, 10:03:18 AM7/1/11
to Comunidad de Visual Foxpro en Español
Miguel, lo que puedes hacer es cambiar la extencion a tus dbf ejemplo
en vez de tabla.dbf, coloca tabla.dll o tabla.reg, etc, la extencion
queda a tu imaginacion. eso si para despues llamar esa tabla debes
hacer lo siguiente:
si le colocas a tu tabla el nombre tabla.dll en vfp debes abrirla de
la siguiente forma
use tabla.dll in 0
asi de simple
Bendiciones
On 30 jun, 21:47, "Walter R. Ojeda Valiente" <w...@hotmail.com> wrote:
> Pues ese es justamente uno de los grandes problemas de las tablas .DBF
>
> Otro, no menos importante, es que pueden ser abiertas con casi cualquier programa: Word, Excel, Notepad, etc.
>
> Una alternativa es que migres a SQL, allí podrás tenerlas ocultas a los ojos de los curiosos.
>
> Otra alternativa es que les cambies el atributo a oculto. No es muy efectivo, pero en algo puede ayudar.
>
> Otra alternativa es que uses algunos de los programas que te permiten ocultar carpetas, las cuales solamente se pueden abrir con una contraseña.
>
> Otra alternativa más, es que las coloques en la subcarpeta, de la subcarpeta, de la subcarpeta, de la subcarpeta, de la subcarpeta de tu aplicación.
>
> Aunque siempre lo mejor sigue siendo que migres a SQL.
>
> Saludos.
>
> Walter.
>
en vez de tabla.dbf, coloca tabla.dll o tabla.reg, etc, la extencion
queda a tu imaginacion. eso si para despues llamar esa tabla debes
hacer lo siguiente:
si le colocas a tu tabla el nombre tabla.dll en vfp debes abrirla de
la siguiente forma
use tabla.dll in 0
asi de simple
Bendiciones
On 30 jun, 21:47, "Walter R. Ojeda Valiente" <w...@hotmail.com> wrote:
> Pues ese es justamente uno de los grandes problemas de las tablas .DBF
>
> Otro, no menos importante, es que pueden ser abiertas con casi cualquier programa: Word, Excel, Notepad, etc.
>
> Una alternativa es que migres a SQL, allí podrás tenerlas ocultas a los ojos de los curiosos.
>
> Otra alternativa es que les cambies el atributo a oculto. No es muy efectivo, pero en algo puede ayudar.
>
> Otra alternativa es que uses algunos de los programas que te permiten ocultar carpetas, las cuales solamente se pueden abrir con una contraseña.
>
> Otra alternativa más, es que las coloques en la subcarpeta, de la subcarpeta, de la subcarpeta, de la subcarpeta, de la subcarpeta de tu aplicación.
>
> Aunque siempre lo mejor sigue siendo que migres a SQL.
>
> Saludos.
>
> Walter.
>
Daniel Estigarribia
Jul 1, 2011, 10:35:21 AM7/1/11
to publice...@googlegroups.com
la otra solucion que se me ocurre, pero va a dar un poco mas de trabajo de programacion es que encriptes la informacion de las tablas de fforma a que solo la aplicacion las pueda entender y usar cualquiera que abra una tabla no va a poder entender su contenido, pero eso implica que lo encriptes al grabar y lo desencriptes al leer la tabla en la ayuda de vfp hay ejemplos de como encriptar, podes hacer una ffuncion u objeto que se encarge de este trabajo eso va a estar en la aplicacion y va a ser transparente para el usuario, y va a dejar las tablas nolegibles para cualquiera que no sea la aplicacion
espero que sea util.
daniel Estigarribia
Asuncion-Paraguay
Asuncion-Paraguay
> Date: Fri, 1 Jul 2011 07:03:18 -0700
> Subject: [vfp] Re: Se pueden esconder las tablas dbf?
> From: protech...@gmail.com
> To: publice...@googlegroups.com
> Subject: [vfp] Re: Se pueden esconder las tablas dbf?
> From: protech...@gmail.com
> To: publice...@googlegroups.com
PabloRoca
Jul 1, 2011, 11:45:38 AM7/1/11
to Comunidad de Visual Foxpro en Español
Walter, leo que dices que ese es uno de los grandes problemas de Fox,
la verdad que no estoy de acuerdo.
En temas de seguridad a la gente se le va un poco el norte .. ponemos
trabas, encriptamos, ocultamos y de todo .. y nadie se le ocurre
proteger físicamente al servidor, cualquiera puede entrar con un bidón
de gasolina y prenderle fuego o liarse con un martillo a machacar el
server. Sin contar con el típico caso del gerente que se lleva una
copia de su empresa en un portátil y después se lo roban o pierden.
Migrar a SQL? bueno, eso puede mejorar algo la seguridad, pero si al
final le ponemos la password por defecto (sa) .. pues estamos
jodidos ... ademas, las tablas de SQL Server se almacenan en el File
System ... quien nos protegerá que un usuario no borre los
archivos .mdf, .ndf, y .ldf ? que son donde están las bases de datos.
"No que SQL Server no es file based" podreis decir algunos ..
efectivamente .. pero al final todo se guarda en simples archivos.
Si no piensas poner unas políticas de seguridad decentes en tu SQL
Server (poca gente lo hace), SQL server no te va a solucionar de per
se el problema. Ayudará un poco, pero no lo solucionara.
Pon en tu sistema un log que controle lo que hacen los usuarios,
encripta con Fox, algún campo que no vayas a utilizar en búsquedas y
no te compliques la vida con problemas que no suelen existir.
Si quieres utilizar un encriptador profesional .. pero que te reduce
el rendimiento de las consultas aproximadamente un 25% .. pues mirate
el Cryptor de Xitech, no es mal producto, yo lo utilice una vez con un
cliente paranoico .. jajaaj
http://www.xitech-europe.co.uk/cryptor5.php
Los comentarios de extremo y Daniel también me parecen acertados.
Saludos,
Pablo Roca
la verdad que no estoy de acuerdo.
En temas de seguridad a la gente se le va un poco el norte .. ponemos
trabas, encriptamos, ocultamos y de todo .. y nadie se le ocurre
proteger físicamente al servidor, cualquiera puede entrar con un bidón
de gasolina y prenderle fuego o liarse con un martillo a machacar el
server. Sin contar con el típico caso del gerente que se lleva una
copia de su empresa en un portátil y después se lo roban o pierden.
Migrar a SQL? bueno, eso puede mejorar algo la seguridad, pero si al
final le ponemos la password por defecto (sa) .. pues estamos
jodidos ... ademas, las tablas de SQL Server se almacenan en el File
System ... quien nos protegerá que un usuario no borre los
archivos .mdf, .ndf, y .ldf ? que son donde están las bases de datos.
"No que SQL Server no es file based" podreis decir algunos ..
efectivamente .. pero al final todo se guarda en simples archivos.
Si no piensas poner unas políticas de seguridad decentes en tu SQL
Server (poca gente lo hace), SQL server no te va a solucionar de per
se el problema. Ayudará un poco, pero no lo solucionara.
Pon en tu sistema un log que controle lo que hacen los usuarios,
encripta con Fox, algún campo que no vayas a utilizar en búsquedas y
no te compliques la vida con problemas que no suelen existir.
Si quieres utilizar un encriptador profesional .. pero que te reduce
el rendimiento de las consultas aproximadamente un 25% .. pues mirate
el Cryptor de Xitech, no es mal producto, yo lo utilice una vez con un
cliente paranoico .. jajaaj
http://www.xitech-europe.co.uk/cryptor5.php
Los comentarios de extremo y Daniel también me parecen acertados.
Saludos,
Pablo Roca
Edgar Acevedo
Jul 1, 2011, 11:47:43 AM7/1/11
to publice...@googlegroups.com
Miguel:
Yo programo desde 1,990. Comencé con FoxBase Plus. Luego pasé con FoxPro 1.0, FoxPro 2.0 y fue con FoxPro 2.6 con lo que hice programas ya a un nivel que podríamos decir "comercial". Me pasé hasta VFP 9 apenas hace un año porque tenía tantos clientes corriendo con mis viejos programas de FoxPro 2.6 que no me dejaban tiempo para meterme de lleno a VFP 9. Clientes contentos y complacidos con sus viejas aplicaciones hechas en FoxPro 2.6 para DOS. Cuando les mencioné que sería bueno hacer la migración a VFP 9 siempre me salían con una muy buena pregunta: ¿Porqué, si lo que que tenemos en FoxPro 2.6 para DOS funciona bien, es estable, no tiene limitaciones y aún hemos podido seguir haciéndole actualizaciones para nuestras necesidades ?
Desde hace mucho tiempo, para que se metan con mis tablas DBF hago algo que ya te sugirieron mas arriba:
- Cambio de nombre a los DBF y les pongo extensión DTS
- He agregado unos pocos archivos con extensión DTS para "despistar" un poco al posible intruso.
- He cambiado el atributo de las tablas a "oculto", así como de los archivos DTS inservibles y que solo uso para despistar.
También oculto otros archivos con otras extensiones.
Vengo haciendo esto desde 1,995. Para hoy, ya han transcurrido 16 años y NADIE, NUNCA ha abierto mis tablas y extraído información. Incluso, cuando han desplazado a mis sistemas por otros y han querido extraer información de mis tablas para incorporarlas al nuevo sistema, NO HAN PODIDO. Han tenido que llamarme para que les entreguelos datos "viejos" en archivos planos, para poderlos meter en la nueva aplicación.
No digo con esto que las tablas de VFP sean "intocables". Ciertamente son bastante vulnerables, pero si le complicas un poco las cosas a los "posibles tentontes", dificilmente tienen la capacidad técnica o el tiempo para tratar de adivinar como abrir tus archivos.
Alguien por allí te dijo que lo mejor es usar una BD profesional como SQL, MySQL y PostgreSQL. Ciertamente estas BD's son enormemente mas seguras pero NO SON INTOCABLES. Conozco el caso de un hacker local que logró abrir una BD en MySQL que funcionaba en un sitio web del gobierno. También en las noticias habrás oído de hackers que se meten con sistemas "impenetrables" del gobierno de EEUU. Los hackers han demostrado una y otra vez que practicamente "lo impenetrable" NO EXISTE.
Mis aplicaciones jamás han sido blanco de un hacker profesional. Nunca les han interesado mis aplicaciones ¿ para qué....?
Y creo que si algún día un hacker profesional decidiera "hacerme su blanco", no importa que mis tablas esten en MySQL, Firebird o PostgreSQL. Un tipo de esos, con toda su inteligencia y recursos técnicos de su lado, encontrará la forma de "voltearle los empaques" y violar mis tablas, estén en lo que estén.
Creo que lo mejor que se puede hacer es relajarse, sacudirse la paranoia, tomar ciertas medidas "razonablemente" seguras y esperar lo mejor. Si pasara lo peor, creo que ya era cosa del destino...
Salu2,
Edgar
Yo programo desde 1,990. Comencé con FoxBase Plus. Luego pasé con FoxPro 1.0, FoxPro 2.0 y fue con FoxPro 2.6 con lo que hice programas ya a un nivel que podríamos decir "comercial". Me pasé hasta VFP 9 apenas hace un año porque tenía tantos clientes corriendo con mis viejos programas de FoxPro 2.6 que no me dejaban tiempo para meterme de lleno a VFP 9. Clientes contentos y complacidos con sus viejas aplicaciones hechas en FoxPro 2.6 para DOS. Cuando les mencioné que sería bueno hacer la migración a VFP 9 siempre me salían con una muy buena pregunta: ¿Porqué, si lo que que tenemos en FoxPro 2.6 para DOS funciona bien, es estable, no tiene limitaciones y aún hemos podido seguir haciéndole actualizaciones para nuestras necesidades ?
Desde hace mucho tiempo, para que se metan con mis tablas DBF hago algo que ya te sugirieron mas arriba:
- Cambio de nombre a los DBF y les pongo extensión DTS
- He agregado unos pocos archivos con extensión DTS para "despistar" un poco al posible intruso.
- He cambiado el atributo de las tablas a "oculto", así como de los archivos DTS inservibles y que solo uso para despistar.
También oculto otros archivos con otras extensiones.
Vengo haciendo esto desde 1,995. Para hoy, ya han transcurrido 16 años y NADIE, NUNCA ha abierto mis tablas y extraído información. Incluso, cuando han desplazado a mis sistemas por otros y han querido extraer información de mis tablas para incorporarlas al nuevo sistema, NO HAN PODIDO. Han tenido que llamarme para que les entreguelos datos "viejos" en archivos planos, para poderlos meter en la nueva aplicación.
No digo con esto que las tablas de VFP sean "intocables". Ciertamente son bastante vulnerables, pero si le complicas un poco las cosas a los "posibles tentontes", dificilmente tienen la capacidad técnica o el tiempo para tratar de adivinar como abrir tus archivos.
Alguien por allí te dijo que lo mejor es usar una BD profesional como SQL, MySQL y PostgreSQL. Ciertamente estas BD's son enormemente mas seguras pero NO SON INTOCABLES. Conozco el caso de un hacker local que logró abrir una BD en MySQL que funcionaba en un sitio web del gobierno. También en las noticias habrás oído de hackers que se meten con sistemas "impenetrables" del gobierno de EEUU. Los hackers han demostrado una y otra vez que practicamente "lo impenetrable" NO EXISTE.
Mis aplicaciones jamás han sido blanco de un hacker profesional. Nunca les han interesado mis aplicaciones ¿ para qué....?
Y creo que si algún día un hacker profesional decidiera "hacerme su blanco", no importa que mis tablas esten en MySQL, Firebird o PostgreSQL. Un tipo de esos, con toda su inteligencia y recursos técnicos de su lado, encontrará la forma de "voltearle los empaques" y violar mis tablas, estén en lo que estén.
Creo que lo mejor que se puede hacer es relajarse, sacudirse la paranoia, tomar ciertas medidas "razonablemente" seguras y esperar lo mejor. Si pasara lo peor, creo que ya era cosa del destino...
Salu2,
Edgar
PabloRoca
Jul 1, 2011, 11:51:41 AM7/1/11
to Comunidad de Visual Foxpro en Español
Ah .. Miguel.
Si quieres encriptar algún dato utilizando solo Visual FoxPro léete
este articulo de las FAQ de Microsoft
http://support.microsoft.com/kb/115476
Cito literalmente
"A partir de Visual FoxPro 7.0, puede utilizar la clase de Crypt.vcx
Visual FoxPro Foundation para cifrar los datos. La clase cryptapi que
se encuentra en la biblioteca de clase base...\Ffc\_Crypt.vcx
proporciona acceso a las rutinas de API Crypto de Windows para que
pueda cifrar las cadenas, datos o archivos en sus aplicaciones de
Visual FoxPro. Para obtener más información sobre la _Crypt.vcx y la
clase _crytapi, vea busque archivo de ayuda para "_Crypt.vcx."
Saludos,
Pablo Roca
Si quieres encriptar algún dato utilizando solo Visual FoxPro léete
este articulo de las FAQ de Microsoft
http://support.microsoft.com/kb/115476
Cito literalmente
"A partir de Visual FoxPro 7.0, puede utilizar la clase de Crypt.vcx
Visual FoxPro Foundation para cifrar los datos. La clase cryptapi que
se encuentra en la biblioteca de clase base...\Ffc\_Crypt.vcx
proporciona acceso a las rutinas de API Crypto de Windows para que
pueda cifrar las cadenas, datos o archivos en sus aplicaciones de
Visual FoxPro. Para obtener más información sobre la _Crypt.vcx y la
clase _crytapi, vea busque archivo de ayuda para "_Crypt.vcx."
Saludos,
Pablo Roca
Richard Gaviria
Jul 1, 2011, 11:54:49 AM7/1/11
to publice...@googlegroups.com
Hola Pablo, se de tu amplia trayectoria en vfp, leía tus comentarios desde cuando era pequeño... jejejej, es una broma, lo que queria acotar es que si bien es cierto en SQL y MySql las tablas se almacenan en archivos, pero tienen una peculiaridad al copiarlas. En el caso de MySql las tablas con formato InnoDB no se pueden abrir cuando las copias porque los privilegios de las tablas de una base de datos están ligadas con la instalación de cada servidor MySql, asi es que es un poco dificil copiarlas, en el caso de las tablas tipo MyIsam si se pueden copiar directamente los archivos.. En el caso de SQL es verdad que la mayoría de programadores se descuida y no remueven al usuario sa, pero eso es de cada programador.
Yo también soy un creyente que los dbf cumplen su objetivo como deben y si uno conoce de configuración de servidores éstas pueden guardarse en un sitio seguro (claro que en informática nada es 100% seguro).
Un saludo y gracias por seguir aportando al grupo.
Saludos.
Rick.
> Date: Fri, 1 Jul 2011 08:45:38 -0700
> Subject: [vfp] Re: Se pueden esconder las tablas dbf?
Luis Mata
Jul 1, 2011, 11:56:54 AM7/1/11
to Comunidad de Visual Foxpro en Espa�ol
Estimado, Comparar seguridad de DBF con un SQL Server es descabellado y
decir que solo mejora un poquito peor aun, para volarte los dbf ya sea por
accidente o intencionado no necesitas entrar al servidor solo tener la ruta
compartida. No puedes hacer copias de seguridad en caliente, los dbf se
abren en openoffice y en office 2003 y se modifican los datos, abres el dbf
modificas y reemplazas la tabla y adi�s �ndices, la conexi�n v�a ODBC es
lent�sima, trabajar por VPN ni hablar, requieres mas l�neas de c�digo para
crear un sistema, requieres mas tiempo y tretas para poder asegurar los dbf
que al final no garantizan nada y bla bla bla.
En el tema de seguridad para SQL instalas en el servidor ni requieres
compartir la carpeta donde esta la Base de datos, por que se conecta por un
puerto, y ning�n usuario deber�a de tener acceso a este y listo.
decir que solo mejora un poquito peor aun, para volarte los dbf ya sea por
accidente o intencionado no necesitas entrar al servidor solo tener la ruta
compartida. No puedes hacer copias de seguridad en caliente, los dbf se
abren en openoffice y en office 2003 y se modifican los datos, abres el dbf
modificas y reemplazas la tabla y adi�s �ndices, la conexi�n v�a ODBC es
lent�sima, trabajar por VPN ni hablar, requieres mas l�neas de c�digo para
crear un sistema, requieres mas tiempo y tretas para poder asegurar los dbf
que al final no garantizan nada y bla bla bla.
En el tema de seguridad para SQL instalas en el servidor ni requieres
compartir la carpeta donde esta la Base de datos, por que se conecta por un
puerto, y ning�n usuario deber�a de tener acceso a este y listo.
Yo veo una gran diferencia entre ambos, el hecho que no lo quieras ver es
otra cosa.
Ning�n usuario final debe de tener acceso al servidor, ahora si hablamos de
da�os f�sicos eso ya no nos compete.
-----Mensaje original-----
From: PabloRoca
Sent: Friday, July 01, 2011 10:45 AM
To: Comunidad de Visual Foxpro en Espa�ol
Subject: [vfp] Re: Se pueden esconder las tablas dbf?
Walter, leo que dices que ese es uno de los grandes problemas de Fox,
la verdad que no estoy de acuerdo.
En temas de seguridad a la gente se le va un poco el norte .. ponemos
trabas, encriptamos, ocultamos y de todo .. y nadie se le ocurre
proteger f�sicamente al servidor, cualquiera puede entrar con un bid�n
de gasolina y prenderle fuego o liarse con un martillo a machacar el
server. Sin contar con el t�pico caso del gerente que se lleva una
copia de su empresa en un port�til y despu�s se lo roban o pierden.
Migrar a SQL? bueno, eso puede mejorar algo la seguridad, pero si al
final le ponemos la password por defecto (sa) .. pues estamos
jodidos ... ademas, las tablas de SQL Server se almacenan en el File
System ... quien nos proteger� que un usuario no borre los
archivos .mdf, .ndf, y .ldf ? que son donde est�n las bases de datos.
"No que SQL Server no es file based" podreis decir algunos ..
efectivamente .. pero al final todo se guarda en simples archivos.
Si no piensas poner unas pol�ticas de seguridad decentes en tu SQL
Server (poca gente lo hace), SQL server no te va a solucionar de per
se el problema. Ayudar� un poco, pero no lo solucionara.
Pon en tu sistema un log que controle lo que hacen los usuarios,
encripta con Fox, alg�n campo que no vayas a utilizar en b�squedas y
no te compliques la vida con problemas que no suelen existir.
Si quieres utilizar un encriptador profesional .. pero que te reduce
el rendimiento de las consultas aproximadamente un 25% .. pues mirate
el Cryptor de Xitech, no es mal producto, yo lo utilice una vez con un
cliente paranoico .. jajaaj
http://www.xitech-europe.co.uk/cryptor5.php
Los comentarios de extremo y Daniel tambi�n me parecen acertados.
Saludos,
Pablo Roca
Edgar Acevedo
Jul 1, 2011, 11:58:02 AM7/1/11
to publice...@googlegroups.com
Yo también he sido Fan de Pablo Roca. He aprendido mucho de sus publicaciones y experiencias. Definitivamente es un monstruo del VFP (dicho en el buen sentido de la palabra).
Saludos Pablo y gracias por tu utilísimos aportes...!!!!
Saludos Pablo y gracias por tu utilísimos aportes...!!!!
Arnaldo Toledano
Jul 1, 2011, 12:12:04 PM7/1/11
to publice...@googlegroups.com
Como dice Luis Mata, no hay punto de comparacion.
PabloRoca
Jul 1, 2011, 12:16:16 PM7/1/11
to Comunidad de Visual Foxpro en Español
Richard,
Que viejo me haces .. jajaja.
De MySQL no dije nada, porque lo he utilizado poco. Y es eso ..
usuario sa sin password .. ¿cuantas instalaciones de SQL Server hay
así? buf .. muchas.
Luis Mata,
No estoy comparando SQL Server contra DBF, lo haces tú .. vuelve a
leer mi comentario. Solo digo que por mucho SQL Server que se ponga,
si el que lo instala y configura no tiene un poco de cerebro . va a
valer de algo .. pero no de mucho. Estoy aburrido de ver malos planes
de seguridad tanto física como lógica en informática. Si tienes que
dar una consultoría de seguridad .. la debes dar también de acceso
físico, claro que compete a quien lo tenga que hacer.
En la mayoría de los casos, adoptar las propuestas que se han hecho en
este hilo sirven para poder tener los DBFs razonablemente seguros. Con
esto quiero reivindicar que no solo la tecnología da la seguridad .
sino el cerebro y el sentido común.
Edgar .... monstruo? .. jajaaj, ahora que ando medio calvo .. pues
puede ser .. :)
Saludos,
Pablo Roca
Que viejo me haces .. jajaja.
De MySQL no dije nada, porque lo he utilizado poco. Y es eso ..
usuario sa sin password .. ¿cuantas instalaciones de SQL Server hay
así? buf .. muchas.
Luis Mata,
No estoy comparando SQL Server contra DBF, lo haces tú .. vuelve a
leer mi comentario. Solo digo que por mucho SQL Server que se ponga,
si el que lo instala y configura no tiene un poco de cerebro . va a
valer de algo .. pero no de mucho. Estoy aburrido de ver malos planes
de seguridad tanto física como lógica en informática. Si tienes que
dar una consultoría de seguridad .. la debes dar también de acceso
físico, claro que compete a quien lo tenga que hacer.
En la mayoría de los casos, adoptar las propuestas que se han hecho en
este hilo sirven para poder tener los DBFs razonablemente seguros. Con
esto quiero reivindicar que no solo la tecnología da la seguridad .
sino el cerebro y el sentido común.
Edgar .... monstruo? .. jajaaj, ahora que ando medio calvo .. pues
puede ser .. :)
Saludos,
Pablo Roca
Arnaldo Toledano
Jul 1, 2011, 12:20:05 PM7/1/11
to publice...@googlegroups.com
Como dice Mata, no hay punto de comparacion.
Con solo tener las tablas o base de datos en el servidor y en una carpeta NO COMPARTIDA, es una buena traba para que entren usuarios no deseados.
Si a esa carpeta solo le das acceso al administrador, ya no estan expuestas a cualquiera.
Porsupuesto, que hay que tener otras consideraciones como no tener el administrador de MySQL o MSSQL en las terminales y otros detalles
por el estilo.
De todas maneras no hay punto de comparacion en la seguridad de dbf contra SQL.
Arnaldo Toledano
Con solo tener las tablas o base de datos en el servidor y en una carpeta NO COMPARTIDA, es una buena traba para que entren usuarios no deseados.
Si a esa carpeta solo le das acceso al administrador, ya no estan expuestas a cualquiera.
Porsupuesto, que hay que tener otras consideraciones como no tener el administrador de MySQL o MSSQL en las terminales y otros detalles
por el estilo.
De todas maneras no hay punto de comparacion en la seguridad de dbf contra SQL.
Arnaldo Toledano
Luis Mata
Jul 1, 2011, 12:24:26 PM7/1/11
to publice...@googlegroups.com
El usuario SA viene deshabilitado por defecto hoy en dia.
-----Mensaje original-----
From: PabloRoca
Sent: Friday, July 01, 2011 11:16 AM
To: Comunidad de Visual Foxpro en Espa�ol
Subject: [vfp] Re: Se pueden esconder las tablas dbf?
Richard,
Que viejo me haces .. jajaja.
De MySQL no dije nada, porque lo he utilizado poco. Y es eso ..
usuario sa sin password .. �cuantas instalaciones de SQL Server hay
as�? buf .. muchas.
Luis Mata,
No estoy comparando SQL Server contra DBF, lo haces t� .. vuelve a
leer mi comentario. Solo digo que por mucho SQL Server que se ponga,
si el que lo instala y configura no tiene un poco de cerebro . va a
valer de algo .. pero no de mucho. Estoy aburrido de ver malos planes
de seguridad tanto f�sica como l�gica en inform�tica. Si tienes que
dar una consultor�a de seguridad .. la debes dar tambi�n de acceso
f�sico, claro que compete a quien lo tenga que hacer.
En la mayor�a de los casos, adoptar las propuestas que se han hecho en
este hilo sirven para poder tener los DBFs razonablemente seguros. Con
esto quiero reivindicar que no solo la tecnolog�a da la seguridad .
sino el cerebro y el sentido com�n.
Richard Gaviria
Jul 1, 2011, 12:34:16 PM7/1/11
to publice...@googlegroups.com
Jajaja, no te ofendas Pablo por lo de viejo.. digo viejo en experiencia, hago notar lo de MySql porque se que en SQL es algo similar, y si es cierto cada servidor con el que me tropezado tiene el usuario sa habilitado y como una experiencia mas con los de Oracle, solo absta busacar una aplicación hecha para Oracle y revisar el archivo ini que los programadores por mala costumbre usan para guardar el ip y el password del servidor.
Saludos.
Rick.
> Date: Fri, 1 Jul 2011 09:16:16 -0700
> Subject: [vfp] Re: Se pueden esconder las tablas dbf?
> From: pablo...@gmail.com
> To: publice...@googlegroups.com
>
Walter R. Ojeda Valiente
Jul 1, 2011, 12:34:33 PM7/1/11
to publice...@googlegroups.com
Hola Pablo
La seguridad de las tablas siempre es un problema, sobre todo en empresas que manejan datos sensibles. Por supuesto que la responsabilidad por mantener los datos seguros no recae solamente en los Analistas, programadores y demás personal informático, también los administradores deben poner algo de su parte: tener el Servidor en una habitación separada, solamente permitir ingresar a esa habitación al personal autorizado, controlar quienes entran, que hicieron, y quienes salen, etc.
Pero algo es indudable: las tablas .DBF son muchísimo más vulnerables que las tablas SQL.
¿Se puede aumentar la seguridad de las tablas .DBF? Claro que sí, y hay varios métodos para conseguirlo, pero intrínsicamente son más vulnerables que las tablas SQL.
¿Cuánto tiempo tardarías tú en leer el contenido de una tabla .DBF que no esté protegida? ¿Un segundo? ¿Y cuánto tiempo tardarías en leer el contenido de una tabla SQL que pertenece a una Base de Datos de la cual no conoces ni el nombre ni la contraseña? Sin ninguna duda, muchísimo más tiempo.
Esto es debido al hecho de que en una correcta aplicación Cliente/Servidor los usuarios no conocen siquiera cual es el nombre real de la Base de Datos a la cual se están conectando ni tampoco la contraseña para acceder a ella. Así que cualquier posible intruso lo tendrá bastante más complicado.
Y solamente eso, ya puede hacer una grandísima diferencia en cuanto a la seguridad de los datos.
Por otro lado, lo que tú dices sobre el bidón de gasolina o el martillo no es muy aplicable en la realidad ¿por qué? porque quienes puedan tener acceso a un Servidor estarán mucho más interesados en robar el contenido de la Base de Datos que en destrozarla fisicamente. Muchos beneficios no podrás obtener al destrozar fisicamente una Base de Datos y hasta es muy probable que te vayas preso porque el delito es muy evidente y alguien puede verte haciendo eso. En cambio si robas su contenido puedes eventualmente volverte millonario en dólares o en euros (por ejemplo, si obtienes los datos de las tarjetas de crédito de miles de personas). Y como informáticos ese es nuestro campo y eso es lo que debemos tratar de conseguir: que el acceso no autorizado a las Bases de Datos sea muy difícil o imposible. Lo relacionado con la seguridad física (habitación separada, puertas blindadas, ingreso con tarjeta magnética y huella digital, guardia de seguridad en la puerta, etc., etc., etc.) queda a cargo de la Administración de la empresa, a la cual le podemos sugerir dichas medidas pero no obligarlas a que las sigan.
Saludos.
Walter.
La seguridad de las tablas siempre es un problema, sobre todo en empresas que manejan datos sensibles. Por supuesto que la responsabilidad por mantener los datos seguros no recae solamente en los Analistas, programadores y demás personal informático, también los administradores deben poner algo de su parte: tener el Servidor en una habitación separada, solamente permitir ingresar a esa habitación al personal autorizado, controlar quienes entran, que hicieron, y quienes salen, etc.
Pero algo es indudable: las tablas .DBF son muchísimo más vulnerables que las tablas SQL.
¿Se puede aumentar la seguridad de las tablas .DBF? Claro que sí, y hay varios métodos para conseguirlo, pero intrínsicamente son más vulnerables que las tablas SQL.
¿Cuánto tiempo tardarías tú en leer el contenido de una tabla .DBF que no esté protegida? ¿Un segundo? ¿Y cuánto tiempo tardarías en leer el contenido de una tabla SQL que pertenece a una Base de Datos de la cual no conoces ni el nombre ni la contraseña? Sin ninguna duda, muchísimo más tiempo.
Esto es debido al hecho de que en una correcta aplicación Cliente/Servidor los usuarios no conocen siquiera cual es el nombre real de la Base de Datos a la cual se están conectando ni tampoco la contraseña para acceder a ella. Así que cualquier posible intruso lo tendrá bastante más complicado.
Y solamente eso, ya puede hacer una grandísima diferencia en cuanto a la seguridad de los datos.
Por otro lado, lo que tú dices sobre el bidón de gasolina o el martillo no es muy aplicable en la realidad ¿por qué? porque quienes puedan tener acceso a un Servidor estarán mucho más interesados en robar el contenido de la Base de Datos que en destrozarla fisicamente. Muchos beneficios no podrás obtener al destrozar fisicamente una Base de Datos y hasta es muy probable que te vayas preso porque el delito es muy evidente y alguien puede verte haciendo eso. En cambio si robas su contenido puedes eventualmente volverte millonario en dólares o en euros (por ejemplo, si obtienes los datos de las tarjetas de crédito de miles de personas). Y como informáticos ese es nuestro campo y eso es lo que debemos tratar de conseguir: que el acceso no autorizado a las Bases de Datos sea muy difícil o imposible. Lo relacionado con la seguridad física (habitación separada, puertas blindadas, ingreso con tarjeta magnética y huella digital, guardia de seguridad en la puerta, etc., etc., etc.) queda a cargo de la Administración de la empresa, a la cual le podemos sugerir dichas medidas pero no obligarlas a que las sigan.
Saludos.
Walter.
> Date: Fri, 1 Jul 2011 08:45:38 -0700
> Subject: [vfp] Re: Se pueden esconder las tablas dbf?
Walter R. Ojeda Valiente
Jul 1, 2011, 12:43:02 PM7/1/11
to publice...@googlegroups.com
Pues SQL Server no es el único Servidor SQL que se utiliza. Ni siquiera sé si es el más popular entre los programadores de Visual FoxPro. Yo particularmente nunca lo he utilizado.
Saludos.
Walter.
Saludos.
Walter.
> Date: Fri, 1 Jul 2011 09:16:16 -0700
> Subject: [vfp] Re: Se pueden esconder las tablas dbf?
> From: pablo...@gmail.com
> To: publice...@googlegroups.com
>
HernanCano
Jul 1, 2011, 1:10:34 PM7/1/11
to Comunidad de Visual Foxpro en Español
Hola, muchachos.
Soy hincha de VFP. Todo lo positivo que hay en este tema, lo ratifico.
Los motores SQL no son la panacea si no se siguen reglas mínimas sde
seguridad, las mismas que pueden ser implementadas en archivos DBF o
en general en en cualquier ambiente: xBase o no.
Les comparto un tema que sirve para ésto de asegurar nuestras
aplicaciones: Impersonación.
Espero que alguno informe si le ha sido útil este recolección de
páginas.
Hasta luego.
----------------------------------------------------------------------------------------------------------------------------------------------
http://fox.wikis.com/wc.dll?Wiki~RunAsAnotherUser
http://fox.wikis.com/wc.dll?Wiki~ImpersonateLoggedOnUserAndGetFile()
http://www.mail-archive.com/gu...@mug.org.ar/msg03583.html
http://www.programacion.com/foros/visualfoxpro/seguridad_reded_a_quien_le_interese_124446
http://www.justskins.com/forums/impersonation-and-unc-network-135144.html
http://www.news2news.com/vfp/?group=101&function=867
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B285879
(sorry, es VB)
http://www.west-wind.com/presentations/internetenabling/internetenabling.htm
http://www.experts-exchange.com/Microsoft/Applications/FoxPro/Q_26287066.html
----------------------------------------------------------------------------------------------------------------------------------------------
extremo
Jul 1, 2011, 1:31:14 PM7/1/11
to Comunidad de Visual Foxpro en Español
bueno,
en realidad han sido muy buenas las catedras sobre seguridad de las BD
pero han dado alguna solucion a la pregunta inicial?
Bendiciones
On 1 jul, 13:10, HernanCano <jhernanca...@gmail.com> wrote:
> Hola, muchachos.
>
> Soy hincha de VFP. Todo lo positivo que hay en este tema, lo ratifico.
>
> Los motores SQL no son la panacea si no se siguen reglas mínimas sde
> seguridad, las mismas que pueden ser implementadas en archivos DBF o
> en general en en cualquier ambiente: xBase o no.
>
> Les comparto un tema que sirve para ésto de asegurar nuestras
> aplicaciones: Impersonación.
>
> Espero que alguno informe si le ha sido útil este recolección de
> páginas.
>
> Hasta luego.
>
> ----------------------------------------------------------------------------------------------------------------------------------------------http://fox.wikis.com/wc.dll?Wiki~RunAsAnotherUser
>
> http://fox.wikis.com/wc.dll?Wiki~ImpersonateLoggedOnUserAndGetFile()
>
> http://www.mail-archive.com/g...@mug.org.ar/msg03583.html
>
> http://www.programacion.com/foros/visualfoxpro/seguridad_reded_a_quie...
>
> http://www.justskins.com/forums/impersonation-and-unc-network-135144....
>
> http://www.experts-exchange.com/Microsoft/Applications/FoxPro/Q_26287...
> ----------------------------------------------------------------------------------------------------------------------------------------------
en realidad han sido muy buenas las catedras sobre seguridad de las BD
pero han dado alguna solucion a la pregunta inicial?
Bendiciones
On 1 jul, 13:10, HernanCano <jhernanca...@gmail.com> wrote:
> Hola, muchachos.
>
> Soy hincha de VFP. Todo lo positivo que hay en este tema, lo ratifico.
>
> Los motores SQL no son la panacea si no se siguen reglas mínimas sde
> seguridad, las mismas que pueden ser implementadas en archivos DBF o
> en general en en cualquier ambiente: xBase o no.
>
> Les comparto un tema que sirve para ésto de asegurar nuestras
> aplicaciones: Impersonación.
>
> Espero que alguno informe si le ha sido útil este recolección de
> páginas.
>
> Hasta luego.
>
> ----------------------------------------------------------------------------------------------------------------------------------------------http://fox.wikis.com/wc.dll?Wiki~RunAsAnotherUser
>
> http://fox.wikis.com/wc.dll?Wiki~ImpersonateLoggedOnUserAndGetFile()
>
>
> http://www.programacion.com/foros/visualfoxpro/seguridad_reded_a_quie...
>
> http://www.justskins.com/forums/impersonation-and-unc-network-135144....
>
> http://www.news2news.com/vfp/?group=101&function=867
>
> http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B285879
> (sorry, es VB)
>
> http://www.west-wind.com/presentations/internetenabling/internetenabl...
> http://www.news2news.com/vfp/?group=101&function=867
>
> http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B285879
> (sorry, es VB)
>
>
> http://www.experts-exchange.com/Microsoft/Applications/FoxPro/Q_26287...
> ----------------------------------------------------------------------------------------------------------------------------------------------
Walter R. Ojeda Valiente
Jul 1, 2011, 3:59:29 PM7/1/11
to publice...@googlegroups.com
Pues a mí también me gusta VFP, tiene muchas cosas buenas, eso es innegable, pero no es perfecto (ningún lenguaje lo es) y para el futuro hay que ir pensando en lenguajes que nos permitan hacer programas para dispositivos móviles, computadoras de 128 bits, etc.
Con VFP podremos ir estirando más o menos bien por unos cuantos años más, pero tarde o temprano habrá que sustituirlo por otro. ¿Cuál otro? eso ya depende de cada uno.
Saludos.
Walter.
Con VFP podremos ir estirando más o menos bien por unos cuantos años más, pero tarde o temprano habrá que sustituirlo por otro. ¿Cuál otro? eso ya depende de cada uno.
Saludos.
Walter.
> Date: Fri, 1 Jul 2011 10:10:34 -0700
> Subject: [vfp] Re: Se pueden esconder las tablas dbf?
Carlos Miguel FARIAS
Jul 1, 2011, 6:00:56 PM7/1/11
to publice...@googlegroups.com
Estimo (y no digo creo, porque empezamos con el tema religioso) que antes de decir que dbf o SGBD es uno mejor o no que otro, hay que pararse en el tamaño del sistema que se va a desarrollar, no amerita instalar un sql server en el sistema de gestion del kiosko de la esquina, ni voy a usar dbf en el aplicativo para un banco.
Es cierto que la inseguridad de un sistema (no solo las bd) surge de la inoperancia de los responsables de aplicar medidas de seguridad (60% de los fallos de seguridad, se han hecho por que algún usuario testiculoso dejo a mano la contraseña que le da acceso a un sistema critico).
Si no me creen, lean el Gato y el Raton de de stoll o algo asi, donde un hacker ataco casi todos los servidores del ejercirto de Usa, desde alemania, tomando en muchos casos acceso de usuario root o administrador (no solo del SGBD, del SO!)
Se puede desarrollar perfectamente con tablas dbf, teniendo especial cuidado de procesar los datos solo usando sql (o cursores adapters), luego, si el cliente lo amerita, pasar el desarrollo al sgbd que se considere oportuno (por desempeño y por costo).
Entiendo que para eso se prestan los cursores adapters, que permite hacer transparente
el formulario de a donde se accede.
Saludos: Miguel
Es cierto que la inseguridad de un sistema (no solo las bd) surge de la inoperancia de los responsables de aplicar medidas de seguridad (60% de los fallos de seguridad, se han hecho por que algún usuario testiculoso dejo a mano la contraseña que le da acceso a un sistema critico).
Si no me creen, lean el Gato y el Raton de de stoll o algo asi, donde un hacker ataco casi todos los servidores del ejercirto de Usa, desde alemania, tomando en muchos casos acceso de usuario root o administrador (no solo del SGBD, del SO!)
Se puede desarrollar perfectamente con tablas dbf, teniendo especial cuidado de procesar los datos solo usando sql (o cursores adapters), luego, si el cliente lo amerita, pasar el desarrollo al sgbd que se considere oportuno (por desempeño y por costo).
Entiendo que para eso se prestan los cursores adapters, que permite hacer transparente
el formulario de a donde se accede.
Saludos: Miguel
Walter R. Ojeda Valiente
Jul 1, 2011, 6:44:40 PM7/1/11
to publice...@googlegroups.com
Claro, desde luego.
Yo siempre he defendido el uso de las tablas .DBF ... para sistemas pequeños.
Por ejemplo, si una profesora quiere un programita para llevar el control de las notas de sus alumnos, trabajos prácticos presentados y cosas así, sabiendo que el el programa estará instalado en su casa, en su computadora, y solamente ella tendrá acceso a él, entonces las tablas .DBF son la opción más adecuada.
Pero si el programa debe ser instalado en el colegio, en unas 20 computadoras, que están en red, con conexión a Internet, pues ... hay que olvidarse de las .DBF y pensar en las SQL. Porque la vulnerabilidad es muy grande y los "inocentes estudiantes" aprovecharán la menor oportunidad para mirar y probablemente cambiar, sus calificaciones. Si saben que sus datos se guardan en tablas .DBF, "saltarán en una pata" de la alegría.
Y ni hablar si se trata de un Banco o de alguna otra entidad financiera. Si les propones instalarles o desarrollarles una aplicación cuyos datos se guardarán en tablas .DBF te echarán de allí diciéndote que les estás haciendo perder el tiempo. Y tendrán razón.
Saludos.
Walter.
Date: Fri, 1 Jul 2011 19:00:56 -0300
Subject: Re: [vfp] Re: Se pueden esconder las tablas dbf?
From: carlosmig...@gmail.com
To: publice...@googlegroups.com
Yo siempre he defendido el uso de las tablas .DBF ... para sistemas pequeños.
Por ejemplo, si una profesora quiere un programita para llevar el control de las notas de sus alumnos, trabajos prácticos presentados y cosas así, sabiendo que el el programa estará instalado en su casa, en su computadora, y solamente ella tendrá acceso a él, entonces las tablas .DBF son la opción más adecuada.
Pero si el programa debe ser instalado en el colegio, en unas 20 computadoras, que están en red, con conexión a Internet, pues ... hay que olvidarse de las .DBF y pensar en las SQL. Porque la vulnerabilidad es muy grande y los "inocentes estudiantes" aprovecharán la menor oportunidad para mirar y probablemente cambiar, sus calificaciones. Si saben que sus datos se guardan en tablas .DBF, "saltarán en una pata" de la alegría.
Y ni hablar si se trata de un Banco o de alguna otra entidad financiera. Si les propones instalarles o desarrollarles una aplicación cuyos datos se guardarán en tablas .DBF te echarán de allí diciéndote que les estás haciendo perder el tiempo. Y tendrán razón.
Saludos.
Walter.
Date: Fri, 1 Jul 2011 19:00:56 -0300
Subject: Re: [vfp] Re: Se pueden esconder las tablas dbf?
From: carlosmig...@gmail.com
To: publice...@googlegroups.com
Alfredo Mendoza
Jul 1, 2011, 7:34:50 PM7/1/11
to publice...@googlegroups.com
Saludos, a todos, tengo una pequeña aplicacion, esta esta en cuatro pc, pero la empresa donde lo tengo no tienen un servidor por decirlo asi, es un grupo de trabajo, de repente la persona que tiene la base de datos, reinicia su maquina o la apaga, y entonces cuando cargan mi aplicacion, envia unos mensajes raros, de error, Me gustaria saber como puedo hacer, para capturar el mensaje que DIGA, SE PERDIO LA CONEXION A LA RED, desde mi aplicacion de VFP.
Les comento que en cada maquina tengo el ejecutable, y en la estacion tengo solo la base de datos.
Muchas gracias a todos y espero sus comentarios a el
respecto.
atentamente,
AM
Edgar Acevedo
Jul 1, 2011, 7:46:32 PM7/1/11
to publice...@googlegroups.com
Comparto en mucho tu opinión Walter. Como dije en un hilo anterior: "Cada cosa en su lugar".
Pero aún así te comentaría que como dijo el sabio Albert Einstein: "Todo es relativo..."
En 1,998, una empresa financiera me pidió que le desarrollara un software TOTAL. Como yo no sabía nada de Cliente-Servidor y quería desesperadamente hacer el trabajo, lo hice en FoxPro 2.6 para D.O.S (era lo que sabía usar en aquellos días). Los trucos que utilicé para darle seguridad a las tablas fueron estos:
1- FoxPro para DOS me dejaba utilizar en los nombres de archivo, caracteres extraños escritos con la tecla ALT, pero que en pleno DOS, Windows, y otros paquetes, NO ERAN FACILES de teclear. Específicamente te hablo del ALT+127 y el ALT+255.
2- Los archivos estaban en una ruta oculta. Aunque la mapearas, dicha ruta no se miraba en el windows explorer porque desde el Windows Registry se indicó que dicha ruta estuviera oculta.
3- Los archivos de datos también estaban con atributos ocultos
4- Los archivos de datos NO SON ACCESIBLES a ningún usuario. Para hacerlos accesibles hay que tener derechos de Administración, por eso mi programa internamente cambia de usuario sin que el usuario del programa se de cuenta.
5- Adicionalmente, la "ruta oculta" donde estan los datos, se abre al entrar en sesión al programa y se cierra al salir del programa.
6- Ciertos datos de las tablas (como saldos por ejemplo) estan guardados en campos caracteres encriptados, así que aunque lograran leer las tablas, no lograrían leer algunos campos.
Utilizando esta técnica, luego de 12 meses el sistema completo quedó concluído y en funciones. Hasta la fecha NUNCA NADIE ha leído el contenido de las tablas. Utilicé esta misma técnica en un Colegio con 54 estaciones conectadas. Hasta la fecha NINGUN ALUMNO ha podido hackear las tablas.
No tenemos los bellos recursos de seguridad de un SQL Server o un MySQL, pero a puro ingenio y dedicación logramos hacer sistemas bastante seguros que hasta la fecha NADIE HA logrado invadir. No tengo idea si es porque no lo han intentado o lo han intentado pero no han encontrado la forma. La cosa es que el mas viejo de ellos, ya con 16 años de estar funcionando aún esta intacto y nadie ha sacado nada de información de las tablas.
¿Es comparable en seguridad a un SQL Server o un MySQL? Para nada. No es tan seguro, pero en términos prácticos da igual ya que no ha sido hackeado. Incluso, los sistemas míos que han sido reemplazados por "sistemas mas modernos" (repito irónicamente: "mas modernos"...) no han logrado extraer la data de mis arhivos A PESAR de que por razones de ética profesional, yo he revelado a los "nuevos consultores" los secretos de mis mediocres y pobres medidas de seguridad para que al nuevo sistema puedan integrar la data y no haya pérdida de información.
Claro, que si me hablan de un banco de plano: Nos vamos a Cliente-Servidor a ojos cerrados. Pero un colegio.... mmmm... en mi experiencia propia, no ha sido necesario. El colegio donde yo monté el sistema en el año 1,994 sigue utilizando mi aplicación hecha en FoxPro 2.6 (no han querido migrar a VFP) y esta es la fecha en que ningún alumno ha logrado burlar su seguridad y me consta que SI lo han intentado. Pero creo que esto NO ES GLORIA DE FOXPRO, es mas bien el resultado de una muy bien planificada política de seguirdad que comenzó con una serie de medidas tomadas en la programación de la aplicación y continuada a nivel de Sistema Operativo por los administradores de la red.
Pero aún así te comentaría que como dijo el sabio Albert Einstein: "Todo es relativo..."
En 1,998, una empresa financiera me pidió que le desarrollara un software TOTAL. Como yo no sabía nada de Cliente-Servidor y quería desesperadamente hacer el trabajo, lo hice en FoxPro 2.6 para D.O.S (era lo que sabía usar en aquellos días). Los trucos que utilicé para darle seguridad a las tablas fueron estos:
1- FoxPro para DOS me dejaba utilizar en los nombres de archivo, caracteres extraños escritos con la tecla ALT, pero que en pleno DOS, Windows, y otros paquetes, NO ERAN FACILES de teclear. Específicamente te hablo del ALT+127 y el ALT+255.
2- Los archivos estaban en una ruta oculta. Aunque la mapearas, dicha ruta no se miraba en el windows explorer porque desde el Windows Registry se indicó que dicha ruta estuviera oculta.
3- Los archivos de datos también estaban con atributos ocultos
4- Los archivos de datos NO SON ACCESIBLES a ningún usuario. Para hacerlos accesibles hay que tener derechos de Administración, por eso mi programa internamente cambia de usuario sin que el usuario del programa se de cuenta.
5- Adicionalmente, la "ruta oculta" donde estan los datos, se abre al entrar en sesión al programa y se cierra al salir del programa.
6- Ciertos datos de las tablas (como saldos por ejemplo) estan guardados en campos caracteres encriptados, así que aunque lograran leer las tablas, no lograrían leer algunos campos.
Utilizando esta técnica, luego de 12 meses el sistema completo quedó concluído y en funciones. Hasta la fecha NUNCA NADIE ha leído el contenido de las tablas. Utilicé esta misma técnica en un Colegio con 54 estaciones conectadas. Hasta la fecha NINGUN ALUMNO ha podido hackear las tablas.
No tenemos los bellos recursos de seguridad de un SQL Server o un MySQL, pero a puro ingenio y dedicación logramos hacer sistemas bastante seguros que hasta la fecha NADIE HA logrado invadir. No tengo idea si es porque no lo han intentado o lo han intentado pero no han encontrado la forma. La cosa es que el mas viejo de ellos, ya con 16 años de estar funcionando aún esta intacto y nadie ha sacado nada de información de las tablas.
¿Es comparable en seguridad a un SQL Server o un MySQL? Para nada. No es tan seguro, pero en términos prácticos da igual ya que no ha sido hackeado. Incluso, los sistemas míos que han sido reemplazados por "sistemas mas modernos" (repito irónicamente: "mas modernos"...) no han logrado extraer la data de mis arhivos A PESAR de que por razones de ética profesional, yo he revelado a los "nuevos consultores" los secretos de mis mediocres y pobres medidas de seguridad para que al nuevo sistema puedan integrar la data y no haya pérdida de información.
Claro, que si me hablan de un banco de plano: Nos vamos a Cliente-Servidor a ojos cerrados. Pero un colegio.... mmmm... en mi experiencia propia, no ha sido necesario. El colegio donde yo monté el sistema en el año 1,994 sigue utilizando mi aplicación hecha en FoxPro 2.6 (no han querido migrar a VFP) y esta es la fecha en que ningún alumno ha logrado burlar su seguridad y me consta que SI lo han intentado. Pero creo que esto NO ES GLORIA DE FOXPRO, es mas bien el resultado de una muy bien planificada política de seguirdad que comenzó con una serie de medidas tomadas en la programación de la aplicación y continuada a nivel de Sistema Operativo por los administradores de la red.
Edgar Acevedo
Jul 1, 2011, 7:57:22 PM7/1/11
to publice...@googlegroups.com
Ojalá alguien te de una mejor idea que la mía para hacer algo mejor. Pero lo que yo hago es los siguiente:
1- Utilizo IP fijos en la red y tomo nota del IP de la estación donde estan las Tablas DBF que utilizo.
2- Agrego a mi programa la siguiente función (no estoy seguro si su autor es Luis María Guyan):
FUNCTION DO_PING
LPARAMETERS M.DirHos, M.NumPtoo
LOCAL TestWS, M.PngRet, M.CntSec
TestWS = CREATEOBJECT("MSWinSock.Winsock")
TestWS.Connect(M.DirHos, M.NumPtoo)
M.CntSec = SECONDS()
DO WHILE SECONDS()-M.CntSec < .3
ENDDO
IF TestWS.state = 7 OR TestWS.state = 9
M.PngRet = .T.
ENDIF
TestWS.Close()
RELEASE TestWS
RETURN M.PngRet
3- Luego, cuando necesito usar las tablas, pregunto antes mediante esta función, si la
estación donde estan las tablas está en línea. Asumamos que la estación donde estan
las tablas tiene la siguiente dirección IP: 192.168.1.10
IF DO_PING("192.168.1.10", 80)
* Si está en línea el servidor de tablas DBF
ELSE
MESSAGEBOX("No esta encendido el equipo con los Archivos", 0, "Error de Origen de Datos")
ENDIF
1- Utilizo IP fijos en la red y tomo nota del IP de la estación donde estan las Tablas DBF que utilizo.
2- Agrego a mi programa la siguiente función (no estoy seguro si su autor es Luis María Guyan):
FUNCTION DO_PING
LPARAMETERS M.DirHos, M.NumPtoo
LOCAL TestWS, M.PngRet, M.CntSec
TestWS = CREATEOBJECT("MSWinSock.Winsock")
TestWS.Connect(M.DirHos, M.NumPtoo)
M.CntSec = SECONDS()
DO WHILE SECONDS()-M.CntSec < .3
ENDDO
IF TestWS.state = 7 OR TestWS.state = 9
M.PngRet = .T.
ENDIF
TestWS.Close()
RELEASE TestWS
RETURN M.PngRet
3- Luego, cuando necesito usar las tablas, pregunto antes mediante esta función, si la
estación donde estan las tablas está en línea. Asumamos que la estación donde estan
las tablas tiene la siguiente dirección IP: 192.168.1.10
IF DO_PING("192.168.1.10", 80)
* Si está en línea el servidor de tablas DBF
ELSE
MESSAGEBOX("No esta encendido el equipo con los Archivos", 0, "Error de Origen de Datos")
ENDIF
Walter R. Ojeda Valiente
Jul 1, 2011, 7:57:52 PM7/1/11
to publice...@googlegroups.com
Hola Edgar
Claro, tienes toda la razón, se pueden buscar y adoptar medidas de seguridad adicionales para que las tablas .DBF no sean tan vulnerables. Inclusive puedes contratar a un guardia de seguridad que mire a todos con cara de perro salvaje y que se pasee revoloteando una cachiporra en la mano.
Pero...yo no confiaría mucho en que dichas tablas no puedan ser hackeadas. No te digo que cualquiera podría hacerlo, pero apostaría que en este grupo hay al menos 10 personas que tenemos esa capacidad.
Tampoco las tablas SQL son invulnerables, claro que no, pero al menos le hacen la vida bastante más difícil al intruso.
Saludos.
Walter.
Date: Fri, 1 Jul 2011 17:46:32 -0600
Claro, tienes toda la razón, se pueden buscar y adoptar medidas de seguridad adicionales para que las tablas .DBF no sean tan vulnerables. Inclusive puedes contratar a un guardia de seguridad que mire a todos con cara de perro salvaje y que se pasee revoloteando una cachiporra en la mano.
Pero...yo no confiaría mucho en que dichas tablas no puedan ser hackeadas. No te digo que cualquiera podría hacerlo, pero apostaría que en este grupo hay al menos 10 personas que tenemos esa capacidad.
Tampoco las tablas SQL son invulnerables, claro que no, pero al menos le hacen la vida bastante más difícil al intruso.
Saludos.
Walter.
Date: Fri, 1 Jul 2011 17:46:32 -0600
Subject: Re: [vfp] Re: Se pueden esconder las tablas dbf?
Edgar Acevedo
Jul 1, 2011, 8:02:51 PM7/1/11
to publice...@googlegroups.com
Ja, ja, ja, ja, que buena esa de: " Inclusive puedes contratar a un guardia de seguridad que mire a todos con cara de perro salvaje..."
Me encantó la paráfrasis...! De hecho, conozco a un par de viejas horrorosas con cara de bestiglo que harían muy bien ese trabajo...!
Coincido contigo completamente amigo...!!!!!
De ahora en adelante cuando piense en medidas de seguridad, tomaré muy encuenta la posibilidad de contratar a una de estas viejas horripilas...!
Ja, ja, ja, ja
Me encantó la paráfrasis...! De hecho, conozco a un par de viejas horrorosas con cara de bestiglo que harían muy bien ese trabajo...!
Coincido contigo completamente amigo...!!!!!
De ahora en adelante cuando piense en medidas de seguridad, tomaré muy encuenta la posibilidad de contratar a una de estas viejas horripilas...!
Ja, ja, ja, ja
Walter R. Ojeda Valiente
Jul 1, 2011, 8:03:10 PM7/1/11
to publice...@googlegroups.com
Escencialmente es lo que hacía yo también cuando usaba tablas .DBF, un PING al Servidor para saber si la conexión estaba activa.
Saludos.
Walter.
Date: Fri, 1 Jul 2011 17:57:22 -0600
Subject: Re: [vfp] Como saber si se perdio la conexion de red desde VFP
From: aper...@gmail.com
To: publice...@googlegroups.com
Saludos.
Walter.
Date: Fri, 1 Jul 2011 17:57:22 -0600
Subject: Re: [vfp] Como saber si se perdio la conexion de red desde VFP
From: aper...@gmail.com
To: publice...@googlegroups.com
Walter R. Ojeda Valiente
Jul 1, 2011, 8:07:52 PM7/1/11
to publice...@googlegroups.com
Hola Edgar
Pero no es solamente la cara fea, también debe poder aplicar alguna medida coercitiva, por eso lo de "revoloteando una cachiporra en la mano". O sea que si haces lo que se supone no debes estar haciendo entonces te ligas un cachiporrazo.
:-(
Saludos.
Walter.
Date: Fri, 1 Jul 2011 18:02:51 -0600
Pero no es solamente la cara fea, también debe poder aplicar alguna medida coercitiva, por eso lo de "revoloteando una cachiporra en la mano". O sea que si haces lo que se supone no debes estar haciendo entonces te ligas un cachiporrazo.
:-(
Saludos.
Walter.
Date: Fri, 1 Jul 2011 18:02:51 -0600
Edgar Acevedo
Jul 1, 2011, 8:14:20 PM7/1/11
to publice...@googlegroups.com
Bueno, se me ocurre que la medida coercitiva sería que al que intente violar la seguridad del sistema, sea obligado a tener sexo con alguna de esa viejas horrorosas.
Es que son de esas viejas que aparte de feas, son malvadas, ineptas y viven cometiendo toda clase de errores con tu sistema pero te hechan a ti la culpa de su incompetencia.
Viejas desgraciadas...!
Es que son de esas viejas que aparte de feas, son malvadas, ineptas y viven cometiendo toda clase de errores con tu sistema pero te hechan a ti la culpa de su incompetencia.
Viejas desgraciadas...!
Ricardo Pina
Jul 1, 2011, 8:24:47 PM7/1/11
to publice...@googlegroups.com
Bueno, por lo menos estas seguro que las señoras entradas en edad y poco agraciadas no le van a llenar la cabeza al jefe en la cama!!
Saludos
Ricardo Pina
D&SIP
Desarrollo y Servicios Informáticos Profesionales
www.dsip.com.ar
Miguel Castillo
Jul 1, 2011, 8:57:32 PM7/1/11
to publice...@googlegroups.com
gracias pablo por tu aporte lo voy a revisar porque eso de poner las viejas a cuidar la bd esta medio complicado jaja
saludos
saludos
> Date: Fri, 1 Jul 2011 08:51:41 -0700
> Subject: [vfp] Re: Se pueden esconder las tablas dbf?
Miguel Castillo
Jul 1, 2011, 8:59:31 PM7/1/11
to publice...@googlegroups.com
gracias Daniel por tu aporte lo voy a revisar a ver que tal me sale
saludos
Miguel
From: daniel_es...@hotmail.com
To: publice...@googlegroups.com
Subject: RE: [vfp] Re: Se pueden esconder las tablas dbf?
Date: Fri, 1 Jul 2011 10:35:21 -0400
saludos
Miguel
From: daniel_es...@hotmail.com
To: publice...@googlegroups.com
Subject: RE: [vfp] Re: Se pueden esconder las tablas dbf?
Date: Fri, 1 Jul 2011 10:35:21 -0400
la otra solucion que se me ocurre, pero va a dar un poco mas de trabajo de programacion es que encriptes la informacion de las tablas de fforma a que solo la aplicacion las pueda entender y usar cualquiera que abra una tabla no va a poder entender su contenido, pero eso implica que lo encriptes al grabar y lo desencriptes al leer la tabla en la ayuda de vfp hay ejemplos de como encriptar, podes hacer una ffuncion u objeto que se encarge de este trabajo eso va a estar en la aplicacion y va a ser transparente para el usuario, y va a dejar las tablas nolegibles para cualquiera que no sea la aplicacion
espero que sea util.
daniel Estigarribia
Asuncion-Paraguay
Asuncion-Paraguay
> Date: Fri, 1 Jul 2011 07:03:18 -0700
> Subject: [vfp] Re: Se pueden esconder las tablas dbf?
> From: protech...@gmail.com
> To: publice...@googlegroups.com
>
> Miguel, lo que puedes hacer es cambiar la extencion a tus dbf ejemplo
>
> en vez de tabla.dbf, coloca tabla.dll o tabla.reg, etc, la extencion
> queda a tu imaginacion. eso si para despues llamar esa tabla debes
> hacer lo siguiente:
>
> si le colocas a tu tabla el nombre tabla.dll en vfp debes abrirla de
> la siguiente forma
>
> use tabla.dll in 0
>
> asi de simple
>
> Bendiciones
>
>
>
> On 30 jun, 21:47, "Walter R. Ojeda Valiente" <w...@hotmail.com> wrote:
> > Pues ese es justamente uno de los grandes problemas de las tablas .DBF
> >
> > Otro, no menos importante, es que pueden ser abiertas con casi cualquier programa: Word, Excel, Notepad, etc.
> >
> > Una alternativa es que migres a SQL, allí podrás tenerlas ocultas a los ojos de los curiosos.
> >
> > Otra alternativa es que les cambies el atributo a oculto. No es muy efectivo, pero en algo puede ayudar.
> >
> > Otra alternativa es que uses algunos de los programas que te permiten ocultar carpetas, las cuales solamente se pueden abrir con una contraseña.
> >
> > Otra alternativa más, es que las coloques en la subcarpeta, de la subcarpeta, de la subcarpeta, de la subcarpeta, de la subcarpeta de tu aplicación.
> >
> > Aunque siempre lo mejor sigue siendo que migres a SQL.
> >
> > Saludos.
> >
> > Walter.
> >
> > From: mike711...@hotmail.com
> > To: publice...@googlegroups.com
> > Subject: [vfp] Se pueden esconder las tablas dbf?
> > Date: Thu, 30 Jun 2011 20:35:38 -0500
> >
> > el asunto es que estoy preparando un programa para su distribucion pero al entrar a la carpeta del programa me encuentro con todas las tablas dbf a la vista y siento como que si mi programa esta medio desnudo pues cualquiera puede entrar en ellas
> > Saludos a todos
> To: publice...@googlegroups.com
>
> Miguel, lo que puedes hacer es cambiar la extencion a tus dbf ejemplo
>
> en vez de tabla.dbf, coloca tabla.dll o tabla.reg, etc, la extencion
> queda a tu imaginacion. eso si para despues llamar esa tabla debes
> hacer lo siguiente:
>
> si le colocas a tu tabla el nombre tabla.dll en vfp debes abrirla de
> la siguiente forma
>
> use tabla.dll in 0
>
> asi de simple
>
> Bendiciones
>
>
>
> On 30 jun, 21:47, "Walter R. Ojeda Valiente" <w...@hotmail.com> wrote:
> > Pues ese es justamente uno de los grandes problemas de las tablas .DBF
> >
> > Otro, no menos importante, es que pueden ser abiertas con casi cualquier programa: Word, Excel, Notepad, etc.
> >
> > Una alternativa es que migres a SQL, allí podrás tenerlas ocultas a los ojos de los curiosos.
> >
> > Otra alternativa es que les cambies el atributo a oculto. No es muy efectivo, pero en algo puede ayudar.
> >
> > Otra alternativa es que uses algunos de los programas que te permiten ocultar carpetas, las cuales solamente se pueden abrir con una contraseña.
> >
> > Otra alternativa más, es que las coloques en la subcarpeta, de la subcarpeta, de la subcarpeta, de la subcarpeta, de la subcarpeta de tu aplicación.
> >
> > Aunque siempre lo mejor sigue siendo que migres a SQL.
> >
> > Saludos.
> >
> > Walter.
> >
> > From: mike711...@hotmail.com
> > To: publice...@googlegroups.com
> > Subject: [vfp] Se pueden esconder las tablas dbf?
> > Date: Thu, 30 Jun 2011 20:35:38 -0500
> >
> > el asunto es que estoy preparando un programa para su distribucion pero al entrar a la carpeta del programa me encuentro con todas las tablas dbf a la vista y siento como que si mi programa esta medio desnudo pues cualquiera puede entrar en ellas
> > Saludos a todos
Miguel Castillo
Jul 1, 2011, 9:03:26 PM7/1/11
to publice...@googlegroups.com
Esa me parece buenisimo para engañar oponerlos a pensar un poquito a los roba datos gracias por tu aporte esta interesante
Saludos
Miguel
Saludos
Miguel
Miguel Castillo
Jul 1, 2011, 9:44:56 PM7/1/11
to publice...@googlegroups.com
esta perfecto edgar creo que podemos realizar muchas cosas entre todos a que sera mas segura que en sql.... gracias
Saludos
Miguel
Date: Fri, 1 Jul 2011 09:47:43 -0600
Subject: Re: [vfp] Se pueden esconder las tablas dbf?
From: aper...@gmail.com
To: publice...@googlegroups.com
Miguel:
Yo programo desde 1,990. Comencé con FoxBase Plus. Luego pasé con FoxPro 1.0, FoxPro 2.0 y fue con FoxPro 2.6 con lo que hice programas ya a un nivel que podríamos decir "comercial". Me pasé hasta VFP 9 apenas hace un año porque tenía tantos clientes corriendo con mis viejos programas de FoxPro 2.6 que no me dejaban tiempo para meterme de lleno a VFP 9. Clientes contentos y complacidos con sus viejas aplicaciones hechas en FoxPro 2.6 para DOS. Cuando les mencioné que sería bueno hacer la migración a VFP 9 siempre me salían con una muy buena pregunta: ¿Porqué, si lo que que tenemos en FoxPro 2.6 para DOS funciona bien, es estable, no tiene limitaciones y aún hemos podido seguir haciéndole actualizaciones para nuestras necesidades ?
Desde hace mucho tiempo, para que se metan con mis tablas DBF hago algo que ya te sugirieron mas arriba:
- Cambio de nombre a los DBF y les pongo extensión DTS
- He agregado unos pocos archivos con extensión DTS para "despistar" un poco al posible intruso.
- He cambiado el atributo de las tablas a "oculto", así como de los archivos DTS inservibles y que solo uso para despistar.
También oculto otros archivos con otras extensiones.
Vengo haciendo esto desde 1,995. Para hoy, ya han transcurrido 16 años y NADIE, NUNCA ha abierto mis tablas y extraído información. Incluso, cuando han desplazado a mis sistemas por otros y han querido extraer información de mis tablas para incorporarlas al nuevo sistema, NO HAN PODIDO. Han tenido que llamarme para que les entreguelos datos "viejos" en archivos planos, para poderlos meter en la nueva aplicación.
No digo con esto que las tablas de VFP sean "intocables". Ciertamente son bastante vulnerables, pero si le complicas un poco las cosas a los "posibles tentontes", dificilmente tienen la capacidad técnica o el tiempo para tratar de adivinar como abrir tus archivos.
Alguien por allí te dijo que lo mejor es usar una BD profesional como SQL, MySQL y PostgreSQL. Ciertamente estas BD's son enormemente mas seguras pero NO SON INTOCABLES. Conozco el caso de un hacker local que logró abrir una BD en MySQL que funcionaba en un sitio web del gobierno. También en las noticias habrás oído de hackers que se meten con sistemas "impenetrables" del gobierno de EEUU. Los hackers han demostrado una y otra vez que practicamente "lo impenetrable" NO EXISTE.
Mis aplicaciones jamás han sido blanco de un hacker profesional. Nunca les han interesado mis aplicaciones ¿ para qué....?
Y creo que si algún día un hacker profesional decidiera "hacerme su blanco", no importa que mis tablas esten en MySQL, Firebird o PostgreSQL. Un tipo de esos, con toda su inteligencia y recursos técnicos de su lado, encontrará la forma de "voltearle los empaques" y violar mis tablas, estén en lo que estén.
Creo que lo mejor que se puede hacer es relajarse, sacudirse la paranoia, tomar ciertas medidas "razonablemente" seguras y esperar lo mejor. Si pasara lo peor, creo que ya era cosa del destino...
Salu2,
Edgar
Saludos
Miguel
Date: Fri, 1 Jul 2011 09:47:43 -0600
Subject: Re: [vfp] Se pueden esconder las tablas dbf?
From: aper...@gmail.com
To: publice...@googlegroups.com
Miguel:
Yo programo desde 1,990. Comencé con FoxBase Plus. Luego pasé con FoxPro 1.0, FoxPro 2.0 y fue con FoxPro 2.6 con lo que hice programas ya a un nivel que podríamos decir "comercial". Me pasé hasta VFP 9 apenas hace un año porque tenía tantos clientes corriendo con mis viejos programas de FoxPro 2.6 que no me dejaban tiempo para meterme de lleno a VFP 9. Clientes contentos y complacidos con sus viejas aplicaciones hechas en FoxPro 2.6 para DOS. Cuando les mencioné que sería bueno hacer la migración a VFP 9 siempre me salían con una muy buena pregunta: ¿Porqué, si lo que que tenemos en FoxPro 2.6 para DOS funciona bien, es estable, no tiene limitaciones y aún hemos podido seguir haciéndole actualizaciones para nuestras necesidades ?
Desde hace mucho tiempo, para que se metan con mis tablas DBF hago algo que ya te sugirieron mas arriba:
- Cambio de nombre a los DBF y les pongo extensión DTS
- He agregado unos pocos archivos con extensión DTS para "despistar" un poco al posible intruso.
- He cambiado el atributo de las tablas a "oculto", así como de los archivos DTS inservibles y que solo uso para despistar.
También oculto otros archivos con otras extensiones.
Vengo haciendo esto desde 1,995. Para hoy, ya han transcurrido 16 años y NADIE, NUNCA ha abierto mis tablas y extraído información. Incluso, cuando han desplazado a mis sistemas por otros y han querido extraer información de mis tablas para incorporarlas al nuevo sistema, NO HAN PODIDO. Han tenido que llamarme para que les entreguelos datos "viejos" en archivos planos, para poderlos meter en la nueva aplicación.
No digo con esto que las tablas de VFP sean "intocables". Ciertamente son bastante vulnerables, pero si le complicas un poco las cosas a los "posibles tentontes", dificilmente tienen la capacidad técnica o el tiempo para tratar de adivinar como abrir tus archivos.
Alguien por allí te dijo que lo mejor es usar una BD profesional como SQL, MySQL y PostgreSQL. Ciertamente estas BD's son enormemente mas seguras pero NO SON INTOCABLES. Conozco el caso de un hacker local que logró abrir una BD en MySQL que funcionaba en un sitio web del gobierno. También en las noticias habrás oído de hackers que se meten con sistemas "impenetrables" del gobierno de EEUU. Los hackers han demostrado una y otra vez que practicamente "lo impenetrable" NO EXISTE.
Mis aplicaciones jamás han sido blanco de un hacker profesional. Nunca les han interesado mis aplicaciones ¿ para qué....?
Y creo que si algún día un hacker profesional decidiera "hacerme su blanco", no importa que mis tablas esten en MySQL, Firebird o PostgreSQL. Un tipo de esos, con toda su inteligencia y recursos técnicos de su lado, encontrará la forma de "voltearle los empaques" y violar mis tablas, estén en lo que estén.
Creo que lo mejor que se puede hacer es relajarse, sacudirse la paranoia, tomar ciertas medidas "razonablemente" seguras y esperar lo mejor. Si pasara lo peor, creo que ya era cosa del destino...
Salu2,
Edgar
Carlos Miguel FARIAS
Jul 2, 2011, 10:01:16 AM7/2/11
to publice...@googlegroups.com
Y aún con esas viejas, logra violar la seguridad (seguro uso llave sexual con las viejas) se merece el premio de acceder a los datos, de acceder al paraiso (solo si son creyentes) y el calificativo de ASQUEROSOS!!! 
Luis Mata
Jun 30, 2011, 10:43:33 PM6/30/11
to publice...@googlegroups.com
El problema de siempre, quizas ocultar pero no garantiza nada usa $
al compartir
Marco Plaza
Jul 2, 2011, 10:12:43 PM7/2/11
to Comunidad de Visual Foxpro en Español
Hola casualmente estoy trabajando en la seguridad de los dbfs.
Una cosa que siempre me ha preocupado es la inyección y manipulación
de
datos por terceros, pero no me animo a instalarle sqlserver o mysql a
mis clientes, lo que como
dice Miguel tampoco te asegura que nadie ha tocado los datos y sería
otra cosa mas de que preocuparse...
Puedes usar ODBC con impersonación, pero seguirás compartiendo la
carpeta en la red con el lleva y trae de datos, y un pc lento
te puede ralentizar todo, o dañar la data ( en casos extremos ) si
hay fallas de comunicación
( wifi - cables o adaptadores de red malos ) y los archivos son muy
grandes.
Si es imprescindible asegurar la data necesitas un servidor de base de
datos.
Como tengo aplicaciones comerciales que han crecido mucho
( instalaciones con hasta 45 pcs y data sensible )
decidí programar un servidor COM+ en VFP que atienda todas las
actualizaciónes y consultas de datos,
firmando los registros usando un algoritmo de seguridad md5 con los
campos claves del registro
que me asegure que fueron creados por un usuario logeado en mi
aplicación.
La idea aquí es tener un servidor VFP escuchando y procesando las
peticiones tal como lo hace mysql o sqlserver
pero claro usando los dbfs, de manera que podremos crear verdaderas
aplicaciones cliente servidor a muy bajo costo,
con log de transacciones, manejo de sesiones, backup en caliente,
posibilidad de responder en multiples formatos ( json, xml, dbfs
comprimidos )
de manera que pueda atender peticiones como servidor Web o local. Eso
no quita que pueda cambiar mas a delante a MySql o SqlServer, porque
el servidor VFP usará ODBC para sus operaciones.
Es un proyecto que estoy acometiendo y que espero compartir cuando
esté en producción. Si alguien ha hecho algo similar me gustará
escuchar sus
experiencias, y abrimos un debate acerca de este proyecto para que
podamos aportar ideas.
VFPServer 1.0 no les suena bien?
Saludos.
Marco.
Vamos a ver si abrimos
On 1 jul, 18:00, Carlos Miguel FARIAS <carlosmiguelfar...@gmail.com>
wrote:
> Estimo (y no digo creo, porque empezamos con el tema religioso) que antes de
> decir que dbf o SGBD es uno mejor o no que otro, hay que pararse en el
> tamaño del sistema que se va a desarrollar, no amerita instalar un sql
> server en el sistema de gestion del kiosko de la esquina, ni voy a usar dbf
> en el aplicativo para un banco.
>
> Es cierto que la inseguridad de un sistema (no solo las bd) surge de la
> inoperancia de los responsables de aplicar medidas de seguridad (60% de los
> fallos de seguridad, se han hecho por que algún usuario testiculoso dejo a
> mano la contraseña que le da acceso a un sistema critico).
>
> Si no me creen, lean el Gato y el Raton de de stoll o algo asi, donde un
> hacker ataco casi todos los servidores del ejercirto de Usa, desde alemania,
> tomando en muchos casos acceso de usuario root o administrador (no solo del
> SGBD, del SO!)
>
> Se puede desarrollar perfectamente con tablas dbf, teniendo especial cuidado
> de procesar los datos solo usando sql (o cursores adapters), luego, si el
> cliente lo amerita, pasar el desarrollo al sgbd que se considere oportuno
> (por desempeño y por costo).
>
> Entiendo que para eso se prestan los cursores adapters, que permite hacer
> transparente
> el formulario de a donde se accede.
>
> Saludos: Miguel
>
> El 1 de julio de 2011 16:59, Walter R. Ojeda Valiente
> <w...@hotmail.com>escribió:> Pues a mí también me gusta VFP, tiene muchas cosas buenas, eso es
> decir que dbf o SGBD es uno mejor o no que otro, hay que pararse en el
> tamaño del sistema que se va a desarrollar, no amerita instalar un sql
> server en el sistema de gestion del kiosko de la esquina, ni voy a usar dbf
> en el aplicativo para un banco.
>
> Es cierto que la inseguridad de un sistema (no solo las bd) surge de la
> inoperancia de los responsables de aplicar medidas de seguridad (60% de los
> fallos de seguridad, se han hecho por que algún usuario testiculoso dejo a
> mano la contraseña que le da acceso a un sistema critico).
>
> Si no me creen, lean el Gato y el Raton de de stoll o algo asi, donde un
> hacker ataco casi todos los servidores del ejercirto de Usa, desde alemania,
> tomando en muchos casos acceso de usuario root o administrador (no solo del
> SGBD, del SO!)
>
> Se puede desarrollar perfectamente con tablas dbf, teniendo especial cuidado
> de procesar los datos solo usando sql (o cursores adapters), luego, si el
> cliente lo amerita, pasar el desarrollo al sgbd que se considere oportuno
> (por desempeño y por costo).
>
> Entiendo que para eso se prestan los cursores adapters, que permite hacer
> transparente
> el formulario de a donde se accede.
>
> Saludos: Miguel
>
> El 1 de julio de 2011 16:59, Walter R. Ojeda Valiente
> > innegable, pero no es perfecto (ningún lenguaje lo es) y para el futuro hay
> > que ir pensando en lenguajes que nos permitan hacer programas para
> > dispositivos móviles, computadoras de 128 bits, etc.
>
> > Con VFP podremos ir estirando más o menos bien por unos cuantos años más,
> > pero tarde o temprano habrá que sustituirlo por otro. ¿Cuál otro? eso ya
> > depende de cada uno.
>
> > Saludos.
>
> > Walter.
>
> > > Date: Fri, 1 Jul 2011 10:10:34 -0700
>
> > > Subject: [vfp] Re: Se pueden esconder las tablas dbf?
> > > From: jhernanca...@gmail.com> > To:publice...@googlegroups.com
> > que ir pensando en lenguajes que nos permitan hacer programas para
> > dispositivos móviles, computadoras de 128 bits, etc.
>
> > Con VFP podremos ir estirando más o menos bien por unos cuantos años más,
> > pero tarde o temprano habrá que sustituirlo por otro. ¿Cuál otro? eso ya
> > depende de cada uno.
>
> > Saludos.
>
> > Walter.
>
> > > Date: Fri, 1 Jul 2011 10:10:34 -0700
>
> > > Subject: [vfp] Re: Se pueden esconder las tablas dbf?
>
> > > Hola, muchachos.
>
> > > Soy hincha de VFP. Todo lo positivo que hay en este tema, lo ratifico.
>
> > > Los motores SQL no son la panacea si no se siguen reglas mínimas sde
> > > seguridad, las mismas que pueden ser implementadas en archivos DBF o
> > > en general en en cualquier ambiente: xBase o no.
>
> > > Les comparto un tema que sirve para ésto de asegurar nuestras
> > > aplicaciones: Impersonación.
>
> > > Espero que alguno informe si le ha sido útil este recolección de
> > > páginas.
>
> > > Hasta luego.
>
> > ----------------------------------------------------------------------------------------------------------------------------------------------
> > >http://fox.wikis.com/wc.dll?Wiki~RunAsAnotherUser
>
> > >http://fox.wikis.com/wc.dll?Wiki~ImpersonateLoggedOnUserAndGetFile()
>
> > > Hola, muchachos.
>
> > > Soy hincha de VFP. Todo lo positivo que hay en este tema, lo ratifico.
>
> > > Los motores SQL no son la panacea si no se siguen reglas mínimas sde
> > > seguridad, las mismas que pueden ser implementadas en archivos DBF o
> > > en general en en cualquier ambiente: xBase o no.
>
> > > Les comparto un tema que sirve para ésto de asegurar nuestras
> > > aplicaciones: Impersonación.
>
> > > Espero que alguno informe si le ha sido útil este recolección de
> > > páginas.
>
> > > Hasta luego.
>
> > ----------------------------------------------------------------------------------------------------------------------------------------------
> > >http://fox.wikis.com/wc.dll?Wiki~RunAsAnotherUser
>
> > >http://fox.wikis.com/wc.dll?Wiki~ImpersonateLoggedOnUserAndGetFile()
>
> > >http://www.mail-archive.com/g...@mug.org.ar/msg03583.html
>
> >http://www.programacion.com/foros/visualfoxpro/seguridad_reded_a_quie...
>
> >http://www.justskins.com/forums/impersonation-and-unc-network-135144....
>
>
> >http://www.programacion.com/foros/visualfoxpro/seguridad_reded_a_quie...
>
> >http://www.justskins.com/forums/impersonation-and-unc-network-135144....
>
> > >http://www.news2news.com/vfp/?group=101&function=867
>
> > >http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B285879
> > > (sorry, es VB)
>
> >http://www.west-wind.com/presentations/internetenabling/internetenabl...
>
> > >http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B285879
> > > (sorry, es VB)
>
>
> >http://www.experts-exchange.com/Microsoft/Applications/FoxPro/Q_26287...
>
> > ----------------------------------------------------------------------------------------------------------------------------------------------
Walter R. Ojeda Valiente
Jul 2, 2011, 10:37:14 PM7/2/11
to publice...@googlegroups.com
Hola Marco
Tienes un error de concepto. Si usas SQL no estás compartiendo alguna carpeta. La comunicación con la Base de Datos se hace a través de un puerto de la PC, no hay carpetas compartidas.
Si la PC es lenta, esa es una razón más para usar SQL, el tráfico de red usando tablas SQL es mucho menor que el tráfico de red usando tablas .DBF. Y al ser el tráfico menor, la velocidad es mayor.
Si usas una Base de Datos SQL no importa el tamaño de tus tablas ni de tus Bases de Datos, tengan el tamaño que tengan siempre el acceso será rapidísimo porque el proceso se hace en el Servidor y al Cliente se envían solamente los datos relevantes.
Es interesante tu proyecto, pero me parece que estás queriendo reinventar la rueda. Si ya tienes algo que funciona muy bien y gratis (el caso de Firebird SQL) ¿por qué molestarte en tratar de emularlo con las tablas .DBF siendo que te llevará muchísimo tiempo hacerlo y probablemente no te salga tan bueno?
Saludos.
Walter.
Tienes un error de concepto. Si usas SQL no estás compartiendo alguna carpeta. La comunicación con la Base de Datos se hace a través de un puerto de la PC, no hay carpetas compartidas.
Si la PC es lenta, esa es una razón más para usar SQL, el tráfico de red usando tablas SQL es mucho menor que el tráfico de red usando tablas .DBF. Y al ser el tráfico menor, la velocidad es mayor.
Si usas una Base de Datos SQL no importa el tamaño de tus tablas ni de tus Bases de Datos, tengan el tamaño que tengan siempre el acceso será rapidísimo porque el proceso se hace en el Servidor y al Cliente se envían solamente los datos relevantes.
Es interesante tu proyecto, pero me parece que estás queriendo reinventar la rueda. Si ya tienes algo que funciona muy bien y gratis (el caso de Firebird SQL) ¿por qué molestarte en tratar de emularlo con las tablas .DBF siendo que te llevará muchísimo tiempo hacerlo y probablemente no te salga tan bueno?
Saludos.
Walter.
> Date: Sat, 2 Jul 2011 19:12:43 -0700
> Subject: [vfp] Re: Se pueden esconder las tablas dbf?
Luis Mata
Jul 2, 2011, 10:51:42 PM7/2/11
to publice...@googlegroups.com
y no pueden comprar un PC que haga de servidor? si no pueden hacer eso, no
creo que paguen bien ah....
Ricardo Pina
Jul 3, 2011, 10:00:07 AM7/3/11
to publice...@googlegroups.com
Hola Alfredo
Simplemente tratando de abrir la bd y capturando el error o un file(ruta+archivoque estaseguro) y ya sabes si el servidor esta en linea
Saludos
Carlos Miguel FARIAS
Jul 3, 2011, 10:38:44 AM7/3/11
to publice...@googlegroups.com
Si la preocupación es que puedan meter datos o modificar datos en una tabla dbf, se puede solucionar utilizando la funcion sys(2017) que te permite hacer un cheksum sobre los registros.
Ese checksum, lo guardas en el mismo registro como una columna mas, y periodicamente (cada una hora, al arrancar el sistema, vos veras) le pegas una recorrida a las tablas, donde el checksum no empareje con los datos, sabes que se metio la mano en el sistema (porque no podran emular el checksum desde afuera).
Si sospechas que puedan tener una aplicación vfp para hacer el ataque, en la tuya, a la función de checksum, agregale una "cadena" tuya que sea interna a la aplicación, entonces, externamente, sin conocer esa cadena, les será practicamente imposible modificar los datos y alterar a la vez el checksum para que no sea detectado el cambio.
Por supuesto, que el encriptado mejora todo.
Indiscutiblemente, usar un SGBD externo, va a dar mejor desempeño y mucho mas seguro que usar nativas (aunque algunas nativas estan para usarse
) La cantidad de datos que circulan mas o menos es la misma, pero como el motor de datos de las dbf estan en el cliente, este necesita acceder a los indices (y esto, por mas que esten optimizado) tienen que circular por la red.
Saludos: Miguel
Ese checksum, lo guardas en el mismo registro como una columna mas, y periodicamente (cada una hora, al arrancar el sistema, vos veras) le pegas una recorrida a las tablas, donde el checksum no empareje con los datos, sabes que se metio la mano en el sistema (porque no podran emular el checksum desde afuera).
Si sospechas que puedan tener una aplicación vfp para hacer el ataque, en la tuya, a la función de checksum, agregale una "cadena" tuya que sea interna a la aplicación, entonces, externamente, sin conocer esa cadena, les será practicamente imposible modificar los datos y alterar a la vez el checksum para que no sea detectado el cambio.
Por supuesto, que el encriptado mejora todo.
Indiscutiblemente, usar un SGBD externo, va a dar mejor desempeño y mucho mas seguro que usar nativas (aunque algunas nativas estan para usarse
) La cantidad de datos que circulan mas o menos es la misma, pero como el motor de datos de las dbf estan en el cliente, este necesita acceder a los indices (y esto, por mas que esten optimizado) tienen que circular por la red.Saludos: Miguel
Marco Plaza
Jul 3, 2011, 1:49:13 PM7/3/11
to Comunidad de Visual Foxpro en Español
Bueno Walter, claro, no pensarás que eso no lo manejo, me refería a
usar tablas DBF con ODBC,
que es lo que le sugieren al usar impersonación, no usando ODBC con
MySql o SQLserver.
Lo que propongo es un objeto para el manejo de datos entre las tablas
de vfp y la aplicación,
no para evitar usar firebird/mysql, sino para poder dejar que el
cliente o las necesidades del producto
permitan escoger que deseas usar simplemente cambiando la cadena de
conexión, que lo puedes lograr como no,
usando odbc para tablas de VFP, pero como expliqué anteriormente,
sigues teniendo que especificar que el origen de los datos es
una carpeta en alguna parte.
Saludos.
On 2 jul, 22:37, "Walter R. Ojeda Valiente" <w...@hotmail.com> wrote:
> Hola Marco
>
> Tienes un error de concepto. Si usas SQL no estás compartiendo alguna carpeta. La comunicación con la Base de Datos se hace a través de un puerto de la PC, no hay carpetas compartidas.
>
> Si la PC es lenta, esa es una razón más para usar SQL, el tráfico de red usando tablas SQL es mucho menor que el tráfico de red usando tablas .DBF. Y al ser el tráfico menor, la velocidad es mayor.
>
> Si usas una Base de Datos SQL no importa el tamaño de tus tablas ni de tus Bases de Datos, tengan el tamaño que tengan siempre el acceso será rapidísimo porque el proceso se hace en el Servidor y al Cliente se envían solamente los datos relevantes.
>
> Es interesante tu proyecto, pero me parece que estás queriendo reinventar la rueda. Si ya tienes algo que funciona muy bien y gratis (el caso de Firebird SQL) ¿por qué molestarte en tratar de emularlo con las tablas .DBF siendo que te llevará muchísimo tiempo hacerlo y probablemente no te salga tan bueno?
>
> Saludos.
>
> Walter.
>
>
>
>
>
>
>
> > Date: Sat, 2 Jul 2011 19:12:43 -0700
> > Subject: [vfp] Re: Se pueden esconder las tablas dbf?
Walter R. Ojeda Valiente
Jul 3, 2011, 2:11:50 PM7/3/11
to publice...@googlegroups.com
Hola Marco.
Tengo muchas cualidades pero adivino aún no soy, no puedo saber lo que manejas y lo que no manejas hasta haber leído (y recordado haber leído) varios e-mails tuyos. Y quizás esté equivocado, pero me parece que muy asiduo colaborador de este grupo no eres.
La idea de tener una clase para administrar las conexiones a varios motores de Bases de Datos no es nueva, inclusive te puedo asegurar que somos muchos quienes hemos desarrollado una clase así. Pero yo particularmente no veo la necesidad de incluir a las tablas .DBF en esa clase. Quizás porque hasta ahora no le encontré la utilidad.
Si voy a desarrollar una aplicación monousuario con tablas .DBF, no la necesito.
Y si voy a desarrollar una aplicación multiusuario, no usaría tablas .DBF, o sea que tampoco la necesito.
De todas maneras, si lo que expones le parece interesante al grupo, sin dudas encontrarás a muchos que te ayudarán con tu idea, yo inclusive.
Saludos.
Walter.
Tengo muchas cualidades pero adivino aún no soy, no puedo saber lo que manejas y lo que no manejas hasta haber leído (y recordado haber leído) varios e-mails tuyos. Y quizás esté equivocado, pero me parece que muy asiduo colaborador de este grupo no eres.
La idea de tener una clase para administrar las conexiones a varios motores de Bases de Datos no es nueva, inclusive te puedo asegurar que somos muchos quienes hemos desarrollado una clase así. Pero yo particularmente no veo la necesidad de incluir a las tablas .DBF en esa clase. Quizás porque hasta ahora no le encontré la utilidad.
Si voy a desarrollar una aplicación monousuario con tablas .DBF, no la necesito.
Y si voy a desarrollar una aplicación multiusuario, no usaría tablas .DBF, o sea que tampoco la necesito.
De todas maneras, si lo que expones le parece interesante al grupo, sin dudas encontrarás a muchos que te ayudarán con tu idea, yo inclusive.
Saludos.
Walter.
> Date: Sun, 3 Jul 2011 10:49:13 -0700
> Subject: [vfp] Re: Se pueden esconder las tablas dbf?
Marco Plaza
Jul 3, 2011, 2:54:55 PM7/3/11
to Comunidad de Visual Foxpro en Español
Tienes razón, para nada, recién llego aquí, pero el caso es ( y por
eso les solicité opinión )
si han tenido experiencias o proyectos similares para seguir usando
dbfs, que es lo que
tratamos de hacer algunos, por ejemplo Carlos Miguel habló acerca de
firmar los registros que es lo mismo
que dije antes pero con otro algoritmo..
Una vez leí en un foro de scripting sobre que a algunos programadores
les gusta hacerlo todo, y decían
a tono de broma que porqué no nos hacemos también la ropa y los
muebles... es verdad hay que usar
lo que ya está hecho y probado.. no inventar la rueda, no perder
tiempo. Pero ahí tienes FoxiPreviewer y FoxCharts
creados en puro VFP.!
Lo que he pensado es usar una dll registrada como servidor com+ para
el manejo de datos entre
las tablas de vfp y la aplicación, pero ojo, no hablo de una clase ni
de lejos un servidor como firebird ,
sino un simple objeto remoto que puedes instanciar usando
createobjectex() que pase y devuelva las transacciones
sql para evitar la exposición de las tablas.
El problema de automatizar el registro del servidor ya lo tengo
resuelto ( sea con Dcom o Com+ ) y bueno, ya veremos como
va.
Saludos.
Marco Plaza
On 3 jul, 14:11, "Walter R. Ojeda Valiente" <w...@hotmail.com> wrote:
> Hola Marco.
>
> Tengo muchas cualidades pero adivino aún no soy, no puedo saber lo que manejas y lo que no manejas hasta haber leído (y recordado haber leído) varios e-mails tuyos. Y quizás esté equivocado, pero me parece que muy asiduo colaborador de este grupo no eres.
>
> La idea de tener una clase para administrar las conexiones a varios motores de Bases de Datos no es nueva, inclusive te puedo asegurar que somos muchos quienes hemos desarrollado una clase así. Pero yo particularmente no veo la necesidad de incluir a las tablas .DBF en esa clase. Quizás porque hasta ahora no le encontré la utilidad.
>
> Si voy a desarrollar una aplicación monousuario con tablas .DBF, no la necesito.
>
> Y si voy a desarrollar una aplicación multiusuario, no usaría tablas .DBF, o sea que tampoco la necesito.
>
> De todas maneras, si lo que expones le parece interesante al grupo, sin dudas encontrarás a muchos que te ayudarán con tu idea, yo inclusive.
>
> Saludos.
>
> Walter.
>
>
>
>
>
>
>
> > Date: Sun, 3 Jul 2011 10:49:13 -0700
> > Subject: [vfp] Re: Se pueden esconder las tablas dbf?
Marco Plaza
Jul 3, 2011, 3:02:10 PM7/3/11
to Comunidad de Visual Foxpro en Español
Gracias por el aporte Carlos, ( aunque no es mi discusión ) veo que ya
has pasado por eso.
y si, es la mejor forma que también encontré de proteger los
registros.
Saludos!
Marco Plaza
On 3 jul, 10:38, Carlos Miguel FARIAS <carlosmiguelfar...@gmail.com>
wrote:
> 32B.gif
> < 1 KBVerDescargar
has pasado por eso.
y si, es la mejor forma que también encontré de proteger los
registros.
Saludos!
Marco Plaza
On 3 jul, 10:38, Carlos Miguel FARIAS <carlosmiguelfar...@gmail.com>
wrote:
> Si la preocupación es que puedan meter datos o modificar datos en una tabla
> dbf, se puede solucionar utilizando la funcion sys(2017) que te permite
> hacer un cheksum sobre los registros.
> Ese checksum, lo guardas en el mismo registro como una columna mas, y
> periodicamente (cada una hora, al arrancar el sistema, vos veras) le pegas
> una recorrida a las tablas, donde el checksum no empareje con los datos,
> sabes que se metio la mano en el sistema (porque no podran emular el
> checksum desde afuera).
> Si sospechas que puedan tener una aplicación vfp para hacer el ataque, en la
> tuya, a la función de checksum, agregale una "cadena" tuya que sea interna a
> la aplicación, entonces, externamente, sin conocer esa cadena, les será
> practicamente imposible modificar los datos y alterar a la vez el checksum
> para que no sea detectado el cambio.
> Por supuesto, que el encriptado mejora todo.
> Indiscutiblemente, usar un SGBD externo, va a dar mejor desempeño y mucho
> mas seguro que usar nativas (aunque algunas nativas estan para usarse [?]) La
> dbf, se puede solucionar utilizando la funcion sys(2017) que te permite
> hacer un cheksum sobre los registros.
> Ese checksum, lo guardas en el mismo registro como una columna mas, y
> periodicamente (cada una hora, al arrancar el sistema, vos veras) le pegas
> una recorrida a las tablas, donde el checksum no empareje con los datos,
> sabes que se metio la mano en el sistema (porque no podran emular el
> checksum desde afuera).
> Si sospechas que puedan tener una aplicación vfp para hacer el ataque, en la
> tuya, a la función de checksum, agregale una "cadena" tuya que sea interna a
> la aplicación, entonces, externamente, sin conocer esa cadena, les será
> practicamente imposible modificar los datos y alterar a la vez el checksum
> para que no sea detectado el cambio.
> Por supuesto, que el encriptado mejora todo.
> Indiscutiblemente, usar un SGBD externo, va a dar mejor desempeño y mucho
> cantidad de datos que circulan mas o menos es la misma, pero como el motor
> de datos de las dbf estan en el cliente, este necesita acceder a los indices
> (y esto, por mas que esten optimizado) tienen que circular por la red.
> Saludos: Miguel
>
> El 2 de julio de 2011 23:37, Walter R. Ojeda Valiente
> <w...@hotmail.com>escribió:
> de datos de las dbf estan en el cliente, este necesita acceder a los indices
> (y esto, por mas que esten optimizado) tienen que circular por la red.
> Saludos: Miguel
>
> El 2 de julio de 2011 23:37, Walter R. Ojeda Valiente
>
>
>
>
>
>
>
> > Hola Marco
>
> > Tienes un error de concepto. Si usas SQL no estás compartiendo alguna
> > carpeta. La comunicación con la Base de Datos se hace a través de un puerto
> > de la PC, no hay carpetas compartidas.
>
> > Si la PC es lenta, esa es una razón más para usar SQL, el tráfico de red
> > usando tablas SQL es mucho menor que el tráfico de red usando tablas .DBF. Y
> > al ser el tráfico menor, la velocidad es mayor.
>
> > Si usas una Base de Datos SQL no importa el tamaño de tus tablas ni de tus
> > Bases de Datos, tengan el tamaño que tengan siempre el acceso será
> > rapidísimo porque el proceso se hace en el Servidor y al Cliente se envían
> > solamente los datos relevantes.
>
> > Es interesante tu proyecto, pero me parece que estás queriendo reinventar
> > la rueda. Si ya tienes algo que funciona muy bien y gratis (el caso de
> > Firebird SQL) ¿por qué molestarte en tratar de emularlo con las tablas .DBF
> > siendo que te llevará muchísimo tiempo hacerlo y probablemente no te salga
> > tan bueno?
>
> > Saludos.
>
> > Walter.
>
> > > Date: Sat, 2 Jul 2011 19:12:43 -0700
>
> > > Subject: [vfp] Re: Se pueden esconder las tablas dbf?
> > > From: stmapw...@gmail.com
>
>
>
>
>
>
> > Hola Marco
>
> > Tienes un error de concepto. Si usas SQL no estás compartiendo alguna
> > carpeta. La comunicación con la Base de Datos se hace a través de un puerto
> > de la PC, no hay carpetas compartidas.
>
> > Si la PC es lenta, esa es una razón más para usar SQL, el tráfico de red
> > usando tablas SQL es mucho menor que el tráfico de red usando tablas .DBF. Y
> > al ser el tráfico menor, la velocidad es mayor.
>
> > Si usas una Base de Datos SQL no importa el tamaño de tus tablas ni de tus
> > Bases de Datos, tengan el tamaño que tengan siempre el acceso será
> > rapidísimo porque el proceso se hace en el Servidor y al Cliente se envían
> > solamente los datos relevantes.
>
> > Es interesante tu proyecto, pero me parece que estás queriendo reinventar
> > la rueda. Si ya tienes algo que funciona muy bien y gratis (el caso de
> > Firebird SQL) ¿por qué molestarte en tratar de emularlo con las tablas .DBF
> > siendo que te llevará muchísimo tiempo hacerlo y probablemente no te salga
> > tan bueno?
>
> > Saludos.
>
> > Walter.
>
> > > Date: Sat, 2 Jul 2011 19:12:43 -0700
>
> > > Subject: [vfp] Re: Se pueden esconder las tablas dbf?
> < 1 KBVerDescargar
Miguel Castillo
Jul 3, 2011, 11:24:32 PM7/3/11
to publice...@googlegroups.com
Daniel acabo de probar tu recomendacion y cambia hasta el tipo de archivo me parece una muy buena y facil opcion y yo creo que los nuevos programadores mientras no queden huellas en el programa de que es foxpro ni se imaginaran que la extencion sea dbf... gracias a ustedes amigos foxeros nadie necesita el soporte de microsof mientras esten todos ustedes nuevamente gracias
saludos
Miguel Castillo
Manta Ecuador
pero vivo en
Santander España
Son unos genios
saludos
Miguel Castillo
Manta Ecuador
pero vivo en
Santander España
Son unos genios
From: daniel_es...@hotmail.com
To: publice...@googlegroups.com
Subject: RE: [vfp] Re: Se pueden esconder las tablas dbf?
Date: Fri, 1 Jul 2011 10:35:21 -0400
la otra solucion que se me ocurre, pero va a dar un poco mas de trabajo de programacion es que encriptes la informacion de las tablas de fforma a que solo la aplicacion las pueda entender y usar cualquiera que abra una tabla no va a poder entender su contenido, pero eso implica que lo encriptes al grabar y lo desencriptes al leer la tabla en la ayuda de vfp hay ejemplos de como encriptar, podes hacer una ffuncion u objeto que se encarge de este trabajo eso va a estar en la aplicacion y va a ser transparente para el usuario, y va a dejar las tablas nolegibles para cualquiera que no sea la aplicacion
espero que sea util.
daniel Estigarribia
Asuncion-Paraguay
Asuncion-Paraguay
> Date: Fri, 1 Jul 2011 07:03:18 -0700
> Subject: [vfp] Re: Se pueden esconder las tablas dbf?
HernanCano
Jul 4, 2011, 3:13:04 AM7/4/11
to Comunidad de Visual Foxpro en Español
Gracias, Edgar.
Me gustó mucho tu aporte.
Son precisamente las medidas que todo programador FoxPro (y no FoxPro)
debe implementar.
Jorge Montúfar
Jul 5, 2011, 4:57:10 PM7/5/11
to publice...@googlegroups.com
Buenas tardes amigos foxeros, yo trabaje con tablas con extension ovl en fox 6 y por lo menos no se pueden abrir con un use.
Edgar Acevedo
Jul 5, 2011, 5:03:44 PM7/5/11
to publice...@googlegroups.com
Suena muy interesante Jorge. Entonces como las abrías ? Las renombrabaras para abrirlas o había otro método para hacerlo ?
extremo
Jul 5, 2011, 5:03:52 PM7/5/11
to Comunidad de Visual Foxpro en Español
Yo jorge uso todas mis dbf con extension dll y hasta ahora ha
funcionado muy bien
Bendiciones
On 5 jul, 16:57, Jorge Montúfar <jma...@gmail.com> wrote:
> Buenas tardes amigos foxeros, yo trabaje con tablas con extension ovl en fox
> 6 y por lo menos no se pueden abrir con un use.
>
>
> - Mostrar texto de la cita -
funcionado muy bien
Bendiciones
On 5 jul, 16:57, Jorge Montúfar <jma...@gmail.com> wrote:
> Buenas tardes amigos foxeros, yo trabaje con tablas con extension ovl en fox
> 6 y por lo menos no se pueden abrir con un use.
>
> El 4 de julio de 2011 01:13, HernanCano <jhernanca...@gmail.com> escribió:
>
>
>
>
>
> > Gracias, Edgar.
>
> > Me gustó mucho tu aporte.
>
> > Son precisamente las medidas que todo programador FoxPro (y no FoxPro)
> > debe implementar.- Ocultar texto de la cita -
>
>
>
>
>
> > Gracias, Edgar.
>
> > Me gustó mucho tu aporte.
>
> > Son precisamente las medidas que todo programador FoxPro (y no FoxPro)
>
> - Mostrar texto de la cita -
Jorge Montúfar
Jul 5, 2011, 5:13:04 PM7/5/11
to publice...@googlegroups.com
jajaja con use jorge.ovl
extremo
Jul 5, 2011, 5:17:40 PM7/5/11
to Comunidad de Visual Foxpro en Español
no entendi
Bendiciones
> > > - Mostrar texto de la cita -- Ocultar texto de la cita -
Bendiciones
Jorge Montúfar
Jul 5, 2011, 5:21:07 PM7/5/11
to publice...@googlegroups.com
Tengo una clase para crearlas y al ser creadas las podes abrir mitabla.ovl index cosa
esto esta en fox 6, o sea que no es nada del otro mundo solo que al tener un exe y las tablas.ovl no saben por lo regular en que estan hechas
esto esta en fox 6, o sea que no es nada del otro mundo solo que al tener un exe y las tablas.ovl no saben por lo regular en que estan hechas
extremo
Jul 5, 2011, 5:26:25 PM7/5/11
to Comunidad de Visual Foxpro en Español
haaa ahora entendi Jorge
Lo que pasa es que en vfp7 en adelante puedes cambiar la extencion de
los archivos ejemplo de DBF a DLL y abrrirlos tal cual lo haces
ejemplo
use tabla.dll in 0
Y el vfp lo abre sin problemas, no necesitas hacer nada extra.
entre parentesis, no sabia que el 6 daba ese tipo de problemas para
leer una dbf con otra extension. Mi fuerte si es trabajar vfp con
SqlServer.
Bendiciones
On 5 jul, 17:21, Jorge Montúfar <jma...@gmail.com> wrote:
> Tengo una clase para crearlas y al ser creadas las podes abrir mitabla.ovl
> index cosa
> esto esta en fox 6, o sea que no es nada del otro mundo solo que al tener un
> exe y las tablas.ovl no saben por lo regular en que estan hechas
>
Lo que pasa es que en vfp7 en adelante puedes cambiar la extencion de
los archivos ejemplo de DBF a DLL y abrrirlos tal cual lo haces
ejemplo
use tabla.dll in 0
Y el vfp lo abre sin problemas, no necesitas hacer nada extra.
entre parentesis, no sabia que el 6 daba ese tipo de problemas para
leer una dbf con otra extension. Mi fuerte si es trabajar vfp con
SqlServer.
Bendiciones
On 5 jul, 17:21, Jorge Montúfar <jma...@gmail.com> wrote:
> Tengo una clase para crearlas y al ser creadas las podes abrir mitabla.ovl
> index cosa
> esto esta en fox 6, o sea que no es nada del otro mundo solo que al tener un
> exe y las tablas.ovl no saben por lo regular en que estan hechas
>
Jorge Montúfar
Jul 5, 2011, 5:29:19 PM7/5/11
to publice...@googlegroups.com
Gracias por las bendiciones, pues yo empezando estoy con mysql y fox, tambien estoy investigando los web services y otra cosa que me encontre que para mi es buena, que es correr una aplicacion en internet.
Bendiciones para vos tambien, saludos cordiales
Bendiciones para vos tambien, saludos cordiales
extremo
Jul 5, 2011, 5:50:18 PM7/5/11
to Comunidad de Visual Foxpro en Español
Jorgue, aca en la empresas estamos trabajando en lo mismo, nuestro
gran desafio es llevar la aplicacion vfp a la web sin necesidad de
instalar nada en el pc del cliente. Estamos recien comenzando con este
proyecto, nuestra primera etapa es hacer correr una aplicacion
sencilla en una palm luego en mac y linux. Cuando logremos algo
concreto ten por seguro que lo enviare al foro.
Bendiciones
On 5 jul, 17:29, Jorge Montúfar <jma...@gmail.com> wrote:
> Gracias por las bendiciones, pues yo empezando estoy con mysql y fox,
> tambien estoy investigando los web services y otra cosa que me encontre que
> para mi es buena, que es correr una aplicacion en internet.
>
> Bendiciones para vos tambien, saludos cordiales
>
gran desafio es llevar la aplicacion vfp a la web sin necesidad de
instalar nada en el pc del cliente. Estamos recien comenzando con este
proyecto, nuestra primera etapa es hacer correr una aplicacion
sencilla en una palm luego en mac y linux. Cuando logremos algo
concreto ten por seguro que lo enviare al foro.
Bendiciones
On 5 jul, 17:29, Jorge Montúfar <jma...@gmail.com> wrote:
> Gracias por las bendiciones, pues yo empezando estoy con mysql y fox,
> tambien estoy investigando los web services y otra cosa que me encontre que
> para mi es buena, que es correr una aplicacion en internet.
>
> Bendiciones para vos tambien, saludos cordiales
>
Miguel Canchas
Jul 5, 2011, 5:52:04 PM7/5/11
to publice...@googlegroups.com
Suena interesante... estare esperando...no se si sentado o parado ...:)
MK
-----Mensaje original-----
De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de extremo
Enviado el: martes, 05 de julio de 2011 04:50 p.m.
Para: Comunidad de Visual Foxpro en Español
Asunto: [vfp] Re: Se pueden esconder las tablas dbf?
HernanCano
Jul 5, 2011, 8:54:03 PM7/5/11
to Comunidad de Visual Foxpro en Español
Edgar: ¿no lees las ayudas? ¿o saber programar?
Para abrir un archivo de datos (en formato .DBF) que no tiene
extensión .DBF, si no otra, se usa el comando USE así:
use MAESTRO.OVL in 0 shared
use CREDITOS.CRE in 0 shared
use PAGOS.DAT in 0 shared
select PAGOS
copy to TEMPORAL for CODIGO=M.Cod
use TEMPORAL exclusive
...
..
etc
On 5 jul, 16:03, Edgar Acevedo <aperso...@gmail.com> wrote:
> *Suena muy interesante Jorge. Entonces como las abrías ? Las renombrabaras
> para abrirlas o había otro método para hacerlo ?*
Para abrir un archivo de datos (en formato .DBF) que no tiene
extensión .DBF, si no otra, se usa el comando USE así:
use MAESTRO.OVL in 0 shared
use CREDITOS.CRE in 0 shared
use PAGOS.DAT in 0 shared
select PAGOS
copy to TEMPORAL for CODIGO=M.Cod
use TEMPORAL exclusive
...
..
etc
On 5 jul, 16:03, Edgar Acevedo <aperso...@gmail.com> wrote:
> *Suena muy interesante Jorge. Entonces como las abrías ? Las renombrabaras
> para abrirlas o había otro método para hacerlo ?*
HernanCano
Jul 5, 2011, 8:55:30 PM7/5/11
to Comunidad de Visual Foxpro en Español
Igual con cualquier otra extensión "reconocida" por FoxPro (o DBase o
Clipper, o...)
Clipper, o...)
Jorge Montúfar
Jul 7, 2011, 6:31:25 PM7/7/11
to publice...@googlegroups.com
Extremo, te lo voy agradecer mucho cuando envies lo de la palm y publicar eso, te comento he leido un poco sobre west wind y se puede realizar o hacer que desde internet lea tu aplicacion, solo es de tener unas librerias y programar un poquito segun dice ahi, creo con esto se podría hacer que desde la palm si esta tiene conexion a internet se pueda ejecutar la aplicacion hecha en vfp.
Gracias y si puedo servirte en algo estoy a tus ordenes
Jorge Montufar
Saludos cordiales
Gracias y si puedo servirte en algo estoy a tus ordenes
Jorge Montufar
Saludos cordiales
Marcelo Villafañes
May 27, 2015, 6:54:21 PM5/27/15
to publice...@googlegroups.com, mike7...@hotmail.com
VEAMOS....
He desarrollado un método para lograr solucionar el tema de la seguridad sobre las bases de datos DBF
a partir de la "IMPERSONALIZACIÓN " , con el que es IMPOSIBLE que nadie que NO DEBA pueda tocar,
modificar, ver, inclusive navegar en el directorio donde residen las tablas o las bases de datos....
veamos como es eso:
1.- Las bases de datos DEBEN ubicarse en un SERVIDOR WINDOWS SERVER XX, en una carpeta
UNICAMENTE compartida para el administrador del sistema (para que ustedes la puedan ver o modificar, etc)
y PARA UN USUARIO EXCLUSIVO PARA ACCEDER AL SISTEMA.
2,. se debe crear ESTE USUARIO, TANTO EN EL SERVIDOR como en LOS TERMINALES que van a acceder a la
las tablas en la base de datos UN USUARIO que SOLO se va a utilizar para que los sistemas
accedan a las tablas. (por supuesto NADIE debe conocer la clave de acceso al mismo ...
3,. NO se debe crear NINGUNA conexión de red en los TERMINALES para acceder a esta carpeta
De esta forma, la carpeta donde residen las bases de datos en el servidor, NO SERÁ visible a
NINGUN usuario, y por lo tanto no las pueden tocar, eliminar, modificar, etc.
4 .-AHORA -- COMO ACCEDEMOS A LAS BASES DESDE EL SISTEMA SI "NO SE LAS PUEDEN VER" ?????
Justamente ... creando DESDE ADENTRO DE LA APLICACIÓN UNA CONEXION DE RED "IMPERSONALIZADA"
Es la misma aplicación la que va a crear SU acceso para poder acceder a las tablas.
veamos como es eso, les paso un sencillo programa para esto:
vamos a utilizar las api de Windows.
(este programita se debe correr antes de hacer nada...)
==========================================================================
** Impersonalización de acceso a la red
** Declara las funciones de la api que utilizara.
declare integer LogonUser in Win32API string userName, string domain, string passwd, integer logonType, integer logonProv, integer @handle
declare integer CloseHandle in Win32API integer handle
declare integer ImpersonateLoggedOnUser in Win32API integer handle
declare integer RevertToSelf in Win32API
declare integer ImpersonateLoggedOnUser in Win32API integer handle
declare integer RevertToSelf in Win32API
** Efectua el login al usuario. Si falla es porque el usuario o el dominio no
** existen o porque la password no corresponde.
** En LogonUser:
** logonType = 3 (LOGON32_LOGON_NETWORK)
** logonProv = 0 (LOGON32_PROVIDER_DEFAULT)
PUBLIC logHandle
logHandle = 0
res = LogonUser("nombre_usuario_exclusivo", "nombre_servidor", "clave_del_usuario", 2, 0, @logHandle)
** Validamos si se conectó al servidor
if res = 0
MESSAGEBOX("Error conectando a la red..." ,32,"Acceso al sistema...",5000)
RETURN 0
endif
MESSAGEBOX("Error conectando a la red..." ,32,"Acceso al sistema...",5000)
RETURN 0
endif
** Impersonaliza el usuario actual
res = ImpersonateLoggedOnUser(logHandle)
res = ImpersonateLoggedOnUser(logHandle)
if res = 0
MESSAGEBOX("Fallo de login del usuario ...",32,"Acceso al sistema...",5000)
RETURN 0
endif
MESSAGEBOX("Fallo de login del usuario ...",32,"Acceso al sistema...",5000)
RETURN 0
endif
on error err_ = .t.
err_ = .f.
if !err_
err_ = .f.
if !err_
*(descomentar la siguiente línea si se quiere ver un mensaje de conexión...)
* wait window (msg + ": Se conecto OK !!")
else
wait window ("Error conectando a la red: " + msg + ": Error '" + message() + "'...")
endif
on error
** Si retorna 1, es porque se conectó al servidor...
RETURN 1
================================================================
ahora... estamos conectado al servidor ... y si vamos a MI PC podremos observar
que NO EXISTE en forma visible, una conexión con el servidor y sin embargo
vamos a poder abrir las bases de datos.
COMO USAMOS AHORA UNA BASE DE DATOS ... ??
La impersonalización hace, que la conexión "NO TENGA LETRA" ....por eso
es que no se ve ni en mi pc ni en ningún lado .... crea un "hilo" único de acceso
SOLO PARA ESE TERMINAL cuando se sale del sistema "SE CAE EL HILO"
entonces... para poder usar una tabla por ej .... le daremos :
y ... listo.....
ESPERO LES SIRVA...
CUALQUIER DUDA ... NO DUDEN EN PREGUNTAR
Marcelo
Arnaldo Toledano
May 27, 2015, 7:33:34 PM5/27/15
to publice...@googlegroups.com, arnaldo....@gmail.com
Supongo que abras utilizado el Código, pero dos dudas.
1.- Para logearte,
1.- Para logearte,
LogonUser("nombre_usuario_exclusivo", "nombre_servidor",
"clave_del_usuario", 2, 0, @logHandle)
No tenes que DESLOGEARTE del primer usuario primero ?.
2.- Que pasa si una vez abierto el Sistema, lo minimizo y hago click en el ICONO de RED, en Windows Seven ?
2.1.- Seguro me aparece el Server
Si hago click en el icono SERVER
2.2.- Me aparece la carpeta compartida donde se encuentran las DBF.
Arnaldo Toledano
2.- Que pasa si una vez abierto el Sistema, lo minimizo y hago click en el ICONO de RED, en Windows Seven ?
2.1.- Seguro me aparece el Server
Si hago click en el icono SERVER
2.2.- Me aparece la carpeta compartida donde se encuentran las DBF.
Arnaldo Toledano
El 27/05/2015 a las 07:54 p.m., Marcelo
Villafañes escibió:
--
Arnaldo Toledano Tesys Informática Córdoba Argentina
Arnaldo Toledano Tesys Informática Córdoba Argentina
Antonio Meza
May 27, 2015, 8:14:11 PM5/27/15
to publice...@googlegroups.com, arnaldo....@gmail.com, arnaldo....@gmail.com
Muy facil, cuando compartes la carpeta en windows server solo tienes que ocultarla poniendo el $ ejemplo
base$
De esta forma al teclear \\server no mostrara las carpetas compartidas.
y quedaría así:
saludos
wpalomo
May 28, 2015, 12:29:23 AM5/28/15
to publice...@googlegroups.com, solv...@gmail.com, arnaldo....@gmail.com
Saludos
Efectivamente, el método de Antonio Mesa es el mas fácil y efectivo para ocultar una carpeta compartida. Inclusive se puede localizar el servidor en el entorno de red , pero no se podra observar las carpetas compartidas que terminen con el simbolo $, este truco viene desde la época del D.O.S.
La ruta de la carpeta compartida por facilidad y seguridad se debe colocar en un archivo.ini, además se debe encriptar la cadena que indica la ruta.
Algo así:
[SERVIDOR]
URL=#*!±±) |¦)ɼ¦|J¦)E¼±¤²¤0¨Ïë±
DAT=(!§ç<#<»íÖt
ANX=ÖtíÖ&ËíJJJ)
[REGISTRO]
EMPRESA=ɼ¥t<(¯#\íËte»tÖtâ(
LICENCIA=)E<íË—#§(Ë
Est0=±±|JÉa)|E|¼J
USE url+dat+ARCHIVO.DBF
Ejemplo:
URL = \\server\ && Nombre servidor (Puede ser la IP)
DAT = datos\ && Carpeta compartida
Algo parecido se puede hacer en linux, utilizando SAMBA Server.
En este caso al crear el recurso compartido, se debe indicar que la carpeta tenga el atributo de NO VISIBLE.
Suerte......
Antonio Meza
May 28, 2015, 11:47:37 AM5/28/15
to publice...@googlegroups.com, toshiba....@gmail.com, arnaldo....@gmail.com, solv...@gmail.com
Y me falto comentar que incluso para cualquier versión de windows funciona no solo para windows server y no hay que llenar de tanto código!!
saludos
Antonio Meza
HernanCano
May 29, 2015, 2:25:45 AM5/29/15
to publice...@googlegroups.com, ad...@targes.com.ar, mike7...@hotmail.com
Hola, Marcelo.
Me complace que mi comentario te haya ayudado a entender el concepto. Así mismo, gracias por compartir.
HernanCano
May 29, 2015, 2:29:35 AM5/29/15
to publice...@googlegroups.com, arnaldo....@gmail.com, arnaldo....@gmail.com
Amigo tesys:
>>> 1.- Para logearte, con LogonUser(...) no tenes que DESLOGEARTE del primer usuario primero ?
Considero que ya que haces la segunda parte de tu comentario, ya ejecutaste el script propuesto por Marcelo, y entonces ta diste cuenta de que la reespùesta a esta primera pregunta es no.
>>> 2. ...
Ya te respondieron.
El miércoles, 27 de mayo de 2015, 18:33:34 (UTC-5), tesys escribió:
Hector Colman
May 29, 2015, 7:30:35 AM5/29/15
to publice...@googlegroups.com, mike7...@hotmail.com
Si se puede hacer e el ejecutable. como hacen no se... aca en Paraguay la Junta Electoral FoxPro. y miren el ejecutable
tengo el programa completo voy a comparte en MEGA y haber si alguien conoce
integral
May 29, 2015, 4:58:03 PM5/29/15
to publice...@googlegroups.com, mike7...@hotmail.com
Que tal Amigos .
Referente al tema en controversia, desde mi punto de vista me parece muy bien la idea del colega EdgaRGT y también el código que expone sobre el numero del IP fijo.
En base a mi experiencia de cuando programaba en Foxpro 2.6 para D.O.S. Aprendi una tecnica muy simple que lo menciono el amigo Extremo.
La técnica consistía en cambiarle la extensión a las tablas
Ejm. USE Costos.mcd
Asi de simple
Hasta la próxima.
INTEGRAL
Jean Pierre Adonis De La Cruz Garcia
May 29, 2015, 5:07:17 PM5/29/15
to publice...@googlegroups.com, mike7...@hotmail.com
Bueno, te puedo dar una tecnica que usaba hace tiempo para confundir a los piratas, creaba un archivo de 1mb y le ponia la extension MDB que parecia access. luego mi base de datos que se podia ver, la encriptaba dentro de una Zipe, luego le cambiaba la cabecera como DLL, lo renombraba, y eso era todo, solo la tabla me funcionaba cuando dentro de mi modulo, le decia que desencripte y que me ejecute en una carpeta oculta, y nadies se daba cuenta.
Asi protegia algunos sitemas que querian piratearme.
Reply all
Reply to author
Forward
0 new messages