Asegurar la comunicación

2

El problema:

Tengo un cliente de código abierto (un complemento de Firefox escrito en JavaScript) y un servidor que contiene información de usuario bastante sensible: nombre de usuario e historial de usuario (todo desde YouTube). El cliente puede agregar nuevas entradas al historial y consultar el historial completo (indicando su nombre de usuario). La comunicación está en el protocolo HTTP. El problema es que no hay ninguna contraseña o autenticación. Esto significa que nadie puede fingir ser alguien, creando solicitudes HTTP falsas, con datos GET modificados y recuperando el historial completo de otro usuario.

¿Cómo puedo generar una contraseña (o hash) que no se puede adivinar, pero se puede usar para autenticar al cliente?

Posibles soluciones (o lo que ya he pensado / probado)

1. Cree un sistema de registro para este servicio

Podría agregar un formulario de registro y un formulario de inicio de sesión, y asociar al usuario del servicio con el usuario de YouTube con algún tipo de verificación, pero eso es demasiado complicado para el usuario. Realmente es solo un servicio básico, por lo que esto sería una exageración.

2. Haz que sea de código cerrado

Los complementos de Firefox no son necesariamente de código abierto. Al hacerla de código cerrado, podría hacer un truco simple como crear una función de hash de costum (o simplemente una sal de costum para el hash) que está oculta por la fuente cerrada. De esta manera generaría una contraseña directamente desde el nombre de usuario. Aquí hay dos opciones:

a.) Créelo como un componente XPCOM de C ++. Lo intenté. Pero resulta que esto también es una exageración. Es muy incompatible con las versiones de gecko y ni siquiera tengo que compilarlo en las plataformas. Es realmente difícil de depurar, casi no hay soporte y lo más importante: no me gusta la idea de mantener una pieza binaria compilada para cada versión de Firefox para cada plataforma solo por tener 5 líneas de código encapsuladas en una interfaz de 300 líneas . Además, ¿qué sucede si decido migrar este complemento para Chrome? No hay tal cosa como XP-COM.

b.) Conviértalo en un JavaScript confuso. No sé cómo escribir código JS que es difícil de descifrar. También es mucho más fácil copiar el código ofuscado, cambiar el parámetro inicial y tener el hash para el nombre de usuario deseado. Con el componente XPCOM es tan difícil trabajar, así que aísle y ejecútelo con un nombre de usuario falso, que casi lo considero una seguridad aceptable: D.

3.) Obtenga la contraseña de YouTube

Si pudiera obtener un código de YouTube, con la misma facilidad obtendré el nombre de usuario (obtener una página ficticia en segundo plano y obtener el nombre de usuario del código fuente). Pero no puedo. No hay forma de que pueda obtener la contraseña real, tal vez si está guardada, podría hacerlo de esa manera, pero no puedo basarme en eso. Bueno, no necesito la contraseña real de todos modos, todo está bien siempre que sea un secreto, es exclusivo del usuario y constante por el usuario (cada usuario tiene uno y solo uno, disponible en cualquier momento).

a.) Busqué el código fuente de YouTube y los parámetros del reproductor integrado y encontré algo, pero no era secreto. Estaba en algún lugar del perfil y podía ver los códigos de otros usuarios. Así que esto significa: no encontré nada.

b.) También revisé las cookies. Pero después de volver a iniciar sesión no hubo ningún valor de cookie que no haya cambiado su valor. No es que yo pudiera entender qué cookie hace qué.

Descripción general

El problema con todo esto es que ... son muy poco profesionales. Publiqué esta pregunta con la esperanza de algún método genial inventado para escenarios como este. Un apretón de manos o algo así.

Necesito esto porque tengo que escribir un Términos de servicio para mi complemento. Y no puedo simplemente escribir que estoy guardando su historial en un servidor externo para el beneficio de que puede usar mi complemento en muchas computadoras sin ningún tipo de seguridad , que cualquiera que descargue Fiddler, y sabe qué es el protocolo HTTP, simplemente puede ver qué videos ha visto.

Lo siento, la pregunta es tan larga y lo siento si está fuera del tema (espero que no sea así).

    
pregunta Máthé Endre-Botond 02.04.2012 - 05:04
fuente

1 respuesta

4

No hay forma de implementar esto de tal manera que sea manejable y tenga una seguridad efectiva. El hecho de que tenga que usar HTTP (y, por lo tanto, no HTTPS) hace que sea muy, muy difícil proteger el sistema contra los ataques MITM / replay. Generar un hash determinisitically a partir del nombre de usuario directamente no ayuda realmente, no resuelve el problema MITM y expone al sistema a ataques de fuerza bruta.

Usted podría simplemente generar un valor aleatorio, almacenarlo en una cookie de larga duración y usarlo como identificador de sesión (en realidad, como sustituto de una contraseña), coincidiendo con un nombre de usuario en el primer acceso. Esto aún será vulnerable a XSS y MITM. pero luego tienes el problema adicional de cómo restablecer la contraseña de los usuarios.

No puede obtener la contraseña de la cuenta de youtube de youtube, pero puede obtenerla del usuario junto con el nombre de usuario de youtube y probar su validez.

Creo que podría hacerlo mucho peor de lo que se hace aquí: usar un ID de sesión de larga duración, autenticado contra openid o un servicio específico de la aplicación. (Pero tenga en cuenta que esto no es totalmente seguro).

    
respondido por el symcbean 02.04.2012 - 16:01
fuente

Lea otras preguntas en las etiquetas