manejo de sesion en web service

Hola a todos, actualmente estoy desarrollando una aplicación con webservise y sus recpectivos clientes para pc y android puesto que la aplicación tiene muchos usuarios y esta en internet debo implementar un tipo de sesiones para que los métodos no puedan ser invocados por cualquiera con malas intenciones.

Actualmente tengo un método login que recibe como parámetros el email y un password, si el email y la contraseña son correctos devuelve un token de sesion (es una cadena de 30 caracteres en base64) y el id de del usuario en la base de datos , de ahí en adelante cada vez que voy a invocar un metodo debo enviarle el token de sesion y el id del usuario para verificar que la sesion sea correcta; cada token de sesion tiene una duracion de 2 horas y esta vinculado a la direccion ip desde la cual se inicio sesion.

Cren que este sistema de autenticación sea suficientemente seguro puesto por estos web servise se transporta información algo importante

Por favor les agradezco sus ideas y comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de Fonseca

Yo utilizo algo muy similar y me ha funcionado...

Pues yo hace tiempo desarrolle un webservice con un una autenticación muy similar, ya tiene un poco mas de 6 meses en Internet funcionando y nunca hemos tenido problemas de seguridad, la única variación es que utilizamos un api_key para cada usuario que es una cadena de 50 caracteres generada por un algoritmo que nosotros mismos desarrollamos, la cual utilizamos a la par del token.

Imagen de ezamudio

Depende...

Si utilizas SSL, pues sí funciona el esquema que dices; es mejor a que estén enviando el usuario y password en cada petición porque aminoras la posiblidad de un ataque de texto conocido (que consiste en interceptar varias peticiones del mismo origen, asumir que hay muchos datos repetidos ahí y con eso tratar de encontrar un patrón en los datos cifrados hasta poder descifrar algo valioso).

Si no utilizas SSL, tu esquema no sirve de nada. Si intercepto la comunicación entre el cliente y el servicio, no importa que no estén mandando ya usuario y password, porque el token es el mismo y tiene una duración de 2 horas, de modo que puedo falsificar peticiones con ese token. Es decir, tu esquema (probablemente) es susceptible de ataques de reproducción; si intercepto una petición legítima y la reenvío sin modificar absolutamente nada, se procesa de nuevo?

Si no hay SSL y no tienes la posibilidad de habilitarlo, lo mejor que puedes hacer es usar algún mecanismo de HMAC. Es decir, no envías password nunca, pero es un secreto compartido (algo que el cliente y el servidor conocen), y se puede usar para generar un código único para cada mensaje. El servicio debe además exigir que algún dato sea único en cada petición, para evitar los ataques de reproducción. Por ejemplo:

Si la petición contiene datos ID, fecha (incluyendo milisegundos), usuario, código de producto, monto, entonces generas un HMAC usando esos 5 datos y el password del usuario. Esto se debe hacer en el cliente, y enviar el HMAC como sexto dato en la petición. El servidor primero verifica que ese usuario no haya enviado una petición anterior con el mismo ID y/o fecha, y luego procede a recalcular el HMAC concatenando los datos y usando el password del usuario (por supuesto en el server el pasword del usuario no debe estar almacenado en claro sino un hash SHA-1 o MD5, etc y el cliente deberá primero procesar su password de esa forma para que lleguen al mismo resultado cuando tienen los mismos datos). Si el HMAC calculado en el servidor coincide con el dato recibido, la petición se considera válida y se procesa.

Si alguien intercepta esa petición, no le sirve de nada porque si la reenvía así como está sin cambiar nada, el servidor la rechaza porque detecta que está repetida, y si le modifica cualquier dato, el HMAC ya no es válido, y le falta un dato (el password del usuario) para poder generar un HMAC válido.

Fonseca: El hecho de que no hayas tenido un problema de seguridad (o que no lo hayas detectado aun) no significa que todo esté funcionando bien. Y eso de "una cadena de 50 caracteres generada por un algoritmo que nosotros mismos desarrollamos", es un foco rojo. Si ya están usando un token de HMAC, esa "api_key" sale sobrando. Pero a fin de cuentas, ese algoritmo, si es algo que usan en vez de un algoritmo conocido de digestión (SHA-1, SHA-256, MD5, etc) o incluso en vez de un algoritmo de cifrado como AES, seguramente ese api_key es el eslabón más débil en tu cadena de seguridad. Siempre es recomendable utilizar algoritmos conocidos, no inventarse uno propio, porque los algoritmos conocidos ya han sido estudiados y analizados y atacados por un montón de gente que sí conoce a fondo el tema, en contraste con un algoritmo que te inventas en una semana y piensas que el resultado se ve difícil de romper y no sabes si tiene alguna debilidad que un atacante puede encontrar muy fácilmente.

Imagen de Fonseca

creo que tienes razon...

Orale... no lo habia visto desde ese punto de vista... gracias por la observación... creo que procederé a cambiar esa parte de mi webservice... Gracias...

Gracias por la respuesta

Gracias por sus respuestas en el servidor si tengo la posibilidad de usar SSL de hecho es algo que según mi opinión debería ser obligatorio en todas las aplicaciones