security - ejemplo - ¿Mejores prácticas para generar tokens de OAuth?

oauth2 php

Question

Me doy cuenta de que las especificaciones de OAuth no especifican nada sobre el origen de los códigos ConsumerKey, ConsumerSecret, AccessToken, RequestToken, TokenSecret o Verifier, pero tengo curiosidad por saber si existen prácticas recomendadas para crear tokens significativamente seguros (especialmente Token / Combinaciones secretas).

Como lo veo, hay algunos enfoques para crear los tokens:

1. Solo use bytes aleatorios, almacene en BD asociado al consumidor / usuario
2. Hash algunos datos específicos del usuario / consumidor, almacenar en DB asociado al consumidor / usuario
3. Cifrar datos específicos del usuario / consumidor

Las ventajas de (1) es que la base de datos es la única fuente de información que parece ser la más segura. Sería más difícil ejecutar un ataque contra que (2) o (3).

Los datos reales de Hashing (2) permitirían volver a generar el token a partir de datos supuestamente ya conocidos. Puede que no proporcione ninguna ventaja a (1) ya que necesitaría almacenar / buscar de todos modos. Más CPU intensiva que (1).

Cifrar datos reales (3) permitiría descifrar la información. Esto requeriría menos almacenamiento y posiblemente menos búsquedas que (1) y (2), pero potencialmente menos seguro también.

¿Hay otros enfoques / ventajas / desventajas que deberían considerarse?

EDITAR: otra consideración es que DEBE haber algún tipo de valor aleatorio en los Tokens, ya que debe existir la capacidad de caducar y volver a emitir nuevos tokens, por lo que no debe estar compuesto solo de datos reales.

Seguir en las preguntas :

¿Hay una longitud mínima de token para que sea significativamente segura criptográficamente? Según tengo entendido, Token Secrets más largo crearía firmas más seguras. ¿Es este entendimiento correcto?

¿Hay ventajas al usar una codificación particular sobre otra desde una perspectiva de hash? Por ejemplo, veo muchas API que usan codificaciones hexadecimales (por ejemplo, cadenas GUID). En el algoritmo de firma OAuth, el token se utiliza como una cadena. Con una cadena hexadecimal, el juego de caracteres disponible sería mucho más pequeño (más predecible) que, por ejemplo, con una codificación Base64. Me parece que para dos cadenas de igual longitud, la que tiene el conjunto de caracteres más grande tendría una distribución de hash mejor / más amplia. Esto me parece que mejoraría la seguridad. ¿Es correcta esta suposición?

La especificación OAuth plantea este mismo problema en 11.10 Entropy of Secrets .

Answer 1

¿Qué hay de poner la dirección IP en el token?

Luego, podría en cada solicitud descifrar el token y verificar la dirección IP de la solicitud con la dirección IP del token.

Tal vez ese enfoque sería más seguro contra los ataques generados al azar.

¡Mejor!

Editado: Ok, creo que tal vez no estaba claro enaugh. Mi publicación no fue una pregunta. No intentaré encontrar un artículo en Internet donde leo la implementación con dirección IP y estoy de acuerdo en que si pones la dirección IP en el token, los clientes con direcciones IP dinámicas y conexiones móviles tendrán problemas de token.

Answer 2

OAuth no dice nada sobre token excepto que tiene un secreto asociado a él. Entonces todos los esquemas que mencionaste funcionarían. Nuestro token evolucionó a medida que los sitios crecen. Aquí están las versiones que usamos antes,

1. Nuestro primer token es un BLOB encriptado con nombre de usuario, secreto de token y vencimiento, etc. El problema es que no podemos revocar los tokens sin ningún registro en el host.

2. Así que lo cambiamos para almacenar todo en la base de datos y el token es simplemente un número aleatorio utilizado como la clave de la base de datos. Tiene un índice de nombre de usuario por lo que es fácil enumerar todos los tokens de un usuario y revocarlo.

3. Obtenemos muy pocas actividades de piratería. Con número aleatorio, tenemos que ir a la base de datos para saber si el token es válido. Así que volvimos a BLOB encriptado de nuevo. Esta vez, el token solo contiene el valor cifrado de la clave y la caducidad. Entonces podemos detectar tokens inválidos o caducados sin tener que ir a la base de datos.

Algunos detalles de implementación que pueden ayudarte,

1. Agregue una versión en el token para poder cambiar el formato del token sin romper los existentes. Todos nuestros tokens tienen primer byte como versión.
2. Utilice la versión URL-safe de Base64 para codificar el BLOB para que no tenga que lidiar con los problemas de codificación URL, lo que hace que la depuración sea más difícil con la firma OAuth, ya que puede ver una cadena básica codificada triple.