Diseño de autentificación API y hackability

Question

Pregunta: ¿Es esta técnica de autenticación API fácilmente pirateable?

apiKey = "123456789" 
apiCallId = "1256341451" 
apiSecret = "67d48e91ab2b7471d4be2a8c2e007d13" 
sig = md5(apiKey + apiCallId + apiSecret) = 09c297a354219f173bfc49c2e203ce03 

donde

• apiKey: algún identificador único para el usuario
• apiCallId: un número entero único que debe ser aumentado en valor (por ejemplo UNIX sello de tiempo)
• apiSecret: cadena conocidos solamente para el usuario, y para nosotros, no pasó en la URL
• sig: firma "no apta" de esta llamada API - MD5 hash

Ejemplo llamada a la API:

http://api.domain.com/?apiKey=123456789&apiCallId=1256341451&sig=09c297a354219f173bfc49c2e203ce03&param1=x&param2=y 

Esta API no requiere una sesión, y no está diseñado para una tercera parte use en nombre de un usuario. En cambio, debe ser utilizado por el usuario.

Me gusta mucho la simplicidad de esto. El requisito de que apiCallId sea único y siempre aumenta significa que no es posible reutilizar un sig, por lo que me siento seguro (protegido contra ataques de repetición), pero no soy un experto.

Otras API utilizan todos los parámetros GET ordenados alfabéticamente al calcular el sig, pero no veo por qué es necesario cuando se incluye apiCallId.

Intente hackear esto ahora antes de implementarlo y liberarlo.

Agradezco cualquier comentario, sugerencia y educación de seguridad.

Answer 1

Lo que está haciendo parece razonablemente sensato, excepto que no verifica los parámetros (que será un problema bastante grande).

Algo que es muy similar a su diseño que podría ser conveniente para copiar es el Amazon Web Services Request Authentication Scheme

En particular Asegúrese de que el esquema de codificación de los parámetros no es ambigua e invertible; Amazon screwed this up en un punto. Aprende de sus errores :)

Criptográficamente hablando, lo que está haciendo no se llama una firma sino un código de autenticación de mensaje (MAC). Un MAC puede ser creado y verificado por cualquiera que comparta la clave secreta (el término 'firma' normalmente se reserva para esquemas de claves públicas como DSA o RSA). MD5 (msg || K) es un MAC conocido y razonablemente sano; No estoy seguro si te lo perdiste por accidente o intencionalmente, pero un método que parece en la superficie ser equivalente, MD5 (K || msg), es bastante inseguro, porque es una rareza en cómo MD5 (y la mayoría de los demás hash funciones) están diseñados significa que si conoce H (m) puede calcular fácilmente H (m || m2) para cualquier m2, por lo que si estaba usando MD5 (K || param1 = 5), alguien podría sacar esto del cable y luego crea MD5 (K || param1 = 5, param2 = 666). (Tal vez sea un poco más técnico de lo que le interesa, pero esto se llama length extension property).

Sin embargo, mientras que MD5 (K || msg) es probablemente "bueno", es mejor usar algo como HMAC, porque en realidad fue diseñado como un MAC. MD5 tiene muchos problemas pero nada afecta directamente su uso como MAC (aún - MD4 se ha roto de esta manera). Por lo tanto, en el futuro (a prueba de auditoría) utilice HMAC con SHA-1 o SHA-256. Incluso si no desea extraer una biblioteca criptográfica, HMAC es bastante simple y hay valores conocidos disponibles para SHA-1 y SHA-2 para que pueda verificar su código.

Answer 2

Bueno, supongamos que conozco el secreto, entonces podría generar el sig y pasarlo. Lo que estaba haciendo para una de mis startups es llevar aún más el sig param al hacer que sig dependa de los otros parámetros y también un requestID (UUID) y la marca de tiempo y almacenar ese UUID (razones de seguridad por un par de horas para negar al hacker llamando a la misma función una y otra vez). De esta manera no puedes volver a llamar a la misma llamada, deberías generar un nuevo UUID y si el hacker reemplaza el UUID en el param el sig lo invalida, y él no sabe cómo generar el sig porque, aparte de secreto, somos también genera una firma basada en una clave interna que tiene 30 caracteres de longitud. Así essenity

MD5 (Lista alfabética de los Parámetros + apikey + CallID + Secert + someLonginternalKey)

No estoy seguro si respondido a su pregunta, pero esa es otra forma de hacer la seguridad de API

Answer 3

No. La integridad de los otros parámetros (param1 y param2 en su ejemplo) no está protegida. Un atacante puede interceptar la llamada y modificarla como quiera antes de reenviarla. El apiCallId solo evita las repeticiones, no la alteración de la primera llamada.

No soy un experto. Si lo vi de inmediato, probablemente haya otros problemas al acecho.

Answer 4

Sugiero usar firmas digitales en este caso, ya que son más apropiadas. Una firma digital sobre, por ejemplo, el apikey es más que suficiente. Ni siquiera necesitas el apisecret y el hash de eso. Solo debe asegurarse de que la firma digital se mantenga privada (al igual que el hash md5).

Si desea evitar el ataque de repetición, necesita algún tipo de aleatoriedad en cada solicitud. Así que le sugiero lo siguiente:

servidor -> API: Nonce (= un número aleatorio)

API -> Servidor: Enc (nonce + firma digital)

esta es encriptada con la clave pública del servidor y la firma digital se coloca con la clave privada del servidor.

Ahora no puede tener un ataque de repetición. Sin embargo, todavía existe el problema de un hombre en el ataque al medio, pero arreglarlo no es tan trivial (pero sí factible). Entonces, dependiendo del nivel de seguridad que desee/necesite, puede adaptar sus medidas técnicas.