1

I use TLS for securing my client-server TCP communications.
I have a Qt server and Android and iOS clients. For TLS connection I use only server side certificates, so only clients sure that they are connected to the real server, but server doesn't know whether it is a trusted or malicious application. When server and client TLS via TCP sockets are connected, client can register a new user, or log in as an existing user.

Registration looks like this:

  1. The user provides login, password and additional information about user(age, location etc.) to the client application.
  2. The password is hashed using this scheme: hashed_password = hash(salt + hash(password)), where salt - one of the user's data field.
  3. Client sends login, hashed password and additional user's information on the server with registration request.
  4. Server performs some routine operations(check if this user already exists, are the types of fields correct?) and then registers a new user in the DB: inserts login, hashed on the client side password and additional information about user in the users table.

Log in looks like this:

  1. The user provides login and password.
  2. Password is hashed using same scheme: hashed_password = hash(salt + hash(password)).
  3. Client sends login and hashed password on the server with authorization request.
  4. Server checks the users table in the DB - is there an appropriate pair of login and hashed password? If yes, server authorizes socket of that client as a some user, now all requests from this socket are interpreted as requests from the identified user, until the socket is closed. But the server hasn't got any "token" and/or some other things(and I know that this is not so good, please check this question),
  5. Server sends id of the user to the client(of course this id will be used only for self-identification of the client in the future).

All what I can say about messages and other requests is that they are passed without any additional protection, except for TLS.

So, I have simple question: should I use some additional cryptographic protocols, algorithms or another things in order to protect user authentication process and message passing process?

closed as unclear what you're asking by forest, Tom K., Xander, Anders, LvB Apr 17 '18 at 8:09

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 5
    This depends on your unknown use case, i.e. what exactly do you need to secure. TLS protects only the transport of messages between the two connection endpoints, i.e. not before and not after these endpoints. If used correctly TLS does well what it is supposed to do. So if you only need what TLS offers than you don't need additional stuff. – Steffen Ullrich Apr 13 '18 at 6:05
  • 3
    You are essentially asking if a specific technical approach to solve an unknown problem is excessive. Maybe or maybe not, depending on the problem. – Steffen Ullrich Apr 13 '18 at 6:24
  • 2
    You need to provide enough details about your specific use case which allow others to see if the protection already offered by TLS is sufficient or not. It will probably help if you specifically highlight the parts of the use case where you think that TLS is not sufficient, why do you think so and what do you think can be done. – Steffen Ullrich Apr 13 '18 at 7:22
  • 1
    Currently, there are already 3 votes to close because it's unclear what you're asking. Imagine you post a question "is a door lock enough or do I need a deadbolt or something?" but you don't mention whether you're talking about a church, house, nuclear facility, or something else. We want to help, but if we don't know whether it's about a nuclear facility or about a church, we can't give you any advice. So tell us what it's about. Please edit your question (only use comments to ask for clarification). – Luc Apr 13 '18 at 11:28
  • 1
    Given that you use TLS to protect against sniffing and authenticate the client initially for each TLS connection and don't consider attacks before the message enters the socket or after it left the socket as risk (at least you don't describe what happens there) I think the message itself is properly protected and authenticated. Your password scheme looks strange but this might be because you use the phrase password for different things and it is not always clear what it means in each context. Since you don't describe how the password is stored on the server side this risk is out of context. – Steffen Ullrich Apr 14 '18 at 6:31