I'm currently using Hawk as the auth scheme for an API. Basically, the current flow (forced SSL) involves:

  1. User types in email/passwd on app
  2. App performs 1000 rounds of PBKDF2 using the email as salt, sends the result along with the email for registration
  3. Server hashes the password using scrypt (64k/8/1) and a random 32-byte salt and stores the salted password in the user account
  4. 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.

  • 1
    I'm no expert but I think salts are 'supposed' to be random security.stackexchange.com/questions/211/…
    – KDEx
    Commented Jul 21, 2015 at 2:31
  • The main issue is that you created a new pattern that is not as well understood as the normal flows. That is rather a positive security feature :)
    – user45139
    Commented Jul 22, 2015 at 10:02
  • 1
    @Morgoroth we use the arbitrary salts to compose what mozilla calls a 'quick stretched password', a more resilient string for our users and we avoid storing the actual (hashed) password. It's another safety step in case our DB gets compromised.
    – Gaston
    Commented Jul 22, 2015 at 12:28
  • @begueradj indeed, but when it comes to security, creativity is potentially a recipe for disaster :)
    – Gaston
    Commented Jul 22, 2015 at 12:29

1 Answer 1


I wouldn't say there is anything wrong with your approach. Security people are just really into always using the accepted methodology. Take CSRF mitigation for example. There's a bunch of ways that successfully mitigate CSRF but security folks always recommend using a CSRF token because that's the accepted standard for mitigating CSRF attacks. I think the main benefit for separating the transaction into two steps is that the transaction is easier to reason about because each step of the transaction has a specific goal. Yours combines some steps but I don't see any reason why that is necessarily bad, just a little more complicated.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .