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→