Estamos trabajando en un nuevo proyecto, somos dos desarrolladores principales y nos encontramos en una encrucijada sobre cómo usar un token para asegurar la comunicación entre el servidor y el cliente.

Primera sugerencia: (el token de una sola vez Token estático)

1. el cliente solicita un token primario, enviando el nombre de usuario y la contraseña y el tiempo actual (esta variable se guardará en la base de datos del servidor y también en el lado del cliente) a la API, el servidor interpreta la entrada y genera un token hash (por ejemplo: 58f52c075aca5d3e07869598c4d66648) lo guarda en la base de datos y lo devuelve al cliente.

2. El cliente ahora guarda el token primario y crea un nuevo token hash usando el token primario + la variable current_time enviada en la solicitud de autenticación (llamemos a este nuevo token, main_token) también el servidor hace lo mismo y crea el mismo token usando el mismo algoritmo .

3. Cada vez que el cliente consulta la API del servidor, envía el token main_token al servidor, ahora el servidor compara el token generado en él, con el token main_token enviado por el cliente, si coincide, significa que el usuario es real

Segunda sugerencia: (Token dinámico)

1. El cliente genera dos claves aleatorias ($ key1 = rand (10000,90000); $ key2 = rand (10000,90000);) En cada solicitud en la API, el cliente crea un hash utilizando el tipo de consulta, y las dos claves con un algoritmo complejo, y envía estas dos claves + el hash al servidor

2. El servidor, usando el mismo Algoritmo usado en el cliente, crea un hash, y se compara con el enviado por el cliente, si coincide, el servidor procede a atender la consulta.

Ahora, la pregunta es: ¿Cuál es la forma más lógica y segura de usar para proteger las solicitudes de API?

Realmente me gusta el primer enfoque en general.

• es simple de entender e implementar
• es seguro (que yo sepa)
• Es un enfoque común que he visto en el pasado

Una cosa que no veo mencionada sobre el primero que debe tener en cuenta, la marca de tiempo utilizada para codificar el token debe tener una caducidad TTL que sea extremadamente corta (como 1 segundo) para que verifique que el mensaje no se envió con el misma marca de tiempo y token de un mensaje 12 horas antes; obviamente se calcularía como legítimo pero no lo es en este caso.

Si estas son las dos únicas opciones que está considerando, me gustaría asegurarme de que también haya analizado otros enfoques, ya que hay muchos. Más de lo que voy a enumerar, de hecho. Estos son algunos enfoques de autenticación comunes que vale la pena estudiar solo para ver si se ajustan mejor a su propósito, y si nada más entenderlos puede darle algunas ideas para ayudar a ajustar cualquier enfoque que elija.

Tenga en cuenta que no soy un experto en seguridad.

OAuth / Federated

En este enfoque, usted tiene un garante de terceros donde el código consumidor solicita el token / cert / qué tiene de ellos y se lo pasa a usted, en este punto, todo lo que necesita hacer es preguntarle a la tercera parte si la clave que le dieron es legítimo

Pro:

• Basados ​​en estándares
• Otros encontrarán problemas en los sistemas de otras personas para que descubras si ocurre la inseguridad
• Necesitará mucho menos trabajo de autenticación

Estafa:

• Debe tratar con un administrador de terceros y su API, o crear y alojar su propio "tercero" para segregar la autenticación de su servicio principal.
• Para muchos servicios exagerados, pero conceptualmente vale la pena considerar

Certificados asincrónicos

Aquí haría que sus clientes encripten sus comunicaciones con un certificado público que haya compartido con ellos cuando crearon un usuario. Por su parte, descifraría utilizando la clave privada asociada con su usuario. En general, iniciaría la comunicación con una respuesta de desafío para mostrar que pueden cifrar / descifrar como espera identificarlos como quienes dicen ser. Aunque son posibles enfoques "sincrónicos" que no utilizan la respuesta al desafío, tienen un poco menos de seguridad y algunos problemas de sincronización de tiempo que pueden hacerlos más complicados.

