Power Builder - Seguridad de Sistema

 
Vista:

Seguridad de Sistema

Publicado por eduardo.v (208 intervenciones) el 08/02/2003 06:37:59
Quiza ya hayan leido una consulta parecida a est a y si la han leido era seguramente una consulta mia. Bueno el problema es este:
Tengo un sistema de gestion desarrollado en power 8.0 con base de datos SQL. tengo tambien varios clientes a los cuales he logrado vender mi sistema y algunos cuantos a los que estoy proximo a venderselo. Mi preocupacion es que si hay alguna forma de proteger mi sistema de una eventual copia ilegal (pirateria) o colocar un tiempo de uso para asegurame con el cumplimiento puntual de los pagos. Con algunos clientes no tengo ese temor porque son pequeños y su conocimiento de informatica es escasa (tanto es asi que me llaman para instalar un office o algo parecido) pero con algunos otros si, puesto que cuentan con personal de informatica capacitado. e buscado varias soluciones pero aun no encuentro la ideal. Podemos repasar las soluciones que he barajado o que me han dado:
- contraseña a la base de datos o guardar en una tabla de la db una contraseña o rango de fechas de uso. no es factible porque yo no vendo el sql y ellos tienen acceso a todas las bases de datos sin restriccion.
-Guardar la contraseña o rango de fechas en el registro de windows. tambien es obvio que la encontrarian ademas de ser un poco engorroso para mi actualizar cada windows en cada maquina estamos hablando de algunos casos de hasta 16 pc por empresa.
-Guardar la contraseña o rango en una dll. esta puede ser pero se que tambien hay sofware para abrir dll's como los utilitarios de visual.
-Guardar la contraseña o rango en un .ini, .txt ect pero volvemos al problema del segundo caso.
(continua...)
Valora esta pregunta
Me gusta: Está pregunta es útil y esta claraNo me gusta: Está pregunta no esta clara o no es útil
0
Responder

Seguridad de Sistema (continua)

Publicado por eduardo.v (208 intervenciones) el 08/02/2003 06:54:36
(...viene)
En todos los casos la idea es guardar un rango de fechas con una contraseña. es decir: Empresa1 rango:01/01/2003 al 31/01/2003 con contraseña xxx y un campo numerico (1/0) para q introduscan la contraseña una sola vez. hasta el siguiente rango. estos rangos yo deberia definirlos al momento de la instalacion del sistema y solamente les proporcionaria la contraseña (por mail) para que avancen al siguiente rango. estoy seguro que esto protegeria mi sistema (y mi bolsillo) pero no se donde guardar estos datos. Ya he sufrido anteriormente un problema asi, con el clipper hice un sistema lo vendi y a los 2 años al visitar una empresa me di con la sorpresa que ya tenian mi sistema instalado. O si no he tenido desencuentros con algunos clientes por el retraso en los pagos (y en algunos casos con el olvido) como comprenderan ya no quiero que me pase eso ahora que estoy en power. asi que si alguien conoce alguna forma de proteger un sistema le agradeceria enormemente que lo compartiera conmigo.
Gracias y saludos desde Peru
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

RE:Seguridad de Sistema (continua)

Publicado por Manuel Ruiz (33 intervenciones) el 08/02/2003 12:41:47
Hola, mira por que no guardas la contraseña o rango en una dll o en un ini, pero todos estos datos encriptados, podrias utilizar un algoritmo de encriptacion propio o uno hecho por otro como por ejemplo el CAPICOM que es de Microsoft, es un algoritmo que es gratis, viene en una dll que podrias utilizar.
En fin, es solo una idea.
Saludos de Lima-Perú.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

los DLLs son la mejor solucion

Publicado por milson cardona (613 intervenciones) el 08/02/2003 17:20:55
Un saludo especial desde COLOMBIA

antes de darte mi punto de vista, te quiero comentar que a mi parecer, considero que no hay ningún sistema infalible ante la piratería, de existir Microsoft o sybase o cualquiera otra de las grandes empresas ya lo hubiera implementado, y como vez cuando uno desee puede copiar un sistema operativo sin ningun problema.


lo que si existen son herramientas seguras, que unidas a un buen programador tal vez puedan disminuir en parte el rpoblema...
a mi parecer, de todas las soluciones que te hemos dado, me parece que la de los DLLs es la mejor, y si puedes encriptar su contenido mucho mejor....

es la mejor solución, porque tu solo distribuyes el ejecutable, y no el código fuente, y de esta manera será muy dificil que un ingeniero por experto que este sea, conozca todas las DLLs del sistema operativo y que al buscar detecte la que instales y sepa que a travez de ella puede vulnerar la apliacción...... claro lógicamente NO la puedes llamar con un nombre muy expresivo como por ejemplo 'contraseñas_mi_sistema' ....

Espero que mi humilde opinion sirva de algo.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

RE:los DLLs son la mejor solucion

Publicado por eduardo.v (208 intervenciones) el 08/02/2003 18:24:44
Gracias a Manuel y Milson por sus respuestas.
Yo tambien pense en algun momento que lo de las dll era la solucion pero al implementarlo me di cuenta de que era poco pratica (en mi caso) porque como explique en el primer post tengo clientes que llegan a tener hasta 16 maquinas en red que tienen instalado en cada una de ellas el sistema. ademas de la forma que quiero hacerlo (ver post 2) necesitaria actualizar un dato (cambiarlo de 0 a 1) para activar el siguiente rango porque la idea es que la contraseña se ingrese solo una vez por rango y las dll (que yo sepa) no se pueden actualizar, son estaticas. ademas si registro los rangos y contraseñas en un dll cada cliente tendria que digiatr la contraseña cada vez que entren al sistema. la idea es que se ingrese la contraseña solo una vez por el operador principal o administrador del sistema sin que los clientes tengan conocimiento alguno. entonces de ahi deduzco que la jugada se debe hacer solo en el servidor, entonces con esta premisa nace la idea de colocar los rangos en la base de datos pero como explique anteriormente ellos tienen acceso total a la base de datos. Quiza sea muy perfeccionista o para algunos hasta paranoico pero no puedo evitarlo ya me paso una vez y no quisiera que me pase nuevamente asi que recurro a ustedes para dilucidar una solucion efectiva.
Gracias y saludos desde Lima-Peru
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Métodos para proteger software

Publicado por Oscar (1178 intervenciones) el 09/02/2003 04:02:12
Referente a los diferentes métodos de seguridad para proteger un software, existen varios. De menos seguro a más seguro, según mi opinión podrían ser:

Password:
Existe el riesgo de que desensamblen tu ejecutable y romper de esa manera la protección. O la contraseña de tu software podría circular como un secreto a voces. No estamos contando tampoco los programas y diccionarios que averiguar las contraseñas por ejemplo mediante fuerza bruta.

Fecha:
Existen muchos utilitarios gratis que podrían bajar de Internet, los mismos que pueden prolongar indefinidamente la vida de un software. Particularmente conozco uno (no les digo el nombre, porque no se trata de un foro de crackers) que rompe cualquier tipo de protección referente a fechas. Puede detener el tiempo sólo del programa ejecutable o si se prefiere, detiene la hora y fecha del sistema.

Dlls:
Puede ser otra alternativa ( y creo que es la que más te inclinas a usar, aunque no pude comprender bien). De manera general, se puede mencionar que existen muchos programas que te muestran todos los dlls que hace uso la aplicación. Sin ir lejos, se puede utilizar el archivo llamado msinfo32.exe de windows que te muestra con lujo de detalles todos las dlls, incluyendo su ruta completa y existen herramientas que te abren las dlls.

(continua...)
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

RE:Métodos para proteger software

Publicado por Oscar (1178 intervenciones) el 09/02/2003 04:04:44
Número de serie del disco duro:
El número de serie de un disco, cambia cada vez que se formatea, según la hora fecha actual del computador. De esta manera es casi imposible que dos discos tengan el mismo número de serie. Podrías hacer que tu aplicación corra según el número de serie del disco duro del equipo. La desventaja de este método, es que cuando se formatee el disco duro; tendrás que modificar un poco tu software para que reconozca a ese nuevo número de serie.

Número de serie de la ROM BIOS:
Es mejor alternativa que el número de serie del disco duro; ya que no importa que se formatee el disco duro; ya que sólo importa el número del BIOS del equipo donde instales la aplicación. Pude ver un código elaborado en Delphi que te averiguaba el número de serie del BIOS; no sé como se podría hacer eso en PowerBuilder.

Hardlock:
Es el método más seguro para proteger la contraseña. Se trata de una llave (estoy hablando de hardware) que se coloca al puerto de impresión. Y permite instalar el programa sólo en ese equipo. Pude ver esta protección en un software llamado ILWIS. Podrías buscar más sobre hardlock en la red.

En resumen, no existe un método seguro para proteger el software. Tendrás que arriesgarte por uno de ellos. Los más seguros quizá sean los menos realizables o complejos para por parte del programador.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Porque no DLL ni seguridad x PC (1)

Publicado por eduardo.v (208 intervenciones) el 09/02/2003 17:51:33
Muchas gracias a Oscar por su respuesta
Bueno definitivamente todo seria mas sencillo para mi si mi sistema correria en una sola maquina. Pero no es asi. Como explique en los post anteriores tengo clientes que llegan a tener hasta 16 pcs en red (y pueden llegar a mas), cabe indicar tambien que mi sistema esta instalado individualmente en cada PC. En resumen, la idea es que funcione mas o menos de esta forma suponiendo que el mes de enero esta activo:
Rangos de la empresa: (esto deberia estar guardado en algun lugar)
01/01/2003 al 30/01/2003 contraseña: "enero" estado:1 (activo)
01/02/2003 al 28/02/2003 contraseña: "febrero" estado 0 (inactivo)
01/03/2003 al 31/03/2002 contraseña "marzo" estado 0 (inactivo)
(continua...)
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

