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

[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,

Seoane, prometo leer con más calma tus últimos mensajes. Román... sí que he quedado como un tonto. Es algo que además es más habitual de lo que quisiera. Me pongo a hablar, a hablar... y no escucho a nadie... ¡y luego resulta que estoy equivocado, confundido, por lo menos! Pero yo a lo mío... a lo mío... muy tonto, sí.

Por el momento he dejado el asunto de manera que la contraseña del usuario nos llegue "en claro", tal y como lo hace en la propia Loturak, es decir, fuera del API de que hablamos. He corregido la "documentación", los métodos oportunos, y he actualizado los ejemplos en consecuencia. Podéis verlo si descargáis el código fuente (v1.0).

No sé. Ahora mismo estoy un poco aturdido. Será que me acabo de despertar, será que la primera ha sido en la frente... no sé porqué será. En todo caso muchas gracias a todos, no me canso de decirlo, porque a las pruebas me remito: si por mí hubiera sido el asunto iría muy mal...

Y lo diré una vez más: he hecho el tonto e incluso me he creído superior de algún modo... Por ejemplo, cuando arriba mencioné a WordPress y hablé de que ahí no se codificaba la contraseña del usuario, que nosotros usábamos MD5... como si estuviéramos inventando algo, siendo, como ha resultado ser, una tontería por nuestra parte...

Bueno. Vale. Voy a ver si me despejo un poco. Seguimos leyéndonos. Gracias otra vez a todos.

[roman]

A ver, aquí estamos bajo el supuesto de que alguien se pone a escuhar la comunicación entre nuestra pc y el servidor, de lo contrario no hay de qué preocuparse.

Vamosa ver, tú le solicitas al servidor un número aleatorio y él te lo manda:

id = 2738582

Este número podria de todas formas verlo quien esté escuchando.

Tu mandas al servidor:

md5(2738582 + pepeloco)

donde pepeloco es tu contraseña. Muy bien, yo intercepto esto y lo mando por mi cuenta. El servidor lo recibe igual que recibiría el tuyo. No veo ventaja. Claro, eso sólo servirá el número de peticiones estipuladas. Bueno, cuando se regenere el número aleatorio, lo vuelvo a escuchar, vamos yo sigo escuchando ¿no?, y lo cambio y se lo mando al servidor. ¿Dónde está la ventaja?

// Saludos

[[seoane]]

Empezado por roman

Muy bien, yo intercepto esto y lo mando por mi cuenta. El servidor lo recibe igual que recibiría el tuyo. No veo ventaja. Claro, eso sólo servirá el número de peticiones estipuladas. Bueno, cuando se regenere el número aleatorio, lo vuelvo a escuchar, vamos yo sigo escuchando ¿no?, y lo cambio y se lo mando al servidor. ¿Dónde está la ventaja?

No es lo mismo "escuchar" que interponerse entre el servidor y el cliente. Tu estas suponiendo que el posible atacante tiene control total sobre la comunicación y puede mandar tanto al cliente como al servidor lo que el quiera e impedir que lleguen los mensajes de uno a otro. En ese caso, la cosa esta difícil y este método no supone ninguna ventaja. Pero en el caso de que solo pueda "escuchar" como es el caso de un sniffer, la cosa cambia. Pongamos que el numero solo es valido para una petición, el cliente pide el numero, cifra la contraseña, y envía la segunda petición con la contraseña cifrada, en ese momento esa contraseña deja de ser valida. Si alguien estuviera curioseando, solo podría obtener la contraseña cifrada, una contraseña que ya no seria valida para usarla una segunda vez.

Empezado por mamcx

Me preocupa eso si lo de MD5 doble. Estas haciendole MD5 asi:

"holamundo".MD5().MD5() ????

Porque si eso es verdad, has minado la seguridad de tu clave y haz reducido la efectividad de la misma. Contrario a lo que uno intuitivamente cree, aplicar multiples encriptaciones a un dato disminuye y no aumenta su seguridad.

¿Por que? Si bien eso es muy cierto para algoritmos de encritptacion que utilizan clave, no creo que sea aplicable a algoritmos de hash. Aunque corrígeme si me equivoco.

En cuanto a lo de usar claves o apikeys, no dudo del beneficio de usar apikey. Pero el nombre de usuario y contraseña sigue siendo necesario para realizar tareas con los enlaces privados. Yo lo veo así, usar un apikey en todas las funciones, de esta manera se puede llevar un control, aunque no sea muy exacto, de quien y como utiliza nuestro servicio. Y cuando se necesite realizar alguna acción que necesite autenticación pedirle al usuario que ingrese su nombre y contraseña. Solo la apikey estaría insertada en el código fuente, la contraseña la tendría que insertar el usuario.

[dec]

Hola,

API-KEY, API-KEY, sentadita me quedé...

Empezado por Seoane

(...) Yo lo veo así, usar un apikey en todas las funciones, de esta manera se puede llevar un control, aunque no sea muy exacto, de quien y como utiliza nuestro servicio.

Es correcto Domingo. Por cierto, ¿qué te pareció el ejemplo "EnlacesUsuario"? ¿Chulo a que sí? ¿eh?

Ahora la piedra queda en el tejado de implementar lo dicho. Cómo proporcionar (¿a quien lo solicite?) una clave para usar el API. Cómo conformar dicha clave (creo que esto sería lo de menos, pero, nada está libre de posibles problemas). Cómo implementar esto en Loturak... un nuevo formulario... un nuevo apartado... utilizar una nueva tabla en la base de datos... va a ver que coger el toro por los cuernos.

Maldita sea... hoy estoy bicho, bicho, bicho.

[mamcx]

Empezado por seoane

¿Por que? Si bien eso es muy cierto para algoritmos de encritptacion que utilizan clave, no creo que sea aplicable a algoritmos de hash. Aunque corrígeme si me equivoco.

mmm... no tengo la razon especifica en este momento y fue algo que aprendi en un foro de Borland de uno de los 2 tipos que hacen herramientas de seguridad para Delphi... y como muchas cosas me gravo el "no es bueno hacer x" y se me borrar los 5 o 6 post donde se explica porque

Algo tiene que ver con el proposito de un hash: Una funcion en un solo sentido que no sea reversable... y que la manera correcta que he leido es usar un "salt" para variar la cosa....