style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

Aplicacion JAVA con KEY

Un saludo a todos los registrados en este sitio, el motivo de este mensaje es para realizar una consulta de apoyo, quisiera saber si alguien de ustedes pudiera decirme como podría ponerle un KEY a una aplicación realizada con JAVA básicamente quisiera saber como hacer un instalador de una aplicación java y poder crear un KEY para asegurar la instalación, sin mas por el momento quedo a sus ordenes y les agradezco de antemano la atención

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

carrera armamentista

Primero que nada, es muy importante que sepas, que tengas muy presente, que ese esquema de autenticación no es infalible, es bastante burlable de hecho, más en Java.

Piensa en el esquema de manera abstracta, no te preocupes ahora por la implementación. Necesitas por un lado un generador de claves, el cual tendrás guardado en un bunker para generar las claves a quienes te paguen. Por otro lado, tendrás un validador de claves, incluido en cada copia de tu software.

La idea es que cualquiera puede bajar tu software, comprarlo pirata en el metro, copiarlo de un amigo, etc; pero necesitan una clave válida para activarlo.

Opción 1: Si esto funciona offline, entonces la validación consiste únicamente en hacer checksums y cosas así, pero no tienes manera de saber si alguien usa y reusa la misma clave N veces.

Opción 2: Si esto funciona online, entonces la validación consiste en que el software se conecta a un servidor que tú pusiste, envía la clave y el servidor contesta si la clave es válida y si es nueva (aquí ya puedes detectar si es repetida y rechazarla).

La opción 1 se usaba mucho en los 80's y la bronca es que la gente se pasaba la copia del software junto con la clave que había que teclear para activarlo. Aparte de eso, había quienes se ponían a hacer generadores de claves y entonces aunque no tuvieras una clave válida, conseguías el generador de claves y te hacía una inventada al vuelo que pasaba las validaciones del software.

La opción 2 es la que se usa hoy en muchos programas, la bronca es que sólo se puede activar el software cuando se tiene conexión a internet (cada vez es menos problema, pero en algunos casos no deja de ser un impedimento). La bronca principal de esta opción es que se puede hacer un servidor falso de autenticación que conteste que cualquier clave es válida. Para dificultar esto pues hay que hacer un protocolo muy complicado para que sea difícil de implementar el servidor falso, pero solamente se tiene que implementar una vez y luego se pone en internet y todo mundo tiene acceso al servidor falso.

Y la bronca que tienen ambos, principalmente en Java, es que al final sabes que existe un código similar a esto dentro del software:

if (Validador.aplicacionEsLegitima()) {
  ejecutarNormalmente();
} else {
  decirleAlUsuarioQueEsPiratota();
  enviarUnMailATodosSusContactosAcusandoloDePiratota();
  System.exit(-1);
}

Por lo tanto, lo único que hay que hacer para burlar el software, es encontrar la clase Validador, y sustituirla por una clase que tenga esto:

public class Validador {

  public static boolean aplicacionEsLegitima() {
    return true;
  }
}

Y con eso ya el software no pedirá clave alguna.

Para burlar eso, puedes hacer varias cosas: ofuscar el código, o no ponerle "Validador" a tu clase sino "com.mipaquete.Utils" o simplemente meter el método aplicacionEsLegitima() en alguna clase donde no viene al caso para que a nadie se le ocurra buscar ahí o que la llamada no se vea sospechosa (y evidentemente no se llama aplicacionEsLegitima(), ni siquiera checkForUpdates() sino algo tipo cargarPreferencias() o algo que sea de esperarse ver que se llame cuando carga la app).

Pero a fin de cuentas, alguien con suficiente motivación y/o tiempo libre y/o algo que demostrar, se pondrá a descompilar tu aplicación para revisar el código y eventualmente encontrará el punto en donde se conecta la app a tu servidor de autenticación o donde pide la clave, etc.

Imagen de ezamudio

Bibliotecas, frameworks, etc

Toda la explicación fue para que puedas darte cuenta por qué no existe una biblioteca o framework o software genérico para generación y validación de llaves... si yo hiciera un software para resolver ese problema, alguien más haría un software para burlar mi software y entonces no tendría ningún caso ya usar mi software para proteger tu software porque hay otro software que elimina la efectividad de mi software en tu software.

software software.

respuesta Java con KEY

te agradezco la respuesta anterior, y me gustaría comentarte que entiendo tu punto de vista para lo que me mencionas referente a la seguridad de este pero pues entonces no se si tu me pudieras proponer algún método que pueda utilizar para poder trabajar esto, ahora si que esto se me ocurrió por el hecho de que es como comúnmente se trabaja, sin mas por el momento quedo a tus ordenes

Imagen de Fonseca

Podrías combinar todos los anteriores.

Es la realidad, como ya sabemos nunca podremos desarrollar una aplicación infalible, pero si podrías complicarles mas la tarea de burlar la autentificación si utilizas una combinación de los métodos anteriores.
Con respecto al primer método del post anterior, podrias generar una key apartir de ciertas caracteristicas de la pc eso te permite un poco mas de protección.
Aunque recuerda que seguridad es solo un estado mental.
Saludos.

