We are creating an app and registration of user happens in following way.

  1. User sends via app: email-id/phone and username.
  2. Server sends a pin to enter in app via phone/email.
  3. User enters the pin in the app.

After this we are thinking of two ways we could store some authentication information on app.

A. Server send a token which used by app with all subsequent requests.


B. We negotiate on a secure key using Diffie–Hellman. Then there is a login function which includes server sending challenge and user answering. After this token is generated, used, and later discarded.

All communication is happening over https. Though option B looks better, option A is easier. Any particular reason we should choose B ? One reason I see is unable to change token, but are there any obvious security risks ?

Also comments to improve A or B are welcome.

1 Answer 1


Don't store long lived auth-tokens, as they can be replayed.

Don't store anything connected to a global shared secret, because that could compromise the user indefinitely.

Don't store anything derived from the user password, as that opens up very easy dictionary attacks.

SHA(last-session-key) is one of the best and most secure authentication tokens you can store. It doesn't compromise previous sessions. It's a large secret with plenty of entropy. It can only be used once. It's easy to combine with other factors if you want even more security.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.