Con Java no se puede Encriptar/Desencriptar y es inseguro

jcl · #1 (**permalink**) 04/10/2003, 04:55

Hay muchas cosas que al parecer, no se pueden realizar con java.

Una de ellas es Encriptar o desencriptar datos, y esto lo digo pues me he cansado de buscar en casi todos los lugares especializados en este ¿¿ fabuloso lenguaje ?? y no he podido encontrar, ni siquiera alguna notas sobre el particular y, mucho menos algún código que demuestre cómo se hace eso.

Sólo en el SDK 1.4.2 aparece una nota sobre the SunJCE provider for Java Cryptography APIs pero no dice cómo utilizarlo efectivamente, es decir, no da ningún ejemplo. (http://java.sun.com).

Otro de los aspectos que me hacen ver a java como una herramienta insegura, es el hecho de que en los accesos remotos, por ejemplo a SQL Server, cualquiera puede ver fácilmente el UserID y el Password de conexión y todo lo demás, con sólo abrir con WodrPad u otro programa editor, los archivos tipo MiClase.class, específicamente me refiero a los casos en que se usa la sentencia:

con = DriverManager.getConnection(url, "UserID", "Password")

En los archivos .Class esos datos de seguridad pasan a ser del dominio público, o sea, de todo aquél que tenga acceso a esto archivos, y con sólo abrirlo puede conocer cómo acceder a la base de datos remota (eso es lo que he podido comprobar hasta ahora).

Espero estar equivocado (ojalá y así sea), por lo cual solicito que alguien que sepa de este asunto y que haya visto la otra cara de la verdad, me aclare esta ¿duda? o ¿certeza? ... pero no con más bla, ... bla, ...bla, ..., sino con hechos, con ejemplos, etc.

Saludos.

clinisbut · #2 (**permalink**) 03/11/2006, 04:24

hay alguna solución respecto al problema q plantea jcl?

Tipdar · #3 (**permalink**) 03/11/2006, 06:53

¿De verdad crees que Sun Microsystems haría algo tan inseguro como planteas? Acá te pongo algunas clases de las que intervienen en los asuntos de criptografía en Java:

- java.net.URLEncoder
- java.security.spec.AlgorithmParameterSpec
- java.security.spec.KeySpec
- javax.crypto.Cipher
- javax.crypto.SecretKey
- javax.crypto.SecretKeyFactory
- javax.crypto.spec.PBEKeySpec
- javax.crypto.spec.PBEParameterSpec
- java.security.MessageDigest
- sun.misc.BASE64Encoder
- sun.misc.CharacterEncoder

Esto existe desde que la gente comenzó a andar a pie por el mundo. Con solo abrir Google y poner "criptografía java" o cosas por el estilo, verás como comienzan a aparecer ejemplos y documentación.

Una de las cosas que hacen de Java un lenguaje muy popular es su marcada y probada seguridad. Pasando a tu otro tema, las cadenas de conexión a bases de datos viajan por canales seguros y encriptados. Otra cosa, al programador que se le ocurra poner dentro de su código, en cualquier lenguaje, cosas como el nombre de usuario y contraseña (además de puerto, ip, etc, etc, etc) para conectarse a su bases de datos, en primera es muy mal programador, porque en el mismo momento en que cambie su contraseña pues, inevitablemente tendrá que recompilar su código y por otra parte, y no sé si sabías esto, es que todos los archivos compilados, no importa en que lenguaje o en que IDE fueron compilados, son decompilables... Si las personas programaran por programar sin usar patrones y cosas por el estilo, entonces las aplicaciones no serían escalables, portables, y un conjunto de cosas más, es decir pasarían cosas como la que has descrito. Eso que acabas de describir, es, y disculpame la palabra, pero soy tan feo como tan franco, uno de los disparates más grandes que he leído en el foro y te confieso, me he reído mucho porque una de las cosas, como ya he dicho, de las que Java hace gala ante otros lenguajes es de la seguridad.

Estoy completamente seguro de que no seré el único en responder. Otros amigos del foro aportarán otras cosas.

Buen día

clinisbut · #4 (**permalink**) 03/11/2006, 08:06

Ya, ya, yo no soy el que inició este tema, pero soy novato con java y me he dado cuenta de que es posible ver los datos de conexión abriendo el archivo .class desde cualquier editor de texto, mi preocupacion es esa.

Dices que cualquier programador que se precie nunca escribiria esos datos en el código...
Me gustaria saber que es lo que harias tu (o los demás usuarios del foro) en ese lugar.

Saludos

chuidiang · #5 (**permalink**) 03/11/2006, 09:23

Hola:

El usuario y password de la base de datos se la puedes pedir al usuario y no es necesario meterla en código.

En caso de que sea fija y no quieras pedirsela y quieras meterlo en el código, supongo que alguien que sepa encontrará muchas más soluciones, pero a mi se me ocurre que te puedes hacer un programa tonto que las encripte y las meta en un fichero y tiras a la basura el programa tonto. Luego tu programa en serio lee el fichero encriptado y lo desencripta. Ese fichero encriptado incluso puedes meterlo dentro del jar con tu aplicación.

En cualquier otro lenguaje, si pones la clave en claro dentro del código, posiblemente también puedas verla en el .exe. Que yo sepa ningún lenguaje al compilar "encripta" el texto en claro que está en su código.

Se bueno.

GreenEyed · #6 (**permalink**) 03/11/2006, 10:04

Si no quieres que la gente que use tu programa pueda ver el usuario/clave de acceso a la BDD, la unica solucion es no escribirlo NUNCA en nada que el pueda obtener. Sean .class, ficheros encriptados, lo que quieras. Si tu programa es capaz de descriptar ese fichero para obtener la clave, un usuario que modifique tu programa lo puede obtener.

Con aplicaciones "nativas" es más complicado, pero con un editor de codigo maquina tambien se puede hacer.

El escribirlas en un sitio que no pueda acceder es, pedirsela a el, obtenerla de un servidor remoto de forma segura, almacenarla en un dispositivo hardware accesible solo por clave (SmartCard) ... etc. todo lo demás es vulnerable, con más o menos dificultad.

No es cuestion de Java, todos los programas sufren el mismo problema y precisamente por eso no hay apenas programas o juegos, para instalar en cliente, que no los encuentres por Internet "desprotegidos". Es lo que hay.

@Chuidiang: El mensaje original es del 2003, así que aunque cuando lo escribió ya estaba equivocado, no creo que venga a leer una respuesta 3 años despues

.

chuidiang · #7 (**permalink**) 03/11/2006, 14:58

Hola:

Hombre, yo no me he ido a los posts del año del catapum. Este estaba el primero porque Clint Eastwood parece que tenia el mismo problema y lo ha resucitado (hoy) y luego más gente ha contestado.

Ciertamente no se me había ocurrido que se puede coger el código java y modificarlo para desencriptarlo.

Se bueno.

angelpunk · #8 (**permalink**) 12/07/2009, 19:51

hola para solucionar ese proble con las bases de datos usa los servlets de java

jcl · #9 (**permalink**) 13/07/2009, 05:06

Cita:

Iniciado por GreenEyed

Si no quieres que la gente que use tu programa pueda ver el usuario/clave de acceso a la BDD, la unica solucion es no escribirlo NUNCA en nada que el pueda obtener. Sean .class, ficheros encriptados, lo que quieras. Si tu programa es capaz de descriptar ese fichero para obtener la clave, un usuario que modifique tu programa lo puede obtener.

Con aplicaciones "nativas" es más complicado, pero con un editor de codigo maquina tambien se puede hacer.

El escribirlas en un sitio que no pueda acceder es, pedirsela a el, obtenerla de un servidor remoto de forma segura, almacenarla en un dispositivo hardware accesible solo por clave (SmartCard) ... etc. todo lo demás es vulnerable, con más o menos dificultad.

No es cuestion de Java, todos los programas sufren el mismo problema y precisamente por eso no hay apenas programas o juegos, para instalar en cliente, que no los encuentres por Internet "desprotegidos". Es lo que hay.

@Chuidiang: El mensaje original es del 2003, así que aunque cuando lo escribió ya estaba equivocado, no creo que venga a leer una respuesta 3 años despues

.

Tipdar dice que “Esto existe desde que la gente comenzó a andar a pie por el mundo…”, pero lo hacer, precisamente como dices tú ¡tres (3) años después!!

Ojalá y no pase igual con la AH1N1, tres años más adelante, cuando algún “vivo de los medicamentos”, pregunte ¿y por qué tanta alharaca, si aquí tengo la vacuna?, claro luego de miles de muertes.

Hace horas, el amigo angelpunk también recomienda algo, pero sólo dice “hola para solucionar ese proble con las bases de datos usa los servlets de java”, pero ni siquiera da algún ejemplo.

Pues, hace bastante tiempo que no visitaba este foro, en virtud a que dejó de ser lo que era en los años 2000-2002.

Por otro lado, ya hoy en día, con la aparición de Visual Studio 2005-2008, SQL Server 2005-2008, ya esos problemas son materias del pasado.

Gracias de todos modos.

PD. Respondí porque me llegó el mensaje

GreenEyed · #10 (**permalink**) 13/07/2009, 05:43

Cita:

Iniciado por jcl

Tipdar dice que “Esto existe desde que la gente comenzó a andar a pie por el mundo…”, pero lo hacer, precisamente como dices tú ¡tres (3) años después!!

Aunque la respuesta la escribiera 3 años después, cuando tu hiciste la pregunta la misma respuesta era igual de válida y tus suposiciones igual de equivocadas de que no había documentación o que lo de decompilar los .class y ver eso era un problema exclusivo de Java.

Cita:

Iniciado por jcl

Ojalá y no pase igual con la AH1N1, tres años más adelante, cuando algún “vivo de los medicamentos”, pregunte ¿y por qué tanta alharaca, si aquí tengo la vacuna?, claro luego de miles de muertes.

De aquí a 3 años, cuando cuenten el numero de muertos causados por la AH1N1 y comparen con los causados por la gripe común, que de momento son muchísimos más aunque éstos no salen en la tele, lo que pensaran es "madre mía menuda estafa que nos vendieron los fabricantes de vacunas". Pero bueno, ese no es tema de este foro así que mejor lo dejamos.

Cita:

Iniciado por jcl

Por otro lado, ya hoy en día, con la aparición de Visual Studio 2005-2008, SQL Server 2005-2008, ya esos problemas son materias del pasado.

Si tú lo dices...
http://www.decompiler-vb.net/
http://msdn.microsoft.com/en-us/vcsharp/aa336818.aspx (seccion decompilers)

S!

picstar · #11 (**permalink**) 22/03/2010, 05:16

Que pena me dais los borreguillos que os arrodilláis ante el efectismo de M$, cuando la verdad es que M$ no ha inventado nada en su p... vida.

ezefarina · #12 (**permalink**) 23/03/2010, 07:02

Q precario !!. Gente, desde cuando como programadores nos limitamos a las funciones propias del lenguaje? Desde cuando, al ver q no hay una funcion para tal o cual cosa lloramos en vez de hacerla por nosotros mismos??? Este post realmente no tiene sentido. Coincido completamente con tripdar y greeneyed, y seguramente algun otro ( ni me gaste en leer el post completo ). Gente, si una funcion especifica como encriptacion, no existiera, para q estamos? No somos desarrolladores para quedarnos mirando q es lo q falta. Slds

ezefarina · #13 (**permalink**) 23/03/2010, 10:21

Cita:

Iniciado por GreenEyed

Aunque la respuesta la escribiera 3 años después, cuando tu hiciste la pregunta la misma respuesta era igual de válida y tus suposiciones igual de equivocadas de que no había documentación o que lo de decompilar los .class y ver eso era un problema exclusivo de Java.

De aquí a 3 años, cuando cuenten el numero de muertos causados por la AH1N1 y comparen con los causados por la gripe común, que de momento son muchísimos más aunque éstos no salen en la tele, lo que pensaran es "madre mía menuda estafa que nos vendieron los fabricantes de vacunas". Pero bueno, ese no es tema de este foro así que mejor lo dejamos.

Si tú lo dices...
http://www.decompiler-vb.net/
http://msdn.microsoft.com/en-us/vcsharp/aa336818.aspx (seccion decompilers)

S!

Nadie lo pudo haber dicho mejor. GreenEyed pasame tu avatar que me hago una remera jajajajjaja