de Novell (sí, lo sé, ¿ Novell ? ¿En serio?)

Los tokens usan una variable como base para generar la contraseña de un solo uso. Esta variable se llama el desafío. Los dos métodos principales para determinar la variable utilizada para generar la contraseña son asíncronos o síncronos.

Con el método asíncrono o desafío-respuesta, el software del servidor envía al token un desafío externo, una variable generada aleatoriamente, para que el dispositivo del token lo cifre. El token utiliza esta variable de desafío, el algoritmo de cifrado y el secreto compartido para generar la respuesta: la contraseña correctamente cifrada.

Con el método sincrónico, el token y el servidor determinan internamente la variable de desafío utilizada para generar la contraseña. Una combinación de contador de tiempo, contador de eventos o contador de tiempo y eventos dentro de cada dispositivo se utiliza como base para la variable de desafío. Debido a que el token y el servidor determinan de forma separada e interna la variable de desafío de sus propios contadores, es muy importante que sus contadores de tiempo y los contadores de eventos permanezcan sincronizados. Debido a que es muy fácil que el servidor y el token se desincronicen, la mayoría de las implementaciones permiten cierta cantidad de deriva entre los contadores. Por lo general, se utiliza un pequeño rango o ventana de estos valores de contador para calcular la contraseña. Sin embargo, si el token y el servidor no se sincronizan más allá de esta ventana,

Pro:

• Los certificados tienen raíces CA que los hacen confiables y difíciles de falsificar.
• Existen instalaciones estándar en los sistemas operativos para administrar y mantener las tiendas de certificados fácilmente
• Enfoque bien estudiado, mucha información disponible al respecto
• El vencimiento junto con una variedad de otras cosas son instalaciones incorporadas de certificados estándar, generalmente son robustas

Estafa:

• Los certificados pueden ser difíciles de trabajar mediante programación
• Dependiendo de si necesita una CA externa, puede no ser gratis
• Es posible que necesite mantener almacenes de certificados manualmente para garantizar que se configuren las confianzas raíz esperadas

NTLM

No se ría, si este es un servicio más pequeño o solo interno y está en un entorno Windows, no hay nada de malo en usar la autenticación NTLM estándar para garantizar el acceso. Especialmente si está trabajando con IIS, este es sin duda el enfoque más simple. Fácil de mantener y configurar también en un web.config.

Pro:

• Extremadamente fácil de configurar, implementar y mantener

Estafa:

• Interoperabilidad mínima
• No es suficiente para la autenticación pública

Nonces

Cuando trabaja con nonces en su enfoque de autenticación, proporciona un método para obtener un nonce en el servicio. Este método devuelve una cadena o pieza de datos arbitraria única ("un nonce") en cada solicitud. Cada solicitud a otros métodos ahora requiere que se recupere un nonce y se use en el algoritmo criptográfico para la solicitud. El valor aquí es que el servidor realiza un seguimiento de los nonces utilizados, y nunca permite la reutilización de un nonce, esto evita completamente los ataques de repetición porque una vez que se realiza una solicitud con un nonce, una solicitud con ese nonce nunca se puede volver a hacer. A medida que se solicitan nonces, se agregan a una lista de nonces disponibles, a medida que se usan se mueven de la lista disponible a la lista usada.

Pro:

• Frustra los ataques de repetición bastante bien
• No del todo difícil de implementar o entender

Estafa:

• Requiere que los clientes realicen dos solicitudes para cada solicitud (aunque puede reducirse al requerir nonces solo para ciertas solicitudes)
• Requiere la gestión de nonces, que debe ser transaccional
• Afecta negativamente el rendimiento al requerir las solicitudes adicionales de nonces (la transaccionalidad aumenta aún más el costo de los recursos de trabajar con nonces)