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

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

[roman]

Creo que ya voy entendiendo seoane. Visto así parece bastante sólido. Me queda ahora la duda de entonces ¿para qué el https?

// Saludos

[[seoane]]

Empezado por roman

Creo que ya voy entendiendo seoane. Visto así parece bastante sólido. Me queda ahora la duda de entonces ¿para qué el https?

// Saludos

El https es necesario para que todo se comunique encriptado, si bien un método con el que comento nos "asegura" la autenticación, todos los demás datos se transmiten en claro. Volviendo al caso de messenger, cualquiera con un sniffer y el programa adecuado puede leer una conversación de messenger, dentro una red local se entiende, entonces ¿por que proteger tanto la contraseña?, porque mientras que te espíen una conversación puede ser grave, que suplanten tu identidad puede ser mucho peor.

En definitiva https es la mejor solución, la información viaja encriptada a través de la red, atravesando incluso los proxys. Aunque no se la dificultad que supondrá desde el lado del servidor implementar esto, desde el lado del cliente solo supone cambiar un par de parámetros.

[dec]

Hola,

Nota del traductor: este Hilo no ha muerto, sólo está en hibernación, al cuidado de HAL, así que no hay problema.

[[seoane]]

Empezado por dec

Nota del traductor: este Hilo no ha muerto

Espero que no. Ya me parece que el hilo de Al sobre automatización web esta en cuidados intensivos , solo faltaba que se me muriera este también.

Por cierto, estaba trasteando con loturak y me devuelve el siguiente error:

Empezado por loturak

Error: El API de Loturak funciona por el momento sólo en local. Disculpa las molestias, por favor

¿Esta situación es temporal? o va a tardar un tiempo en volver a estar disponible.

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