Actualmente estoy usando Hawk como el esquema de autenticación para una API. Básicamente, el flujo actual (SSL forzado) implica:
- Los tipos de usuario en el correo electrónico / contraseña en la aplicación
- La aplicación realiza 1000 rondas de PBKDF2 usando el correo electrónico como salt, envía el resultado junto con el correo electrónico para el registro
- El servidor hash la contraseña usando scrypt (64k / 8/1) y un sal aleatorio de 32 bytes y almacena la contraseña con sal en la cuenta de usuario
- El servidor crea un secreto compartido de hawk y lo envía de vuelta (id y secreto compartido) para que el cliente pueda crear la carga útil de encabezado adecuada si la contraseña es correcta.
Sin embargo, al leer esta discusión sobre la implementación, surgió algo:
No puedo pensar en un problema con eso, pero como es creativo, a la gente de seguridad no le gusta. El problema principal es que creó un nuevo patrón que no se entiende tan bien como los flujos normales. Debes pensar / implementar esto como dos sistemas. Uno que toma un nombre de usuario / contraseña y devuelve un token (ya sea una cookie o rsvp), y otro que toma ese token y obtiene nuevas credenciales con él, vinculado a quien lo esté utilizando. Su solución reduce un poco las esquinas, lo cual está bien si no tiene una API pública o varias aplicaciones.
Lo siento si es demasiado noble, pero ¿cómo es más beneficioso agregar otra capa (un nivel de direccionamiento indirecto, como lo veo)?
Viendo las implementaciones de hawk en producción, por ejemplo: onepw protocol de Mozilla, noté que devuelva un token de sesión que luego se deriva utilizando HKDF para componer las credenciales de hawk.