NIO Client / server securely authenticate credentials

Question

I use Java NIO secured by SSL to connect client and server. To connect to a server the user is prompted to enter host, port, username and password. So far I can connect client and server (they successfully complete their SSL handshake) and I could theoretically start sending data back and forth. I have not written a mechanism to verify login credentials (username, password) yet.

The server can authenticate username and password by looking them up in a database. If the credentials a client sends are incorrect, the connection will be closed.

Question 1: When should the credentials be validated? I assume this has to happen after the SSL handshake.

Question 2: How do I securely package the credentials before they are serialized and sent to the server? I assume I should hash the password. Should I hash the username too?

Would something simple like this suffice?

public class LoginCredentials implements Serializable {

    private static final long serialVersionUID = 1026410425432118798L;

    private final String username;
    private final byte[] passwordHash;

    public LoginCredentials(String username, byte[] passwordHash) {
        this.username = username;
        this.passwordHash = passwordHash;
    }

    public final String getUsername() {
        return username;
    }

    public final byte[] getPasswordHash() {
        return passwordHash;
    }

}

Question 3: Authenticating credentials should be done once per session, correct? I read some posts that seemed to indicate the credentials should be verified for every request.

Question 4: Which hashing algorithm should I use? SHA–512 seems to be very popular.

Krzysztof Cichocki · Accepted Answer · 2019-02-06T08:47:27.577

0

of course that after ssl handshake, when the ssl connection is established, this makes it more secure
Not many applications really do that, most of them just sends the password over ssl not hashing it at all. Yes, you can generate a hash, but the hash should be generated for every login, so it will not be always the same, this requires some code on client side to resolve some challenge which includes the correct password and some random thing sent by server, otherwise it would not differ much from regular password authentication. But there is plenty of authentication mechanisms - passwords, hashes, tokens, ssl certificates to name a few.
you need to check if the authenticated user has access rights to the resource He tries to access - this is for every request, not to login the user for every request if you have session. If you need to manage the user access rights to grant or revoke access during single session then you need to read the user access rights for every request, if you don't need such granularity then reading them once for the whole session is ok. Sometimes there are sessionless services eg. some REST, then typically you need to send some credentials on every call.
You can use any hashing algorithm that's not too easy to decipher.

edited Feb 06 '19 at 08:47

answered Feb 05 '19 at 22:40

Krzysztof Cichocki

6,294
1
16
32

1

Thanks! Could you elaborate on your answer to question 2? Why would the hash not be the same every time? And what kind of random thing would the server send? – rougemarsrover Feb 05 '19 at 22:52
Because if the hash would be always the same someone could steal the hash and use it to login just as regular password. If the server will send some "random"/unique data to client that will be used together with correct password to genarate the hash on both sides, then the hash is always unique and even if someone would steal the hash/decipher the ssl connection to know the previously used hash He will not be able to login using it. – Krzysztof Cichocki Feb 06 '19 at 08:43
Someone could steal the hash how? If they can steal the hash they can steal the password. – user207421 Feb 06 '19 at 08:58
@user207421 Someone could record the ssl connection and decipher it after few years when apporiate hardware/methods would become available - this has already happend to some ciphers. Someone could do man-in-the-middle attack and discover the pass to use it to log in later and perform malicious activity. Different hash every time someone login will limit such possibilities. – Krzysztof Cichocki Feb 11 '19 at 21:03

NIO Client / server securely authenticate credentials

1 Answers1