RE:Porque no DLL ni seguridad x PC (1)

Publicado por Pedro López (68 intervenciones) el 10/02/2003 16:22:32
En el caso que comentas, te recomiendo que guardes la información camuflada y encriptada en una tabla de la base de datos. Es la forma más sencilla de controlarlo, sin tener que actuar en todos los puestos.

Aunque el cliente tenga un técnico que pueda acceder a la base de datos, le sería muy complicado descifrar el contenido de esa información.

Por ejemplo, en los datos que has puesto:
01/01/2003 al 30/01/2003 contraseña: "enero" estado:1 (activo)
Generas un string con todos los datos (Ej: "01/01/2003|31/01/2003|ENERO|1"), encriptas el string y lo guardas en una tabla de la BD.
01/02/2003 al 28/02/2003 contraseña: "febrero" estado 0 (inactivo)
Generas un string con todos los datos (Ej: "01/02/2003|28/02/2003|FEBRERO|0"), y haces lo mismo que con el anterior.

Después, al iniciar tu aplicación, recuperas y descifras esta información, y sabes si el cliente ha apagado o no.

Cuando el cliente te paga un periodo, puedes generar las claves encriptadas en un fichero, que enviarías al cliente. El usuario administrador importaría ese fichero una única vez, y no habría que hacer nada más en los demás puestos, ya que lo que se actualiza es la base de datos.

Un saludo,

Pedro
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Porque no DLL ni seguridad x PC (2)

Publicado por eduardo.v (208 intervenciones) el 09/02/2003 17:57:31
(...continua)
entonces cuando llegue a fecha 01/02/2003 el sistema deberia pedirme una contraseña para poder activar el siguiente rango. Al proporciorle la contraseña (que en este caso seria"febrero") solo el operador principal del sistema deberia ingresarlo por unica vez para que habilite a todas las pc que estan conectadas en red. entonces los rangos quedarian de esta forma:
Rangos de la empresa: (esto deberia estar guardado en algun lugar)
01/01/2003 al 30/01/2003 contraseña: "enero" estado:1 (activo)
01/02/2003 al 28/02/2003 contraseña: "febrero" estado 1 (activo)
01/03/2003 al 31/03/2002 contraseña "marzo" estado 0 (inactivo)
De esta forma los usuarios podran usar el sistema hasta el 28/02/2003 y cuando llegue al 01/03/2003 nuevamente se repite la historia.
(continua...)
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Porque no DLL ni seguridad x PC (3)

Publicado por eduardo.v (208 intervenciones) el 09/02/2003 17:59:44
(...continua)
Como comprenderan no puedo utilizar dll porque no puedo actualizar los datos que pueda guardar en ellas (en este caso el estado), y en el caso de reemplazarlas por otras. seria un poco fastidioso teniendo en cuenta que hay una dll por cada pc. actualmente tengo 9 clientes con estas caracteristicas y al usar dll's me llevaria a estar fabricando dll's cuando termine cada periodo ademas 5 tienen internet 4 no. si reemplazo las dll's tendria que ir yo personalmente a instalarlas lo que me proporcionaria perdida de tiempo. Como se habran dado cuenta lo que pretendo aparte de darle seguridad a mi sistema es crear un mecanismo de control que me permita tener a mis clientes siempre a la expectativa para efectos de los pagos. Yo vendo mi sistema a credito en la mayoria de los casos con plazos de hasta 2 años entonces es importante para mi tener alguna especie de "proteccion" porque la verdad no se como sera en sus respectivos paises pero aqui en el Perú la practica del "Perro Muerto" es casi una religión. Espero comprendan mi interes en poder hacer esto de la manera mas practica.
Saludos desde Peru "Cuna del verdadero Pisco"
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

idea1

Publicado por Oscar (1178 intervenciones) el 10/02/2003 19:43:09
Hola Eduardo:
En primer lugar, mil disculpas por haberte enviado información sobre seguridad de software de manera muy general. No era lo que necesitabas; ojalá que eso haya servido como información para alguien.
En tu caso particular, ya entendí el planteo, incluyendo las restricciones que mencionas, como por ejemplo, no puedes crear tablas, ya que tus clientes manejan plenamente la base de datos y tú solo venderás la aplicación.

