Vuestra opinión sobre el API XML-RPC de una aplicación

[dec]

Hola,

Empezado por Román

(...) actualmente manejas en loturak, via http, una autentificación y tal y es lo mismo de insegura que en el caso que te ocupa ahora. Si vía http no te quita el sueño, ¿por qué te lo quita ahora?

Bueno. Efectivamente, porque se me ocurrió así desde un principio. Es decir, desde el momento en que era necesaria la autentificación del usuario pensé que podría enviarse el MD5 de la contraseña. Es cierto que Mario a puesto en evidencia que los datos del enlace siguen enviándose en claro, y, esto en los enlaces públicos importa menos, pero, en los privados... en fin.

No sé. Supongo que he ido a salvar la contraseña por todos los medios posibles mientras que el resto de datos he dado por supuesto que viajarían en claro... sin más. Lo que significa le hecho de que lo decidiera así es que ahora pienso que podría hacer lo mismo con la contraseña en la autentificación en Loturak, no en el API... sino en la propia página Web. Se me ocurre que podría codificar la contraseña igualmente con MD5 valiéndome de JavaScript.

La seguridad es algo que habría que tener en cuenta... a lo menos hasta donde pudiera llegar uno. Mismamente al liarme con todo esto del API he solucionado (hasta donde llego) un par de problemas de seguridad en sendas partes de Loturak: era posible hasta anteayer para un usuario registrado editar así como borrar enlaces de otros usuarios. No sencillamente, es decir, requería comerse un poco la cabeza, pero, no demasiado. Y sin embargo, pensando en todo esto... los datos siguen viajando en claro...

Empezado por Román

Por otro lado, no entiendo eso de mandar la contraseña cifrada.

Bueno. Ya digo que es una idea mía... así que puede ser perfectamente inútil o innecesaria... de hecho en WordPress, sin ir más lejos, no se cifra la contraseña del usuario cuando esta se utiliza el API XML-RPC conque cuenta este gestor de contenidos. A lo menos eso he creído entender luego de revisar el código fuente relacionado. Ya digo. Lo pensé así Román... centrándome (acaso un tanto irracionalmente, puesto que dejo los datos del enlace en claro), digo, queriendo proteger la contraseña del usuario.

Empezado por Román

Hasta donde entiendo, en el caso de la autenticación de loturak, la contraseña cifrada te sirve para poder mantener al usuario en sesión (no digo logueado porque suena horrible) sin necesidad de guardar la contraseña real en una cookie, pero en algún momento debe hacerse la autenticación. ¿Cómo se llevaría esto a cabo con la API?

Efectivamente, usando un par de Cookies conseguimos que la autentificación del usuario "persista" en el tiempo. Lo que se guarda en la Cookie... no te lo vas a creer... es el MD5 (no recuerdo ahora mismo si doble) del MD5 (este seguro doble) de las contraseñas de los usuarios. Me parece que añado algo más en la clave que guardo en la Cookie...

Ahora bien, en todo caso, no sé si te aclarará el asunto un poco si te digo que las contraseñas de los usuarios no se guardan en claro en la base de datos, sino que se guarda el "doble MD5" de las contraseñas. Los métodos del API que lo necesiten ya recogen el doble MD5 de una contraseña de usuario, así que la autentificación se lleva a cabo con el login de usuario y con la contraseña tal cual llega, pues es justo lo que se necesita.

Empezado por Román

Otra cosa, ¿me podría alguien explicar qué es una API-KEY?

Pues debe ser algo como una "llave" que permita a determinado programador/desarrollador acceder a un determinado API. No tienes la "llave"; no puedes acceder al API. Google hace uso de esto en sus APIs... generalmente, al menos, asigna al que lo solicita una clave (creo que única). En el caso de Google además, al menos para ciertas APIs, asigna a cada clave un número limitado de "consultas a la API"... que es algo que no sé muy bien cómo va exactamente, pero, en definitiva, no puedes "buscar en Google" desde tu aplicación más de 1.000 veces al día o algo así... ciertamente yo también estoy verdísimo en todo esto, como en casi todo, cada vez que lo pienso más.

[dec]

Hola,

Ya contamos con un método "EnlacesUsuario" y con otro "NumeroEnlaces" (del usuario). Se han preparado "ejemplos" de uso de estos métodos tanto en PHP como en Delphi. También he quitado los "SpinEdits" de todos los ejempos de Delphi que los usaban. He repasado, en general, todos los ejemplos. Y creo que eso es todo. Ya me diréis si os place y tenéis tiempo lo que os parece.

¡Que paséis un buen domingo!

[[seoane]]

Bueno, voy también a opinar yo, no se si para ayudar o para confundir mas Lo primero, si tienes preocupación por la seguridad por que no utilizas simplemente https en vez de http, todo los datos irán cifrados, se acabo el preocuparse de quien esta mirando. En cuanto a lo de mandar la contraseña cifrada o en claro, el cifrar la contraseña no nos proporciona ninguna seguridad extra, si alguien llega a tener acceso a los datos y puede leer el md5 eso es todo lo que necesita, porque siempre es el mismo, cuando quiera utilizar la api solo tiene que usar el mismo hash no tiene porque conocer la contraseña.

Creo recordar que sistemas como el messenger utilizan un sistema de identificación basado en md5 bastante seguro, cuando un cliente se conecta al servidor este le manda un numero aleatorio, entonces el cliente genera el md5 a partir de la contraseña y ese numero. Cuando el servidor recibe el md5, hace lo mismo, utiliza la contraseña original y el numero que genero y también calcula su md5, entonces compara ambos hash. Esto llevado a tu caso puede ser bastante complicado de implementar, y por lo menos implicaría el tener que usar 2 peticiones consecutiva, una para obtener el número aleatorio y otra para mandar la petición con la contraseña cifrada. Bueno, ahí te queda la idea ....

En cuanto a lo de la API-KEY puede ser buena idea, te comento que en flickr te la dan solo con estar registrado y decir que quieres hacer una aplicación. Tiene toda la pinta de ser el hash de algo, pero para el caso nos da igual, puede ser una cadena de texto aleatoria. Yo lo que creo es que simplemente almacenan las keys en una tabla de la base de datos y eso les sirve para validarlas o llevar la cuenta de las peticiones que realizan. Así que nos daría igual que fueran aleatorias. Yo el fallo mas grande que le veo a ese sistema, es que cualquiera puede "robarle" la contraseña a una aplicación y usarla en la suya, ya sea revisando el ejecutable o espiando la comunicación. Pero los de google o flickr tendrán sus razones y yo humilde diletante no les voy a decir como tienen que hacer las cosas

[roman]

Empezado por seoane

Creo recordar que sistemas como el messenger utilizan un sistema de identificación basado en md5 bastante seguro, cuando un cliente se conecta al servidor este le manda un numero aleatorio, entonces el cliente genera el md5 a partir de la contraseña y ese numero. Cuando el servidor recibe el md5, hace lo mismo, utiliza la contraseña original y el numero que genero y también calcula su md5, entonces compara ambos hash. Esto llevado a tu caso puede ser bastante complicado de implementar, y por lo menos implicaría el tener que usar 2 peticiones consecutiva, una para obtener el número aleatorio y otra para mandar la petición con la contraseña cifrada. Bueno, ahí te queda la idea ....

A ver, si yo me pongo a escuchar tu pc e intercepto el md5 que mandas al servidor, ¿qué me impide a mi mandarlo por mi cuenta? Cuando el servidor lo reciba, hará las operaciones que describes y claro que concordarán.

Pero de cualquier forma, no es tanto haber "puesto al descubierto" si el sistema era o no inseguro, eso creo que todos lo tienen más o menos claro. El sistema es tan seguro o inseguro como lo puede ser cualqiera de muchos que hay. Sin ir más lejos, como el del propio ClubDelphi, y ¿ustedes creen que Emlio duerme intranquilo por ello? Claro que no. Porque aunque la autenticación no viaje por un canal seguro, no estamos hablando de una tienda en línea o un banco o el Pentágono. No quiero decir con esto que la seguridad no sea importante para este tipo de proyectos, claro que la es y qué bueno que David haya encontrado y corregido las fallas que menciona, pero no creo que requiera mucho más nivel de seguridad.

Una cosa más: ¿cuál es su problema con los SpinEdit? ¿Qué no vienen incluidos con Delphi?

// Saludos

[[seoane]]

Empezado por roman

A ver, si yo me pongo a escuchar tu pc e intercepto el md5 que mandas al servidor, ¿qué me impide a mi mandarlo por mi cuenta? Cuando el servidor lo reciba, hará las operaciones que describes y claro que concordarán.

En el sistema que describo, si alguien intercepta la comunicación y se hace con el md5, este no le valdrá de nada. Pues si intenta conectarse por su cuenta el numero aleatorio sera diferente y por lo tanto el md5 también. El sistema es seguro para realizar una autenticación, pero los datos se siguen mandando sin cifrar.

Empezado por roman

Pero de cualquier forma, no es tanto haber "puesto al descubierto" si el sistema era o no inseguro, eso creo que todos lo tienen más o menos claro. El sistema es tan seguro o inseguro como lo puede ser cualqiera de muchos que hay.

