Autenticación sobre SSL usando hash y salt

Question

Autenticación sobre SSL usando hash y salt

#1 de Josef (1 votos)
#2 de SilverlightFox (1 votos)

1

He investigado este tema exhaustivamente y estoy atascado; esperaba obtener alguna aclaración por parte de la gente útil.

Antecedentes: tengo transpondedores de Bluetooth conectados a bloqueos que se abren mediante pago en mi aplicación. Un usuario paga una tarifa fija, el bloqueo se abre, toma su artículo y la puerta se cierra y se cierra. Estoy tratando de evitar ataques de suplantación de identidad donde los usuarios que no pagan pueden abrir estos bloqueos.

En teoría, mi solución actual es la siguiente: a cada transpondedor se le da una sal aleatoria de 32 bits. Una vez que la aplicación se conecta, se envía una solicitud de autenticación al transpondedor. El transpondedor crea una cadena de desafío aleatoria + su sal única. El transpondedor luego el hash itera la cadena 10,000 veces (para proteger contra la fuerza bruta) usando SHA256.

Mientras esto sucede, la cadena de desafío + sal original también se transmite a la aplicación, que luego la envía a un servidor seguro a través de SSL donde también se encuentran la clave de hash secreta compartida y la sal del transpondedor. La cadena se hash iterado 10.000 veces con Sha256, se envía de vuelta a la aplicación y se vuelve al transpondedor que valida el hash del servidor contra su propio hash calculado. Si es igual, el bloqueo se abre.

Mis preguntas son: ¿es seguro? ¿Estoy pasando por alto un defecto de seguridad evidente, ya sea por fuerza bruta u otra? ¿Estoy completamente equivocado? Cualquier ayuda o recomendación sería muy apreciada

hash salt tls bluetooth

pregunta user3682157 03.08.2016 - 04:53

fuente

2 respuestas

Lea otras preguntas en las etiquetas hash salt tls bluetooth

Correo electrónico informal que incluye un número de cuenta P-Card y fecha de vencimiento. ¿Viola esto a PCI? ¿Esta cadena de letras extraña indica que mi cuenta de Outlook ha sido hackeada?

score 1 · Answer 1

Lo que desea se llama un código de autenticación del mensaje . Hay diferentes maneras de crear uno. Lo que describe es una forma trivial de crear un Hash-MAC, pero tiene algunos fallas de seguridad . Podría estar de acuerdo con eso, si su cadena de desafío tiene una longitud fija y agrega la "sal", que en realidad es la clave, al final. Pero hay una forma bien definida de generar un HMAC y sugeriría que lo use, porque se estudió su seguridad. Para la mayoría de los lenguajes de programación, también hay buenas bibliotecas para crear un HMAC que reduce su trabajo (y las cosas que podría hacer mal).

score 1 · Answer 2

Iterar un hash es una forma de estiramiento de la tecla . Esto generalmente se logra a través de un algoritmo probado como PBKDF2 en lugar de simplemente iterar una función criptográfica de hashing a su manera.

La extensión de la clave de esta manera solo es realmente necesaria si está intentando tomar una contraseña suministrada por el usuario con una posible entropía baja que necesita aumentar artificialmente. Si puede controlar las teclas usted mismo y generar una con una entropía suficientemente alta, no es necesario estirar las teclas.

Para aclarar esto tienes:

App --authentication request--> Transponder

Transponder Authentication Key = 10,000 x sha-256(Challenge String + Transponder 32-bit salt)

Transponder --Challenge String + Transponder 32-bit salt--> App
App --Challenge string + Transponder 32-bit salt--> Server (via SSL)

Server Authentication Key = 10,000 x sha-256(Challenge String + Transponder 32-bit salt)

Server --Server Authentication Key--> App --Server Authentication Key--> Transponder

Transponder: Unlock if Server Authentication Key == Transponder Authentication Key

Espero haberlo hecho correctamente.

Lo único que no tengo claro es shared secret hash key . ¿Es esta la cadena de desafío o alguna otra cosa, ya que no has mencionado este término anteriormente?

Estoy tratando de evitar ataques de suplantación de identidad donde están los usuarios que no pagan. capaz de abrir estos bloqueos.

¿Qué impide que alguien genere su propio cálculo de 10,000 x sha-256(Challenge String + Transponder 32-bit salt) y luego lo envíe de vuelta al transpondedor para que se abra?

Supongo que shared secret hash key está involucrado en algún lugar y lo que realmente estás haciendo en el transpondedor es

Transponder Authentication Key = 10,000 x sha-256(Challenge String + Transponder 32-bit salt + shared secret hash key)

Si esa suposición es correcta, entonces suena como si necesitaras un Código de autenticación de mensaje en lugar de un hash simple con varias rondas. Por ejemplo, un HMAC .

Si la cadena de desafío es de 128 bits y la sal es de 128 bits, esto le daría a cada clave de autenticación 256 bits de entropía, y debe asegurarse de que el shared secret hash key sea al menos de 128 bits. Consulte esta respuesta .

Desde el transpondedor a la aplicación que calcularías

HMAC_SHA256("<shared secret hash key>", "Challenge String + Transponder 32-bit salt")

y Challenge String + Transponder 32-bit salt luego se transmite a la aplicación y luego al servidor, el servidor realiza el mismo cálculo de HMAC y lo devuelve a la aplicación que lo reenvía al transpondedor para su comparación.