2

I have a set of machines that I'm going to setup to push data to my web server over HTTPS at regular intervals. These units will automatically send requests using a script, so I plan on giving them configuration files with a username and long password for authenticating with my server.

Is there anything I should do in addition to user credentials to increase security? I'm not so much concerned about the security of the data as I am about unauthorized users getting access to my server. I figure I can try encrypting the the username/password, but I don't know if that will give me any additional security considering I'll be sending the requests using HTTPS.

Copernicus
  • 105
  • 3
  • 2
    If you're sending the request via https you are already encryping the username and password – Richard Tingle Apr 25 '17 at 21:18
  • 1
    The security issues with using usernames and passwords for this kind of thing is that you need to store them somewhere. Often this means they end up in plain text on the client machine. This is where client certs are helpful because the keystores that protect the private key are widely available. No secrets are passed to the host. – JimmyJames Apr 25 '17 at 21:37
  • See this answer helps you. https://stackoverflow.com/a/56405726/303685 – Water Cooler v2 Jun 01 '19 at 10:27

1 Answers1

4

You can consider implementing a different authorization scheme, notably OAuth with Bearer Tokens as a more robust (and, importantly, not self-invented) mechanism.

Also (or instead), you could consider setting up your server to require a client certificate in order to verify that anything accessing your restricted API is a genuine client (or has managed to at least steal your client cert). This might not be the best solution if only some of your endpoints require this security, as it would negatively affect "regular" users. If that's the case, it might be workable to setup a second API requiring client auth consisting only of the POST resources to be accessed by the automated scripts.

Community
  • 1
Dan1701
  • 3,118
  • 1
  • 15
  • 24
  • +1 on client certs. Just one note, it's not the cert that someone needs to steal (that's public), it's the private key which (ideally) should be generated locally and never leave the keystore or at least the machine. Browsers actually support this fairly well so it shouldn't be an issue if your 'users' are devs. You can also make the client cert optional and provide a different challenge to clients that lack a cert. – JimmyJames Apr 25 '17 at 21:34
  • Using a certificate seems like the best solution to me. This endpoint is not intended for any human interaction, only for collecting data from some machines. Regarding implementing this: Would I generate a private/public key pair per unit that needs to connect, or just one and share the public key? Also when sending a key to my server, would it matter whether it was in the body of a POST request vs in a header field? – Copernicus Apr 25 '17 at 21:57
  • You could generate multiple certs, but in most cases, it's sufficient to have one client cert distributed to all users/machines that need it. The cert is sent as part of the connection handshaking, its not something you need to add in to the request itself. (In Node, for example, it's specified in the `options` object supplied to `https.request(...)`. – Dan1701 Apr 25 '17 at 22:36