Search code examples
javasecurityhttpencryptionman-in-the-middle

Secure connection between client and server

I'm developing a server component that will serve requests for a embedded client, which is also under my control.

Right now everything is beta and the security works like this:

  1. client sends username / password over https.

  2. server returns access token.

  3. client makes further requests over http with the access token in a custom header.

This is fine for a demo, but it has some problems that need to be fixed before releasing it:

  • Anyone can copy a login request, re-send it and get an access token back. As some users replied this is not an issue since it goes over https. My mistake.

  • Anyone can listen and get an access key just by inspecting the request headers.

I can think of a symmetric key encryption, with a timestamp so I can reject duplicate requests, but I was wondering if there are some well known good practices for this scenario (that seems a pretty common).

Thanks a lot for the insight.

PS: I'm using Java for the server and the client is coded in C++, just in case.

Solution

  • I don't get the first part, If the login request is https, how can anyone just copy it?

    Regarding the second part, t This is a pretty standard session hijacking scenario. See this question. Of course you don't have the built-in browser options here, but the basic idea is the same - either send the token only over a secure connection when it matters, or in some way associate the token with the sending device.

    In a browser, basically all you have is IP address (which isn't very good), but in your case you may be able to express something specific about your device that you validate against the request to ensure the same token isn't being used from somewhere else.

    Edit: You could just be lucky here and be able to rule out the IP address changing behind proxies, and actually use it for this purpose.

    But at the end of the day, it is much more secure to use https from a well-known and reviewed library rather than trying to roll your own here. I realize that https is an overhead, but rolling your own has big risks around missing obvious things that an attacker can exploit.