Creando mis propios tokens para asegurar la comunicación con mi API

Navega tus respuestas
1

Tengo una API que se comunica con mi cliente, ahora quiero asegurar esa API para que solo mi cliente pueda usarla. Estoy planeando hacer lo siguiente, ya que no tengo experiencia en esto, he reunido todo esto al leer sobre el tema y necesito consejos, aquí está mi flujo:

  1. Cuando un usuario inicia sesión en / registra, genera un token (por ejemplo: token = userId + date + radomvalue), guarda este token (hash) en un DBtable junto con userId.
  2. Enviar token (hash) al cliente, guardar en las preferencias para su uso posterior.
  3. Al llamar a la API, este token debe enviarse con la solicitud, en el servidor, revisamos nuestra tabla de tokens y vemos si encontramos la combinación de userId + hashedToken, si lo hacemos, se otorga el acceso.

Todas las comunicaciones son SSL, aquí están mis preguntas:

  1. ¿Qué debo hacer con el TTL en mis fichas? Y ¿qué pasa si al final obtengo 3 000 000 de usuarios, eso significa que cada llamada que hago a la API tiene que ver una tabla con 3 000 000 filas, ¿está bien?
  2. Obviamente no puedo hacer que mis puntos finales de inicio de sesión / registro requieran que se pase un token en la solicitud (ya que el cliente todavía no lo ha recibido), ¿está bien dejar estos "abiertos"?
  3. ¿Es correcto enviar sal + contraseña de texto sin formato a la api ya que está protegida por SSL, luego la hash en el lado del servidor?

EDITAR: 4. Pensando más en esto, ¿no podría alguien simplemente tomar su token de acceso del archivo de preferencias y hacer llamadas a mi API desde su propia aplicación, siempre que tienen el punto final y editan lo que quieran en su propio usuario?

Modelo de amenaza: estoy creando un juego. Tengo una base de datos donde guardo clasificación, experiencia, y también qué versión de juego tengo (gratis, sin publicidad, premium). Después de que alguien haga una compra, llamo a endpointService.setVersion("userId", "PREMIUM") ;. Este es el único activo de gran valor para mí, ya que no quiero que la gente edite eso por sí misma. Solo quiero proteger mis puntos finales, pero especialmente ese.

    
pregunta Green_qaue 13.03.2017 - 10:53
fuente

2 respuestas

1

¿Es posible reutilizar un mecanismo de autorización, como OAuth2?

Su cliente obtiene un token de acceso válido en caso de desafío (ID de usuario, secreto) que está firmado criptográficamente. La aplicación de su servidor puede verificar este token y, potencialmente, retirar cualquier reclamación de él; así que no necesitas buscarlo en una base de datos. Incluso si desea buscar algo, debe buscar en las memorias de valor clave / mecanismos de almacenamiento en caché como Redis.

El IdP, un proveedor de identidad, realizará la incorporación (registro / inicio de sesión). Véalo como el sistema que realiza la verificación actual. Responderá un token único al cliente; Codificado y firmado. Siempre que su API se asegure de que este es un token válido (firmado por el individuo correcto), entonces debería ser bueno.

  

¿Está bien enviar sal + contraseña de texto sin formato a api ya que es   SSL-protegido, luego hash en el lado del servidor?

Si ingresa su contraseña del lado del cliente, simplemente sustituye la contraseña. A menos que alguien haga un MiTM (proxy de intercepción, ...), y no registre el cuerpo de la solicitud, ... SSL evitará que escuche intrusos. Si usas la contraseña, o el hash de la contraseña; un atacante que lo captura, también enviaría el hash.

  

... ¿Alguien no podría simplemente tomar sus   Acceda al token desde el archivo de preferencias y realice llamadas a mi API desde   su propia aplicación

Sí, no se puede confiar en todo lo que está en el cliente. Puedes intentar ofuscarlo un poco, pero en esencia, no puedes estar seguro de que fue tu aplicación la que lo envió; y no otro programa (de alguien que se tomó el tiempo y el esfuerzo para realizar ingeniería inversa)

    
respondido por el ndrix 14.03.2017 - 23:05
fuente
0

Como mencionó JosephSible, y aludió en su edición, en su comentario, no controla el punto final del cliente y pueden hacer lo que quieran en su propio sistema. Además, dado que controlan el punto final, SSL no hará nada, ya que solo pueden leer el token de la memoria.

EDITAR:

De acuerdo, acabo de ver la edición de tu modelo de amenaza. Estás haciendo una pregunta diferente de la que creo que pretendes hacer. Mi respuesta anterior responde a su pregunta original de "Cómo construir un sistema al que solo puedan conectarse los clientes autorizados". Eso no es posible. Lo que creo que pretendes preguntar es "¿Cómo evito que los usuarios que no han pagado por las funciones de X las usen en el cliente?" Hay un par de enfoques, algunos más efectivos que otros. La mejor respuesta y la única 100% efectiva es hacer todo del lado del servidor. Hay muchos enfoques diferentes para asegurar al cliente, pero ninguno de ellos es 100% efectivo. Si el usuario puede parchear el binario del cliente o crear el suyo propio, puede sortearlo.

Es posible que desee leer este libro: enlace Habla bastante de cómo se separan los juegos de un punto de vista de seguridad.

    
respondido por el user52472 14.03.2017 - 14:59
fuente

Lea otras preguntas en las etiquetas

¿Se ha implementado HSTS pero no funciona? ¿Cómo sé si la computadora host se enciende o apaga? [cerrado]