2010-12-01 11 views
5

Estoy trabajando en una aplicación WP7. Esta aplicación WP7 interactuará con algunos servicios web que he creado. No quiero que otras aplicaciones interactúen con estos servicios web. La razón es porque no quiero que roben mis datos. Con esto en mente, aquí es lo que estoy haciendo actualmente:Interacción segura/autenticada desde una aplicación WP7

  • Conexión a servicios web a través de HTTPS
  • Haciendo mi conexión de los usuarios inicialmente para la aplicación
  • Pasando los usuarios nombre de usuario/contraseña con cada servicio Web interacción

En este momento, no veo qué impide a un desarrollador malintencionado crear un combo de nombre de usuario/contraseña y usar esa cuenta en su aplicación para interactuar con mis servicios web. ¿Cómo realmente bloqueo esta cosa?

Gracias!

Respuesta

0

Puede introducir una función de "Id. De aplicación autorizada" en la que la aplicación envía su nombre o identificador dentro de cada cuerpo de solicitud HTTP. Luego, en el lado del servidor, puede verificar la identidad de la aplicación (por ejemplo, almacenar los ID de la aplicación autorizada en una tabla). La identificación de la aplicación se encriptaría dentro del cuerpo de HTTP (S).

Esto también le daría la opción de enviar nuevos ID de aplicación en versiones actualizadas de la aplicación WP7 si desea deshacerse de una ID de aplicación anterior. También podría admitir nuevas aplicaciones en diferentes dispositivos o plataformas en el futuro.

+0

El problema es si alguien decidió descargar el archivo .xap. Todavía podían ver la ID de la aplicación. Incluso la ofuscación no es perfecta. Tiene que haber alguna forma de abordar esto. – user462166

+0

Buen punto. Gracias. – kindohm

1

Como inicio de un sistema más seguro, debe dejar de almacenar la contraseña y enviarla por el cable con cada solicitud (incluso si está utilizando SSL).

Si debe pasarlo con cada solicitud, almacene un hash salado de la contraseña y utilícelo en su lugar.

1

estoy usando un enfoque de múltiples capas a este problema. Recomiendo pensar creativamente y utilizar una variedad de métodos para validar que las solicitudes provengan de dispositivos de los que espera que provengan las solicitudes.

Alternativamente, si hay algún mérito en su escenario, abra su API a desarrolladores de terceros y hágala funcionar para lograr sus objetivos.

1

Si decide guardar una clave en su aplicación, no almacene texto RAW sino que declare una matriz de bytes de los valores UTF8, esto no será tan fácil de leer.

Puede agitar la mano con su servicio utilizando un hash salado de la tecla la primera vez que se ejecuta la aplicación, el servicio le entrega otra tecla para que el dispositivo la use en el día a día.

El teléfono debe tener una hora casi precisa, por lo que puede volver a calcular la clave cada día u hora. También puede revocar la clave en el extremo del servidor para ese dispositivo.

Esta API será útil para garantizar que pueda poner en la lista negra un dispositivo de forma permanente.

DeviceExtendedProperties.GetValue ("DeviceUniqueId").ToByte();

No he investigado el cifrado simétrico porque es posible que incluso pueda usar el ID único anterior como clave privada.

Creo que la clave del éxito es ese primer apretón de manos, y garantizar que no se fisgonee. Si se trata de un sistema realmente importante, entonces no use ninguna de estas ideas, ya que rodar su propio cifrado siempre es endeble para cualquier persona con intenciones serias: use métodos bien conocidos y lea.

Luke

Cuestiones relacionadas