Las alternativas que se me ocurren a tu problema son:
Tu “Aliado” principal en la protección de tu software deben ser las fechas límites de cada mes en que estará vigente tu aplicación. Es decir, según la fecha, tú no debes crear la contraseña. Deja que la fecha cree su propia contraseña; claro está que la contraseña que genere deberá estar encriptada. Para ponerte un solo ejemplo, el número de serie del disco duro, resulta de la fecha y hora en que se formatea el mismo. Ese es el mecanismo inventado por Microsoft. Por ejemplo, si el disco se formateo el 25 de octubre de 1997, a las 23:45 y a los 37.84 segundos el número de serie será 336d:172d.
Pero en este caso, tú tendrás que elaborar tu propio script encriptador, para que te genere la contraseña según la fecha del último día del mes. De esta manera tu tendrás que enviar la contraseña por e-mail (porque tú sabes que esa fecha genera esa contraseña) y la aplicación esperará par funcionar esa contraseña ya también generó desde tu aplicación.

Lo bueno de esto, es que si alguien destripa algún dll de tu aplicación, para observar la contraseña que corresponde al próximo mes, ésta aún no se habrá generado y no podrá ver nada, además está
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Idea2

Publicado por Oscar (1178 intervenciones) el 10/02/2003 19:46:21
(viene anterior..)
encriptada.
Tu aplicación correrá únicamente con esa contraseña. La contraseña que se usó, supongamos en el anterior mes, ya no tendrá vigencia y eso no tiene importancia (es mejor que tu aplicación tenga en un determinado momento una sola contraseña válida); pero por si surge algún problema de este tipo, no olvides que puedes emplear en las fechas los operadores menor o igual, para que corra tu aplicación en fechas anteriores; pero no en posteriores.
Ahora si la pregunta es donde se puede guardar esta información, se me ocurre que podría ser en un array dinámico (unboud). El tamaño de un array dinámico se incrementa al asignar un valor a una nueva entrada en el array. Tu array puede ser: Unidimensional ó dimensional. Ejemplo:
String Mes[]
Luego:
If mes[2]=”Febrero” then
// la contraseña es tal cosa
open(w_principal)

Cuidado con los tipos de datos que manejes en un array, ya sabes que sólo te acepta uno solo.
Si esto funciona bien, es decir, si el array puede guardar las contraseñas de manera indefinida según la fecha. Luego de los dos años, que termine de pagar tu cliente, seguirá pidiendo contraseña. Depende de ti si lo quitas o lo programas sólo por dos años.
Si no resulta el array, quizá podrías crear una estructura o un data windows external. No sé.
Otro punto que mencionas es que esa contraseña, deseas darle sólo al administrador del sistema. En este caso, se supone que en el sistema, se dan los permisos según la jerarquía del personal. Se supone que el administrador del sistema administra con SQL Server.
(continua...)
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Idea3

Publicado por Oscar (1178 intervenciones) el 10/02/2003 19:48:13
(viene del anterior...)
Si desde tu aplicación deseas colocar una cierta restricción para que sólo funcione tu contraseña en el servidor o desde una máquina cliente específica; podrías hacer que la contraseña generada por la fecha, además verifique que se está ejecutando según el nombre del equipo o su IP. Por ejemplo:

//Podrías averiguar el nombre del equipo a través del regedit de windows. Por ejemplo:
String valor
RegistryGet("HKEY_LOCAL_MACHINE\Network\Logon", "username", valor)

//Imprimes el resultado en un static Text
st_1.text=String(valor)

If mes[2]=”Febrero” then
// la contraseña es tal cosa además, y si además el nombre del equipo es tal cosa (valor) then
open(w_principal)

Una vez expuestas las ideas de manera general, acá van algunas cosas que te podrían ayudar de manera más puntual:

Para crear claves encriptadas, existe un código en el que te podrías basar (lamentablemente está hecho en JavaScript) a ver si puedes adaptarlo a PowerBuilder. De todas maneras eso no es muy importante, ya que puedes crear tu encriptación como mejor te parezca. La dirección es:
http://programacion.com/articulo/tw_password2/

(Continua...)
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Idea4

Publicado por Oscar (1178 intervenciones) el 10/02/2003 19:49:35
(del anterior...)
Acá va un script en PowerBuilder para obtener el último día del mes.
Se coge una fecha, se incrementa el mes, se cambia el día por “01” y entonces restamos 1:
Int li_retday, li_month, li_year
li_month=month(ad_date)
li_year=year(ad_date)
if li_month<12 then
li_month++
else
li_month=1
li_year++
end if
//construimos una fecha nueva
ld_newdate=date(li_year),li_month,1)
//extraemos el ultimo día del mes anterior
ld_previosmonthlastday=day(relativedate(ld_new_date,-1))

Yo se que tú tendrás que hacer el “trabajo duro” para que tu protección funcione como tu quieres. Estas ideas se me ocurrieron y sé que están llenas de problemas para ejecutarlas, inclusive hay errores de concepto. Pero quizá algo podría servir.

Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar