Bases de datos shareware (2)

Deja un comentario

En este artículo ya habíamos visto las ventajas de tener una Base de Datos shareware, las dos formas usuales de hacerla, y los trucos que los usuarios tramposos podrían intentar:

https://firebird21.wordpress.com/2014/01/23/bases-de-datos-shareware/

Ahora explicaremos mejor el funcionamiento de esas dos formas.

Protección por fecha

Se le permite al usuario usar la aplicación hasta que llegue una cierta fecha, después ya no podrá usarla. Por ejemplo si instaló la aplicación el 24 de enero de 2014 podrá usarla hasta el 24 de febrero de 2014. Si quiere usarla después, entonces tendrá que pagar.

Aquí lo que debemos impedir es que si le cambia la fecha a la computadora la aplicación siga funcionando. Por ejemplo, el día 25 de febrero el usuario no puede usar la aplicación, le cambia la fecha a su computadora y le coloca 1 de febrero de 2014. A pesar de haber cambiado la fecha no debería poder usar la aplicación. Debemos detectar ese cambio y actuar en consecuencia.

¿Cómo protegemos por fecha?

Guardamos en una tabla de nuestra Base de Datos o en un archivo externo a ella, tres valores: la fecha inicial, la fecha final, y la fecha última.

La fecha inicial es el primer día que puede usar la aplicación. Por ejemplo el 24 de enero de 2014

La fecha final es el último día que puede usar la aplicación. Por ejemplo el 24 de febrero de 2014

La fecha última, cuando se instala la aplicación es igual a la fecha inicial. Después, cada vez que se ejecuta la aplicación se verifica si la fecha del Servidor es igual o posterior a la fecha última. Si es así, se actualiza la fecha última.

Entonces, si el 25 de febrero el usuario ejecuta la aplicación el valor de fecha última será 25 de febrero. Si le cambia la fecha a su computadora y le pone 1 de febrero, fecha última seguirá siendo 25 de febrero, porque el valor de fecha última jamás puede retroceder. El nuevo valor de fecha última solamente puede ser igual o posterior al valor anterior de fecha última.

En nuestra rutina de validación verificamos:

  1. Que la fecha de la computadora sea mayor o igual que fecha inicial y que también sea menor o igual a fecha final
  2. Que la fecha última sea mayor o igual que fecha inicial y que también sea menor o igual a fecha final

Podemos mejorar el algoritmo si en vez de guardar solamente la fecha guardamos la fecha y la hora. Inclusive lo mejoraríamos aún más si nos aseguramos que cada vez que se ejecuta la aplicación el tiempo aumente por lo menos en 5 minutos.

Primera ejecución del sistema: 24 de enero de 2014, 16:12

Segunda ejecución del sistema, como mínimo debería ser el 24 de enero de 2014 a las 16:17, ó sea 5 minutos después que la ejecución anterior. Fíjate que no importa cuando el usuario realmente ejecutó la aplicación, lo que nos aseguramos es que siempre haya un incremento de por lo menos 5 minutos. Si la segunda ejecución fue el 24 de enero a las 16:50, en fecha última tendremos guardado 24 de enero y 16:50, pero si la segunda ejecución fue el 24 de enero a las 16:13 en fecha última tendremos guardado 24 de enero y 16:17 porque siempre incrementamos como mínimo 5 minutos.

Por supuesto que no es obligatorio sumarle 5 minutos, podrías sumarle 10 minutos, 30 minutos, 60 minutos, los que te parezcan. La idea es que siempre que se ejecuta la aplicación la fecha y hora se incrementen, que jamás puedan mantenerse igual o retroceder.

De esta manera, tarde o temprano, haga el usuario lo que haga, se sobrepasará la fecha última y la aplicación dejará de funcionar.

Protección por cantidad de ejecuciones

Esto es mucho más fácil de programar que la protección por fechas. Simplemente guardamos en una tabla de nuestra Base de Datos o en un archivo externo la cantidad de veces que el usuario ejecutó nuestra aplicación. Cada vez que la ejecuta incrementamos esa cantidad en 1.

Cuando instala la aplicación, el contador es 0. La primera vez que la ejecuta, el contador es 1. La segunda vez el contador es 2. Y así sucesivamente. Cuando se llegue a la cantidad predeterminada (por ejemplo: 25), la aplicación dejará de funcionar.

Usando ambas protecciones

Para que nuestra aplicación esté más protegida lo mejor es protegerla con ambos métodos: fecha y cantidad.

Siguiendo con nuestro ejemplo, la aplicación dejará de funcionar el 25 de febrero de 2014 ó cuando haya sido ejecutada 25 veces, lo que ocurra primero.

Encriptando los valores

Evidentemente ninguna protección será efectiva si el usuario puede ver y cambiar las fechas o las cantidades de ejecución. Esos valores deben encontrarse encriptados (es decir, ilegibles para quienes no conozcan la clave) y cuanto más ocultos, mejor.

Un lugar donde tradicionalmente se guardan esos valores es en el Registro del Windows. Muy pocos usuarios conocen el Registro del Windows, menos aún han entrado a curiosearlo y muchos menos aún se atreven a cambiar algo por su propia cuenta.

Otro lugar es en la propia Base de Datos. Si tienes una tabla de un solo registro donde guardas la configuración o algo similar entonces puedes aprovechar y agregarle una columna a esa tabla. En esa nueva columna guardas (convenientemente encriptadas, por supuesto) la fecha inicial, la fecha final, la fecha última y la cantidad de ejecuciones.

Recuperando los valores

Así como has guardado las fechas y la cantidad de ejecuciones encriptadas, debes poder desencriptarlas para realizar las verificaciones y determinar si la aplicación puede seguir usándose o no.

Esto puedes realizarlo en dos lugares:

  1. En tu aplicación. Es decir en el programa que escribiste con Visual FoxPro, Visual Basic, C, C++, Delphi, Java, etc.
  2. En un trigger de tu Base de Datos. El usuario debe tener solamente la versión compilada de ese trigger, no debe tener el código fuente o de nada te servirán las protecciones.

Lo ideal y lo correcto por lo tanto es que verifiques que tu aplicación puede ejecutarse, en ambos lugares: en tu aplicación y en un trigger. De esa manera aunque el usuario llegara a descubrir y evitar la protección que se encuentra en un lugar aún le faltaría descubrir y evitar la protección que se encuentra en el otro. Y si debe trabajar más para conseguirlo es más probable que desista de su intención. Y entonces la protección habrá cumplido su misión.

En el siguiente artículo ya veremos como implementar lo expuesto hasta acá.

Artículos relacionados:

Bases de datos shareware

El índice del blog Firebird21

Proteger a las Bases de Datos visibles en Internet

9 comentarios

En ocasiones necesitas que tu Base de Datos pueda ser accedida desde Internet, generalmente a los usuarios les gusta tener esa opción: poder conectarse usando su notebook, su tableta, su teléfono celular o estando en un cybercafé es muy atractivo a simple vista.

Sin embargo como profesional informático debes saber que cualquier Base de Datos que no esté lo suficientemente protegida está en grave riesgo y puede ser atacada por los hackers. Una IP pública sin protección es una invitación para que cualquier malhechor intente el acceso.

cyberattack

Dos computadoras que se encuentran en Internet generalmente no tienen un comunicación directa entre ellas sino que la comunicación va pasando de servidor a servidor hasta llegar a su destino. A esas computadoras intermedias se las llama “nodos” y en algunos casos podría haber decenas de nodos entre ambas. Como se ve en el gráfico superior, para ir desde “A” hasta “B” se requiere pasar por varios nodos. ¿Y cuál es el problema? que cualquiera de esos nodos puede interceptar los datos que pasan por él y enterarse de todo.

Los hackers utilizan programas que les permiten revisar en cuestión de minutos todas las IP que se encuentran en un rango. Por ejemplo, podrían buscar todas las IP públicas que se encuentren activas entre 200.120.60.0 y 200.120.90.255 y eso solamente les tomará unos cuantos minutos. Anotan los números de las que están activas e intentan realizar la conexión. Para eso también tienen programas que les facilitan la tarea.

Y si la IP donde se encuentra tu Base de Datos está dentro del rango en el cual algún hacker está buscando, estás corriendo un riesgo gravísimo. Y no te olvides que en el mundo hay cientos de miles de hackers y muchísimos de ellos están “trabajando” en este mismo momento.

Para que tu conexión sea segura y sin riesgos (o con un riesgo pequeñisimo) lo que necesitas es un túnel privado de conexión.

¿Qué es un túnel privado?

Es una comunicación que se realiza entre dos computadoras. La computadora que envía los datos los encripta y los comprime, la computadora que recibe los datos los descomprime y los desencripta.

VPN

Esto se realiza a través de una VPN (Virtual Private Network) o red privada virtual. Se le dice virtual porque usa la misma conexión de Internet, no una conexión propia con cables propios sino un programa que se encarga de realizar la tarea. Y se le dice privada porque solamente quienes conozcan las contraseñas podrán conectarse a esta red y la información siempre viajará encriptada, por lo cual aunque sea interceptada no hay riesgo de que sea fácilmente leída.

Dos programas que se usan mucho para crear y usar los túneles son ZebeDee y OpenVPN, cuyos enlaces son:

http://www.winton.org.uk/zebedee/

http://openvpn.net/

Como los datos viajan encriptados:

  • el riesgo de ser leídos por personas no autorizadas disminuye muchísimo
  • el viaje es más rápido porque la cantidad de datos que viajan es menor

Conclusión:

Si tu Base de Datos será accedida desde Internet debes protegerla con una VPN (red privada virtual) o de lo contrario estará muy expuesta a ser atacada por los hackers. Y aunque tú creas que no hay en ella nada importante los hackers podrían destruirla y corromperla o llenarla de basura con todos los perjuicios que dichas acciones causarían (podrían hacer eso sólo por maldad, porque quieren y pueden hacerlo). Usando una VPN obtendrás dos beneficios: que el riesgo de ser atacada disminuya muchísimo y que las velocidades de las operaciones aumenten mucho.

La gran mayoría de los hackers desiste de atacar las computadoras o bases de datos que están muy protegidas, salvo que crean que obtener éxito les resultará de mucho provecho. Por lo tanto, cuanto más protejas a tus bases de datos, mucho mejor.

Artículos relacionados:

Usando Zebedee con Firebird

Usando Zebedee con Firebird. Parte 2

El índice del blog Firebird21