I'm currently using Hawk as the auth scheme for an API. Basically, the current flow (forced SSL) involves:
- User types in email/passwd on app
- App performs 1000 rounds of PBKDF2 using the email as salt, sends the result along with the email for registration
- Server hashes the password using scrypt (64k/8/1) and a random 32-byte salt and stores the salted password in the user account
- Server creates a hawk shared secret and sends it back (id and shared secret) so the client can create the appropriate header payload if the password is correct.
However, reading this discussion regarding the implementation, something came up:
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.
Sorry if it's too noobish, but how's adding another layer (a level of indirection, as I see this) any more beneficial?
Looking at hawk implementations in production, eg: Mozilla's onepw protocol I noticed they return a session token which is then derived using HKDF to compose the hawk credentials.