Double-hashing authentication scheme

Rate my authentication scheme? (This feels simple enough to be a duplicate, but it’s really hard to search for these types of questions. Sorry if it is a duplicate.)


When a password is set, it’s immediately hashed with a random salt S1 and stored as H1.

When a user tries to authenticate, they are sent S1 and a random value S2. They then hash their password with S1 to get H1, then hash that with S2 to get H2. H2 is then sent to the server.

The server simply computes H2 the same way, then compares the values. The server then generates a random 64-bit value C and sends it to the user.

All further communications with the server contain C as an authentication token.


The point here is to ensure that the password is never sent in cleartext; the communication channel between the user and server is assumed to be “reasonably” secure, in that this scheme is for an extremely low-value target; the user’s most common passwords are likely to be the most valuable information present.

The protocol should defend against:

  • Determination of the password by a passive or active attacker
  • Impersonation of the user by a third-party without eavesdropping capabilities

EDITS

  • I’m not using TLS because this is for a video game; I’m trying to minimize latency as much as possible.
  • The user’s password is set via a TLS-protected webapp.
  • I don’t care (much ☺) about the NSA hijacking a user’s account so much as 1337Kid__1 hijacking OtherPlayer‘s account, or an attacker intercepting passwords.
    • I’m making the assumption in the above that eavesdropping on another user’s traffic is hard to do (for someone who isn’t the NSA) without being on the same network segment as them; if this is a notion I should be disabused of, let me know.

Continue reading Double-hashing authentication scheme