¿Existe alguna ventaja al aplicar pbkdf2 a una clave que se usa para generar un MAC?

1

Necesitamos generar URL resistentes a la manipulación indebida para acceder a un servicio, que luego se comparten con el usuario final. Las URL no contienen datos confidenciales, pero debemos asegurarnos de que no se hayan manipulado desde que se generaron. Depende del usuario final mantener estos datos confidenciales.

Parece que un MAC (como HMACSha256) sería apropiado para autenticar las URL. También me gustaría incluir un salt y una marca de tiempo para hacer que la clave MAC sea menos fácil de adivinar, y para que las URL firmadas puedan expirar de forma natural.

Estaba pensando que PBKDF2 podría ser una buena manera de generar la clave MAC, por ejemplo:

pepper = "xyzzy"
importantFullUrl = "https://....."

salt = secureRandomBits(256)
url = importantFullUrl + "&ts=987654321&salt=" + base62(salt)

signingKey = PBKDF2(pepper, salt, 10000 /*iterations*/, 256 /*bits*/)
mac = hmacSha256(url, signingKey)
signedUrl = url + "&sig=" + base62(mac)

Un enfoque alternativo que he visto omite el paso PBKDF2 y simplemente genera el MAC basado en los valores de url y pepper anteriores, es decir:

mac = hmacSha256(url, pepper)

¿Un enfoque ofrece significativamente más beneficios de seguridad sobre el otro? Dadas las URL, se agotará el tiempo después de un período (por ejemplo, de 24 a 48 horas), ¿importa en este caso? ¿Cómo selecciono un recuento de iteraciones adecuado para un tiempo de espera determinado?

Se describe un enfoque en esta pregunta que involucra una contraseña proporcionada por el usuario. Los usuarios de nuestro servicio se autentican mediante un mecanismo diferente y no tienen una contraseña explícitamente. Esto tampoco es para un servicio web, y todas estas URL firmadas se generarán en el lado del servidor y se volverán a comprobar en el lado del servidor.

    
pregunta Jonathan 08.12.2013 - 15:38
fuente

1 respuesta

1

La criptografía solo se debe usar cuando no hay otra opción (SSL / TLS es un buen ejemplo donde se requiere criptografía). Un HMAC siempre presenta la posibilidad del ataque trivial (fuerza bruta). Además, un HMAC también puede ser un desperdicio de esfuerzo de cómputo, en comparación con otras soluciones, como un Nonce criptográfico simple utilizado para hacer referencia a los datos.

PBKDF2 se usa para estirar la entrada de baja entropía, como las contraseñas generadas por humanos, para ser usadas como claves criptográficas. Para que el PBKDF2 sea útil, consumirá un esfuerzo computacional significativo para producir el hash resultante. Una aplicación que expone este tipo de funcionalidad es vulnerable a un Ataque de Complejidad Algorítmica (ACA), y esta sería una vulnerabilidad muy seria si se tratara de un software finito, porque los ataques DoS causan daños monetarios.

PBKDF2 es útil, especialmente para las contraseñas, sin embargo, al exponer esta función a un atacante sin ningún tipo de limitación de velocidad, crea una posible condición de DoS. SHA256 está bien para su uso como HMAC, de hecho, SHA1 sería una mejor opción para una aplicación web porque es más rápido y los ataques de prefijo contra SHA1 no debilitan el HMAC resultante. La clave secreta es lo que es importante, y aún tiene que preocuparse por los ataques de fuerza bruta sin conexión. Pero eso puede solucionarse haciendo que la clave secreta tenga una longitud de 128 bytes, que resuelve ese problema para la vida de nuestro sistema solar (¡con algo de comodidad!).

    
respondido por el rook 08.12.2013 - 19:11
fuente

Lea otras preguntas en las etiquetas