Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement network auth system #5

Open
XeonSquared opened this issue Apr 17, 2018 · 5 comments
Open

Implement network auth system #5

XeonSquared opened this issue Apr 17, 2018 · 5 comments

Comments

@XeonSquared
Copy link
Member

XeonSquared commented Apr 17, 2018

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
Copy link
Contributor

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

@XeonSquared
Copy link
Member Author

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

@skyem123
Copy link
Contributor

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

@MrDetonia
Copy link

MrDetonia commented Apr 23, 2018

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
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants