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?

konstantin_doncov
  • 157
  • 7
  • 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 06:05
  • @SteffenUllrich ok, I mean that If I would use Kerberos or Nonce for authentication and message passing, would it be excessive? – konstantin_doncov Apr 13 '18 at 06:16
  • 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 06:24
  • @SteffenUllrich what additional details should I provide? – konstantin_doncov Apr 13 '18 at 06:32
  • 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 07: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
  • @Luc yes, I understand. I will do it within 24 hours. – konstantin_doncov Apr 13 '18 at 12:37
  • @SteffenUllrich I provided some additional information, please check the question. – konstantin_doncov Apr 14 '18 at 06:09
  • 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 06:31
  • @SteffenUllrich
    1. Does it mean that both messages passing and user authentication process are properly protected on the net transmission stage and don't need additional cryptographic and/or authentication protocols?
    2. I've made changes regarding the hashed password in the question, please check it. I know that hashing changes depending on which stage it is registration or authorization is strange, but can you give only an assessment in terms of the security of storing such a password hash in the DB (assuming that the storage itself is also protected)?
     – konstantin_doncov Apr 14 '18 at 07:29
  • As I said in my first comment: properly used TLS does not need additional protection for the transmission stage. 2. Still confusing, now hashed_passwords has different meanings on different places in your question. As for storing password hashes on the server: it is often discussed here and no need to repear it - see How to securely hash passwords?.
    • – Steffen Ullrich Apr 14 '18 at 07:40
  • @SteffenUllrich this is exactly what I said :) Ok, now I changed not a description of the hashing but the hashing process itself, please check it. – konstantin_doncov Apr 14 '18 at 07:53
  • 1
    Given that the description it looks like that a) hashed_password is actually the password used between client and server, i.e. an attacker needs to have only this. And b) your server stores hashed_password without additional protection, i.e. if the server database is broken all hashed_password are known and can be misused. See the question about password hashing I referred to in a previous comment on how to do this properly. See also https security - should password be hashed server-side or client-side?. – Steffen Ullrich Apr 14 '18 at 07:59