Restrinja el acceso a un tipo específico de entidad

0

Quiero crear un servicio web al que solo pueda acceder un tipo específico de entidad: mi propia aplicación móvil. ¿Hay algún método bien aceptado para hacer esto?

Estoy pensando en incrustar un secreto en esta aplicación móvil, pero parece ser susceptible a la ingeniería inversa y se puede detectar fácilmente en la red. Agradecería si alguien me puede sugerir algunas alternativas.

Gracias

    
pregunta Andree 05.09.2013 - 12:45
fuente

1 respuesta

2

La autenticación del certificado SSL del cliente sería algo que podría considerar. En lugar de proporcionar credenciales, su servidor le solicitará que proporcione un certificado (que puede incrustar en su aplicación).

Una pequeña descripción general que obtuve de Wikipedia :

  

El siguiente ejemplo completo muestra cómo se autentica un cliente (en   Además del servidor como arriba) vía TLS usando certificados   Intercambiaron entre ambos compañeros.

     

Fase de negociación:

     
  • Un cliente envía un mensaje de ClientHello que especifica la versión más alta del protocolo TLS que admite, un número aleatorio, una lista de sugerencias sugeridas.   conjuntos de cifrado y métodos de compresión.
  •   
  • El servidor responde con un mensaje de ServerHello, que contiene la versión del protocolo elegido, un número aleatorio, un conjunto de cifrado y   Método de compresión a partir de las opciones ofrecidas por el cliente. los   El servidor también puede enviar un ID de sesión como parte del mensaje para realizar   un apretón de manos reanudado.
  •   
  • El servidor envía su mensaje de certificado (según el paquete de cifrado seleccionado, el servidor puede omitirlo).
  •   
  • El servidor solicita un certificado del cliente, para que la conexión pueda autenticarse mutuamente, utilizando un CertificateRequest
      mensaje.
  •   
  • El servidor envía un mensaje de ServerHelloDone, que indica que se realizó con la negociación de intercambio.
  •   
  • El cliente responde con un mensaje de certificado, que contiene el certificado del cliente.
  •   
  • El cliente envía un mensaje ClientKeyExchange, que puede contener un PreMasterSecret, una clave pública o nada. (De nuevo, esto depende de la
      cifrado seleccionado.) Este PreMasterSecret se encripta usando el comando público
      clave del certificado del servidor.
  •   
  • El cliente envía un mensaje de CertificateVerify, que es una firma sobre los mensajes de intercambio anteriores utilizando los certificados del cliente.   llave privada. Esta firma puede ser verificada mediante el uso del cliente.   Clave pública del certificado. Esto le permite al servidor saber que el cliente
      tiene acceso a la clave privada del certificado y, por lo tanto, posee la
      certificado. El cliente y el servidor luego usan los números aleatorios y
      PreMasterSecret para calcular un secreto común, llamado "maestro
      secreto ". Todos los demás datos clave para esta conexión se derivan de esta
      maestro secreto (y los valores aleatorios generados por el cliente y el servidor),
      que se pasa a través de una función pseudoaleatoria cuidadosamente diseñada.
  •   
  • El cliente ahora envía un registro ChangeCipherSpec, que básicamente le dice al servidor: "Todo lo que le diga a partir de ahora será autenticado
      (y cifrado si el cifrado fue negociado). "The ChangeCipherSpec
      es en sí mismo un protocolo de nivel de registro y tiene tipo 20 y no 22.
      Finalmente, el cliente envía un mensaje finalizado encriptado, que contiene un   hash y MAC en los mensajes de intercambio anteriores.
  •   
  • El servidor intentará descifrar el mensaje finalizado del cliente y verificar el hash y el MAC. Si el descifrado o verificación   falla, el apretón de manos se considera que ha fallado y el   la conexión debe ser demolida.
  •   
  • Finalmente, el servidor envía un ChangeCipherSpec, que le dice al cliente, "Todo lo que le diga a partir de ahora será autenticado (y
      cifrado si el cifrado fue negociado). "El servidor envía su propio servidor.   mensaje terminado encriptado.
  •   
  • El cliente realiza el mismo descifrado y verificación.
  •   

fase de solicitud:

     
  • En este punto, el "apretón de manos" está completo y el protocolo de la aplicación está habilitado, con un tipo de contenido de 23. Mensajes de la aplicación
      El intercambio entre el cliente y el servidor también se cifrará exactamente
      como en su mensaje finalizado.
  •   
    
respondido por el Lucas Kauffman 05.09.2013 - 13:19
fuente

Lea otras preguntas en las etiquetas