ShadowKatStudios / OC-Minitel

Easy-to-implement networking protocol for OpenComputers
https://oc.shadowkat.net/minitel/
Mozilla Public License 2.0
41 stars 12 forks source link

Implement network auth system #5

Open XeonSquared opened 6 years ago

XeonSquared commented 6 years ago

I want an easy way to provide user/password auth over streams. At one point I implemented a system as follows:

  1. Client sends auth request
  2. Server generates a salt
  3. Server concatenates password with salt, hashes (sha256 in this case, not ideal)
  4. Server sends salt to client
  5. Client concatenates password with salt, hashes
  6. Client sends hash(salt, password) to server
  7. Server compares both results, if they match, the password is correct.

This has a significant downside in that both sides require plaintext passwords, and in the server's case, stored somewhere.

The alternatives are to use other crypto methods to get a password transmitted securely for the server to hash.

Some interesting things to look into:

skyem123 commented 6 years ago

You could store the password as a hash+salt on the server, requiring the client to hash twice?

XeonSquared commented 6 years ago

The issue with that is that it makes the hashed password the password, you don't need the actual password.

skyem123 commented 6 years ago

yes, but it does improve security, as it avoids certain issues with password reuse (if you make sure the salts are different!)

MrDetonia commented 6 years ago

It might be an idea to implement a simple version of Kerberos authentication. This gets rid of the issue of hash reuse, and also provides an encryption layer to be used after said authentication.

Note this still potentially leaves applications vulnerable to pass the hash attacks (actually pass the ticket), which need to be mitigated by creating new Kerberos sessions.

XeonSquared commented 6 years ago

So it looks like having passwords of some description stored on the server is non-optional - you can't use them to generate things if they're hashed and salted without compromising the hash.

Instead, here's what I suggest:
Have a keyring daemon like ssh-agent that holds the actual passwords in memory. This reads the (encrypted) password db from disk, and provides services for generating salted hashes (ie you can give it a salt and request it to hash(password .. salt)) and setting users/passwords, but not actually get the password back out.

Still looking for other options, of course.