Imagen de ezamudio

Caso

Para qué caso es? Quieres ponerle llave a una aplicación que le vendes a ciertos clientes (una base pequeña, donde tengas cierto control)? O será software empaquetado para venta al público en general?

mmm...podrías hacerla un poco

mmm...podrías hacerla un poco más fácil. Una DB con los KEY generados por ti, que funcionara online (de hecho ya es raro el programa que no funciona con autenticación online). De ahí revisar por DB si ese KEY está asignado y creado por ustedes ;). Cómo te ha dicho @ezamudio, el sistema de key gen no es del todo fiable.

Eso es lo que te recomendaría hacer lotes de claves válidas y ya generadas por que estén en un servidor. La bronca con este método es revisar cuantas veces ha sido ingresada esa clave...por lo que la limitarías a un número de veces, a una compu (por medio de la MAC Address por ejemplo) o a otra cosa.

Imagen de ezamudio

auth online

Ya mencioné desde el principio que la autentificación online no es infalible tampoco, hay al menos 2 formas de burlarla.

Imagen de Fonseca

Totalmente de acuerdo.

Exacto. Aparte eso tendria sus limitantes.
Creo como ya lo dije antes que combinar ambas tecnicas (la key y el auth online), seria una buena opción. Es más creo que ya es tiempo de desarrollar una nueva forma de autentificación.

Imagen de ezamudio

problema raíz

El problema seguirá siendo el mismo siempre: Si el ejecutable está en manos del usuario, es modificable. Por ingeniería reversa, por decompilación, por modificación directa a los binarios, por lo que sea. Alguien eventualmente encontrará el bit que hay que voltear para que la aplicación crea que ya fue autenticada. Y ese ejecutable aparecerá en miles de páginas de torrents para que todo mundo lo baje.

No necesitamos una nueva forma de autenticar software. Se necesita un nuevo modelo de negocio. Y ya lo tenemos: el software debe ser un servicio, no un producto. Es obsoleto seguir queriendo tratar el software como un producto. Sólo si tienes un contrato de soporte vale la pena todo ese rollo de la autentificación, y si ya hay una relación directa entre el cliente y el autor (o dueño de los derechos del software), medio sobra el esquema de autentificación.

Cómo mencioné, no es del todo

Cómo mencioné, no es del todo segura =)...Y a mi se me ocurren 4, aunque la última no la he probado del todo.

Si el ejecutable está en

Si el ejecutable está en manos del usuario, es modificable. Por ingeniería reversa, por decompilación, por modificación directa a los binarios, por lo que sea. Alguien eventualmente encontrará el bit que hay que voltear para que la aplicación crea que ya fue autenticada. Y ese ejecutable aparecerá en miles de páginas de torrents para que todo mundo lo baje.

[sarcasmo] Pues será en otras plataformas, porqué en Java eso ni existe. No hay maneras simple de decompilación de software a un click, te toma AÑOS ENTEROS decompilar un programa Java[/sarcasmo] (bueno creo que ya se entendió.

No necesitamos una nueva forma de autenticar software. Se necesita un nuevo modelo de negocio. Y ya lo tenemos: el software debe ser un servicio, no un producto. Es obsoleto seguir queriendo tratar el software como un producto. Sólo si tienes un contrato de soporte vale la pena todo ese rollo de la autentificación, y si ya hay una relación directa entre el cliente y el autor (o dueño de los derechos del software), medio sobra el esquema de autentificación.

Así es, a menos que sean aplicaciones más cerradas que las de iP[ hone | [a|o]d ], donde si puedes tratarlas cómo productos.

Si el ejecutable está en

Si el ejecutable está en manos del usuario, es modificable. Por ingeniería reversa, por decompilación, por modificación directa a los binarios, por lo que sea. Alguien eventualmente encontrará el bit que hay que voltear para que la aplicación crea que ya fue autenticada. Y ese ejecutable aparecerá en miles de páginas de torrents para que todo mundo lo baje.

[sarcasmo] Pues será en otras plataformas, porqué en Java eso ni existe. No hay maneras simple de decompilación de software a un click, te toma AÑOS ENTEROS decompilar un programa Java[/sarcasmo] (bueno creo que ya se entendió.

No necesitamos una nueva forma de autenticar software. Se necesita un nuevo modelo de negocio. Y ya lo tenemos: el software debe ser un servicio, no un producto. Es obsoleto seguir queriendo tratar el software como un producto. Sólo si tienes un contrato de soporte vale la pena todo ese rollo de la autentificación, y si ya hay una relación directa entre el cliente y el autor (o dueño de los derechos del software), medio sobra el esquema de autentificación.

Así es, a menos que sean aplicaciones más cerradas que las de iP[ hone | [a|o]d ], donde si puedes tratarlas cómo productos.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">