¿Existen vulnerabilidades con este mecanismo de autenticación?

  

Estoy tratando de encontrar una manera de implementar la autenticación basada en token para una API REST sin la necesidad de SSL.

¡No!

Use SSL (bueno, TLS en realidad).

  

nada que no sea público ya está pasando por alto

Esto obviamente no es exacto:

• se captura el nombre de usuario; TLS ocultaría el nombre de usuario (no estoy diciendo que sea un error grave, pero es una información que se divulga);
• se captura un hash basado en la información disponible y ahora se pueden probar las contraseñas (ataque de diccionario).

  

Solo he empezado a ver la seguridad, por lo tanto, soy un principiante en esto, ¡así que cualquier ayuda / consejo sería apreciado!

Use las herramientas adecuadas. No intente crear sus propios protocolos. Si intenta crear sus propios protocolos de seguridad, casi siempre tendrán fallas.

Hay muchos problemas con tu protocolo:

• revela el nombre de usuario (puede que no sea un gran problema, pero aún así)
• revela el hash de contraseña: permite el ataque sin conexión a la contraseña
• el servidor debe conocer todas las contraseñas en texto sin cifrar (ya sea almacenándolas en texto sin cifrar o almacenándolas encriptadas con encriptación simétrica y almacenando la clave de encriptación) (bueno, no el usuario contraseña, pero el verdadero autentificador secreto de usuario)
• y la peor parte: absolutamente sin protección contra un atacante activo

Respondiendo a tu actualización:

  

Debería haber sido más claro con respecto al SSL ... no es que esté haciendo todo lo posible por evitar el uso de SSL, es más adecuado para el escenario en el que no es una opción.

¿Por qué no es una opción en este escenario?

  

Además, dirija sus respuestas más a las razones por las que este enfoque no funcionaría & si pudiera ajustarse para que funcione en lugar de "usar SSL".

TLS le ofrece "seguridad" a nivel de transporte: secreto e integridad (en realidad, el secreto es limitado, ya que el tamaño del mensaje se filtra; el secreto de las claves de tamaño fijo está protegido).

Se puede "modificar" para que funcione sin usar realmente TLS, si vuelve a implementar la mayor parte de TLS para obtener seguridad de transporte sin TLS. El costo de la implementación sería excelente, e incluso si puede obtener todos los detalles correctos, su implementación podría no funcionar tan bien como una implementación TLS cuidadosamente optimizada.

La pregunta importante es por qué no querría usar TLS .

Usted divulga suficiente información para permitir el forzamiento sin conexión de la contraseña.

Revisemos. El intruso conoce la marca de tiempo, la sal y el resultado del hash (hash (contraseña + sal) + marca de tiempo). El atacante puede ejecutar hash (hash ( guess + salt) + timestamp) varias veces con diferentes valores de "guess" hasta que el resultado sea igual al token observado. La contraseña es entonces conocida.

Esto está terriblemente mal. Como dijo el chico curioso, nunca jamás intentes hacer tus propios protocolos de autenticación. Lo que es más perturbador es que usted dice con confianza que evita los ataques de reproducción, cuando no lo hace en absoluto.

Si alguien con un rastreador captura el Paso 5, siempre podrá iniciar sesión, ya que el cliente está devolviendo la marca de hora y el servidor confía . Por lo tanto, puede reutilizar esa marca de tiempo para siempre, hasta que se cambie la contraseña. Incluso si agrega una ventana de tiempo, el atacante solo necesita automatizarla para iniciar sesión tan pronto como el cliente envíe su respuesta.

Hay un par de grandes problemas aquí.

Si está hablando de un navegador como cliente, entonces tiene una gran vulnerabilidad de inmediato. A menos que esté implementando el código como un script greasemonkey (es decir, ya está en el cliente), entonces el código para implementar el paso 3 debe enviarse por el canal no cifrado (lo que brinda la oportunidad de que sea interceptado y modificado).

Dejando esto de lado, su propuesta autentificará el nombre de usuario, pero ¿cómo mantiene una sesión / autentica más solicitudes del cliente?

Incluso sin saber el nombre de usuario y la contraseña, ni cambiar la secuencia de datos, un intruso podría asumir la identidad (según cómo se implementa la administración de la sesión) detectando y reproduciendo el token proporcionado por el cliente.

Sí, es un poco mejor que enviar una contraseña en texto simple, pero solo. Y sí, hay un beneficio en la prevención de la eliminación de una contraseña, incluso cuando no hay un requisito para agregar seguridad sólida a las transacciones reales que se procesan (pero MITM puede subvertir su enfoque para revelar la contraseña real).