Protezione dell'API REST tramite Hawk

Attualmente sto utilizzando Hawk come schema di autenticazione per un'API. Fondamentalmente, il flusso corrente (SSL forzato) implica:

1. Tipi di utenti in email / passwd su app
2. L'app esegue 1000 round di PBKDF2 utilizzando l'e-mail come sale, invia il risultato insieme all'e-mail per la registrazione
3. Il server blocca la password usando scrypt (64k / 8/1) e un sale casuale a 32 byte e memorizza la password salata nell'account utente
4. Il server crea un falco segreto condiviso e lo rimanda (id e segreto condiviso) in modo che il client possa creare il payload dell'intestazione appropriato se la password è corretta.

Tuttavia, leggendo questa discussione riguardo all'implementazione, qualcosa è venuto fuori:

I can't think of a problem with that but being that it's creative, security folks don't like it. The main issue is that you created a new pattern that is not as well understood as the normal flows. You should think/implement this as two system. One that takes a username/password and returns a token (be it a cookie or rsvp), and another that takes that token and gets new credentials with it, bound to whoever is using it. Your solution cuts corners a bit which is fine if you don't have a public API or multiple apps.

link

Scusa se è troppo noioso, ma come aggiungere un altro livello (un livello di riferimento indiretto, come vedo) più vantaggioso?

Osservando le implementazioni di falco in produzione, ad es. il protocollo onepw di Mozilla ho notato che restituisce un token di sessione che viene quindi derivato utilizzando HKDF per comporre le credenziali hawk.