Re: [OFF] Lenguajes de programación para escritorio
El 11 de febrero de 2016, 14:24, alparkom . <alparkom@gmail.com> escribió:
>
> El día 11 de febrero de 2016, 10:14, German Cardozo
> <gcardozo@gmail.com> escribió:
> >
> > On Feb 11, 2016 7:38 AM, "Rafael Cantos Villanueva" <rafael@rafaelcantos.es>
> > wrote:
> >>
> >> Saludos
> >>
> >> Rafa
> >>
> >>
> >>
> >> El 11/02/2016 a las 12:28, alparkom . escribió:
> >>>
> >>> El día 11 de febrero de 2016, 8:01, Luis Felipe Tabera Alonso
> >>> <taberalf@unican.es> escribió:
> >>>>
> >>>> On Thursday 11 February 2016 07:33:51 alparkom . wrote:
> >>>>>
> >>>>> Explicado de forma simple; si hago una conexión en Java, el archivo
> >>>>> .java tendrá los datos de conexión (en caso de usar MariaDB, se
> >>>>> debería escribir en el .java la dirección del servidor, el usuario de
> >>>>> MariaDB, la contraseña del mismo y el puerto usado)... entonces, que
> >>>>> pasa si descompila dicho el .class que genera Java?
> >>>>
> >>>>
> >>>> Lo estás haciendo mal, si el programa tiene todos esos datos 'tal cual',
> >>>> te va
> >>>> a dar igual el lenguaje de programación, compilado o no. Un usuario
> >>>> malicioso
> >>>> podrá obtenerlos. ¿Quién se supone que tiene acceso a la BD? ¿Solo
> >>>> usuarios?
> >>>> ¿Solo el programa? El usuario/programa que acceda a la BD ¿Puede hacer
> >>>> con
> >>>> ella lo que quiera? ¿debería poder?
> >>>>
> >>>
> >>> Se supone que C++ es compilado a código máquina, y es imposible
> >>> obtener el código de este lenguaje una vez compilado por lo que no
> >>> podrían obtener los datos.
> >>
> >>
> >> Te equivocas, yo te lo vuelvo a repetir. Da igual que el programa sea
> >> compilado o no, se puede descompilar igualmente y acceder a los datos.
> >>
> >
> > +1
> >
>
> Vale. Eso es ingeniería inversa, no? También quiero aprender eso,
> suena interesante.
>
Hola, hola
Sólo queía completar las respuestas de Rafael y German con un ejemplo
práctico y desmontar por completo esa idea de que en código del
programa (fuente, objeto, etc) es un buen lugar donde almacenar
cualquier cosa que no sea... código ;-)
Hagamos un ejemplo muy sencillo en C....
int main()
{
char string1[] = "Hello World";
char string2[] = "clavesecreta";
return 0;
}
Lo compilamos, etc, etc... y obtenemos nuestro ejecutable, vamos a ver
que ha pasado con nuestra clave. En el interior de nuestro ejecutable
encontramos esto
(...)
0001720 20 c7 45 f4 48 65 6c 6c c7 45 f8 6f 20 57 6f c7 > .E.Hell.E.o Wo.<
0001740 45 fc 72 6c 64 00 c7 45 e7 63 6c 61 76 c7 45 eb >E.rld..E.clav.E.<
0001760 65 73 65 63 c7 45 ef 72 65 74 61 c6 45 f3 00 b8 >esec.E.reta.E...<
0002000 00 00 00 00 c9 c3 66 90 66 90 66 90 66 90 66 90 >......f.f.f.f.f.<
(...)
Decididamente no es un buen sitio para guardar unas credenciales salvo
que las cifres por ejemplo, en cuyo caso... ¿para que hacer
dependiente esto de la compilación del programa?.
>
> >>>
> >>> Se supone que el software debería tener acceso a la base de datos. Si
> >>> puede hacer lo que quiera es un sí, aunque dudo importe demasiado la
> >>> respuesta a esta pregunta.
> >>>
> >>> Entonces como lo hacen softwares como algunos Adobe, donde debes
> >>> iniciar sesión para ocupar varios de sus productos? Con HTTP?
> >>
> >>
> >> Como te indicaba en otra respuesta, centra la seguridad en la base de
> >> datos y el servidor. Una opción es esta, enviar por htp, o mejor aún por
> >> https, emplear sockets, etc, una solicitud de acceso al servidor, con un
> >> usuario y contraseña. Desde el servidor, se realiza una conexión a la base
> >> de datos, con los datos almacenados de dicha conexión en el servidor, y
> >> autenticar al usuario. Una vez que lo has autenticado, puedes devolver un
> >> tokken de conexión que valide las comunicaciones realizadas entre ese
> >> usuario y el servidor a través de la aplicación. Esto, si te fijas, es igual
> >> que cuando accedes a un servicio web introduciendo tu usuario y contraseña
> >> desde un navegador web.
> >>
> >
> > Si lo que quieres es una aplicación cliente-servidor, donde el cliente se
> > ejecute desde la estación como una aplicación instalable, y además requieres
> > (tus argumentos tendrás para ello) que se use conexiones a la Base de Datos
>
> Mis argumentos? Suponiendo que tengo 50 mil personas distintas con el
> software instalado, tendré 50 mil usuarios en la base de datos... no
> crees que eso es demasiado?
>
> No hablo de columnas de una tabla, sino de usuarios de la base de datos...
>
> > mediante un único usuario, mi recomendación es mediar con una capa entre el
> > cliente y la BD que exponga la interfaz que deseas que conozca el cliente.
> > Dicha capa se encargará de la funcionalidad, la autenticación y la seguridad
> > entre otros, y allí implementar el protocolo que más convenga.
> >
> > La comunicación con la base de datos quedará bajo este "Middleware", y
> > podrás protegerle mediante firewall u otras medidas, dependiendo de tus
> > recursos y arquitectura.
> >
> > Varios lenguajes tienen facilidades para crear estos componentes, exponiendo
> > mediante "buses de servicio" u otros elementos, un API. Puedes desarrollar
> > además uno propio, pero todo dependerá del alcance propuesto para la
> > aplicación, como por ejemplo, hacer uso de estándares como SOA. Estas
> > tecnologías no son exclusivas de los servicios WEB, aunque su uso este más
> > extendido en ese campo.
> >
> > Con este componente mediando entre tus clientes y el modelo de datos, puedes
> > desacoplar el desarrollo de este, haciendo uso incluso de un lenguaje de
> > programación distinto al usado en el servidor, y disponer de clientes para
> > diferentes sistemas operativos, dispositivos o situaciones como
> > requerimientos de accesibilidad.
> >
> > Siempre encontrarás problemas de seguridad a resolver, pero todo dependerá
> > de los requerimientos exigidos y hasta donde estés dispuesto a ceder y
> > tolerar.
>
> Vale. Veo que ni un solo lenguaje haría lo que yo quiero (aunque
> pensándolo bien, era obvio).
> La solución creo que será que el cliente tenga una base de datos
> propia y que cada cierto tiempo se compare con la del servidor y se
> actualicen unas a otras.
>
> Entonces, conectar C++, Java, entre otros, a bases de datos como MySQL
> o MariaDB, no sirve de mucho? Excluyendo a SQLite obviamente.
>
¡Claro que sirve de mucho!, ya te han comentado algunos modos de
hacerlo sin comprometer los datos de acceso, a esto puedes añadir el
cifrado y alguna otras técnicas. Hay un montón de posibilidades.
Un saludo
Reply to: