Cómo proteger la API (clave privada) para aplicaciones móviles

Navega tus respuestas
9

Estoy creando un servicio web que solo debe ser accesible para las aplicaciones de iOS. En el futuro, quiero expandirme a un sitio web móvil para que mi servicio también esté disponible para otros sistemas operativos móviles.

Ahora, tengo todo trabajando a través de una API. mis usuarios pueden registrarse, buscar compañías, ordenar productos de esas compañías y rastrear sus pedidos. Aún no está activo, pero está funcionando ...

Estoy enfrentando un problema importante: ¿cómo asegurar esto?

Durante los últimos días he dejado de programar y siempre he estado ocupado buscando en la web, StackOverflow y Seguridad de la información para saber cómo hacer esto. Descubrí que la forma en que Amazon asegura su API sería la mejor solución para mí. La manera en que Amazon asegura su servicio se explica aquí . Lo he ajustado un poco para mi servicio:

  1. El usuario se registra y obtiene la clave privada de la API + la clave pública (identificación)
  2. El usuario ingresa las credenciales y pulsa "iniciar sesión". La aplicación crea un hash de las variables + clave privada. La aplicación envía variables + marca de tiempo + hash + clave pública a API
  3. La API busca la clave pública en la base de datos, encuentra la clave privada que pertenece a esa clave pública (si la clave pública es válida). La API crea el hash de la misma manera que la aplicación. Si los hashes son los mismos, se ejecuta la solicitud (inicie sesión en este caso).

Esta forma de asegurar un servicio tiene sentido para mí, y puedo codificar la mayor parte del mismo. pero tengo un problema importante y no puedo encontrarle ninguna solución:

  • El usuario obtiene un mensaje público & Clave de API privada cuando se crea una cuenta. La clave pública se puede enviar desde el servidor al dispositivo del usuario, ya que no es necesariamente un secreto. Dado que la clave de la API privada puede nunca enviarse por cable, cómo puedo asegurarme de que una cuenta registrada en el dispositivo de un usuario conozca la API privada clave que se crea en el servidor?

¿Alguien sabe cómo resolver este problema? Cualquier ayuda sería muy apreciada !!

    
pregunta Joris416 09.12.2013 - 14:15
fuente

2 respuestas

1

¿Por qué quieres que los clientes tengan sus propias claves privadas? Estoy tratando de entender cómo se supone que funciona tu escenario, pero estoy un poco confundido acerca de lo que estás tratando de lograr.

En general, aquí hay un par de comentarios que pueden ayudar:

  1. HTTPS es cómo puede establecer un canal de comunicación seguro con los clientes. Una vez que haga esto, puede transferir lo que desee de forma segura a través del cliente de conexión < - > servidor. Esto es lo mismo que hace su banco.

  2. El artículo al que se vincula no dice nada sobre HTTPS, parece que tienen la intención de enviarlo a través de HTTP. Debe usar HTTPS no HTTP para cualquier cosa que no quiera que se vea comprometida (como un usuario registrado). ¿Por qué tratar de crear su propio mecanismo de encriptación cuando puede usar HTTPS? El uso de HTTP para cualquier tipo de autenticación me parece un consejo terrible.

  3. No estoy seguro de que sus clientes realmente necesiten su propio par de claves pública / privada. Normalmente, es un servidor que protege la comunicación de su aplicación y que tiene un certificado con clave privada. Los clientes seguirán teniendo un nombre de usuario y contraseña, ¿verdad? Esa es la autenticación para su cliente (no un certificado) y usted puede enviar el usuario / pase al servidor una vez que haya establecido un canal seguro HTTPS. En el lado del servidor, su aplicación verificará que las credenciales de inicio de sesión del cliente sean válidas y le dará al cliente una forma de decir "Ya estoy autenticado durante 30 minutos" a través de un mecanismo de sesión o cookie. Obviamente, una vez que un cliente ha iniciado sesión, la comunicación debe continuar a través de HTTPS o su token / sesión de autenticación podría ser robada.

En pocas palabras, si solo está tratando de asegurar la comunicación entre los clientes y un servidor, use HTTPS y no vuelva a inventar la rueda.

    
respondido por el AckSynFool 06.06.2014 - 14:01
fuente
0

Sí, hay una solución. Crear las claves públicas y privadas en el lado del cliente. Entonces solo se necesita transmitir la clave pública del cliente, desde el cliente al servidor. El servidor tiene su propio par de claves públicas y privadas, de las cuales solo comparte la clave pública.

El esquema que describe no debe requerir que ambas partes tengan copias de la clave pública y privada. Usted describió un esquema de comunicación simétrico, donde los datos transmitidos hacia y desde el servidor se cifran con el mismo par de claves pública-privada, y ambas partes requieren las claves pública y privada.

La solución es introducir algo de asimetría. El cliente debe tener la clave pública del servidor. El servidor debe tener la clave pública del cliente. Cada uno debe tener su propia clave privada. Si desea, el servidor puede usar las mismas claves para todos los clientes, o puede generar nuevas claves de servidor para cada cliente. En cualquier caso, no es necesario compartir las claves privadas.

Buena suerte con tu implementación. ¡Publica un comentario para avisarnos si funciona!

    
respondido por el Brent Kirkpatrick 29.03.2016 - 15:27
fuente

Lea otras preguntas en las etiquetas

Riesgos de seguridad de BD + Pin requerido para acceder a la ranura de autenticación de tarjeta (tarjeta inteligente)