How can I secure a server authentication password securely on client side?

Question

In my application a client connects to a server via SSLSocket . To authenticate the server sends the salt and the client sends the password encrypted with the given salt.

I actually do not want to have the user type his password every time, but on the other hand I do not want to have a security issue.

I read about keystores, but are they secure? And also for my understanding, the user still has to type a password.

What would be a secure and user-comfortable solution?

Answer 1

If I correctly understand, your current protocol looks like the following:

server -> client: random nonce
server <- client: encrypted password
server <- client: encrypted password

Client doesn't have to send his password again and again, and I would recommend you to leverage an access token in your protocol. Access token ("authentication token", "session id") is a big random value which server returns as an authentication response:

server <- client: encrypted password
server -> client: 256-bit access token
server <- client: 256-bit access token
server <- client: 256-bit access token

It is a session management. NIST provides recommendations about session management: https://pages.nist.gov/800-63-3/sp800-63b.html#sec7

Session management is preferable over continual presentation of credentials as the poor usability of continual presentation often creates incentives for workarounds such as cached unlocking credentials, negating the freshness of the authentication event.

Client holds the access token in the memory and uses it instead of the password. If you want to preserve the access token between application launches then you have to store it safely and it depends on client's OS:

1. Android: KeyStore.
2. iOS: keychain.
3. Linux/Windows/MacOS: it is hard here - just hold the token in the memory as long as possible, don't put into file, make application to run as long as possible.

Either way, access token has to expire after a while, and even if it leaked by some reason, the client would get a new one after a while. See the part about re-authentication in NIST .