Estoy de acuerdo, podemos hablar de métodos de seguridad de forma teórica, es un tema muy interesante, pero implementarlos en un proyecto que no va a manejar dinero me parece desproporcionado. Hablamos de "interceptar" comunicaciones como si fuera algo sencillo, y en realidad es bastante complicado, por que alguien habría de tomarse tantas molestias para cambiarnos los enlaces de loturak. En la autenticación aquí en el club delphi se manda la contraseña cifrada una sola vez con md5 por un canal no seguro y, como tu dices, a Emilio no le quita el sueño, ni a nadie le han "robado" la identidad

Empezado por roman

Una cosa más: ¿cuál es su problema con los SpinEdit? ¿Qué no vienen incluidos con Delphi?

Pues al parecer en el turbo delphi no.

[roman]

Empezado por seoane

En el sistema que describo, si alguien intercepta la comunicación y se hace con el md5, este no le valdrá de nada. Pues si intenta conectarse por su cuenta el numero aleatorio sera diferente y por lo tanto el md5 también. El sistema es seguro para realizar una autenticación, pero los datos se siguen mandando sin cifrar.

Perdón, pero sigo sin entender. El número aleatorio se genera cuando se hace la autenticación, es decir cuando se manda el usuario y contraseña. En los subsecuentes accesos es cuando se manda el md5 que se formó con el número aleatorio y la contraseña. Entonces, repito, ¿qué me impide mandar ese md5 desde mi pc?

// Saludos

[[seoane]]

Empezado por roman

Perdón, pero sigo sin entender. El número aleatorio se genera cuando se hace la autenticación, es decir cuando se manda el usuario y contraseña. En los subsecuentes accesos es cuando se manda el md5 que se formó con el número aleatorio y la contraseña. Entonces, repito, ¿qué me impide mandar ese md5 desde mi pc?

// Saludos

No estamos desviando del tema. Pero todo sea para que no te quedes con la duda. En el sistema que describo primero se solicita el numero aleatorio, sin enviar todavía la contraseña, una vez que se tiene el numero es cuando se manda el usuario y la contraseña cifrada en md5.

Adaptándolo a este caso caso, me imagino un sistema parecido a este. Primero enviamos una petición de numero aleatorio indicando nuestro nombre de usuario. Del lado del servidor generamos un numero aleatorio que guardamos en alguna tabla asociándolo a ese nombre de usuario y dándole una vida útil de x peticiones. Una vez el cliente tiene el numero, en la siguientes peticiones mandara la contraseña cifrada con ese numero, el cliente sera el encargado de solicitar un numero nuevo cuando este deje de ser valido. Incluso podemos indicar que el numero solo sea valido para una petición, de esta manera antes de cada petición habría que solicitar un numero nuevo.

[roman]

Empezado por dec

He quedado como un tonto, imagino.

Esto ni pensarlo. Este tipo de discusiones nos sirven a todos. Me parece que sólo se trata de una confusión en cuanto al uso del md5 en la contraseña. No es para proteger el proceso de autenticación, sino para preservar la sesión mientras se navega por el sitio sin que la contraseña quede guardada tal cual en una cookie.

// Saludos

[dec]

Hola,

Empezado por Seoane

Bueno, voy también a opinar yo, no se si para ayudar o para confundir mas Lo primero, si tienes preocupación por la seguridad por que no utilizas simplemente https en vez de http, todo los datos irán cifrados, se acabo el preocuparse de quien esta mirando.

Llevas razón Seoane. Es algo que tengo que mirar con más atención... sobre todo ahora...

Empezado por Seoane

En cuanto a lo de mandar la contraseña cifrada o en claro, el cifrar la contraseña no nos proporciona ninguna seguridad extra, si alguien llega a tener acceso a los datos y puede leer el md5 eso es todo lo que necesita, porque siempre es el mismo, cuando quiera utilizar la api solo tiene que usar el mismo hash no tiene porque conocer la contraseña.

Claro. Justo. Y a esto se refería Mario conque no entendía el MD5 de la contraseña, y lo mismo quería decir Román cuando se dijo que no entendía la preocupación en el API y no en la aplicación... y yo respondí poco menos que con cajas destempladas, y es que el que no sabe es como el que no ve. La virgen.

Bueno. Ahora mismo me dispongo a rectificar lo necesario para que todo quede tal cual en la aplicación: no hay necesidad de hacer que quien utilize el API de Loturak tenga que complicarse con MD5 y demás... así que voy a arreglar eso. Luego ya podremos hablar del "HTTPS" y cómo podríamos utilizarlo, si es que se ve menester...

He quedado como un tonto, imagino.

Pero muchas gracias a todos. De verdad que gracias.