RESTful application security

Question

I have written a C++ application framework which communicates with a server app, using a RESTful API. The data passed between the client and server is currently using a (32bit long) simple password that is known (hardcoded) in both server and client.

In my current scheme, the data transfer between client and server is done as a binary encoded data. The data is a zipped JSON format string that has been encrypted using a password (as mentioned above).

I am aware that this is possibly, the weakest form of security. I would like to beef up the security by using HTPPS as well as some other mechanism so that each client has a unique token which cant be faked - even by anyone who may happen to be eavesdropping to the messages. This is very important, since sensitive personal and financial data will be transferred between the server and the client, so any security breaches can be considered to be fatal.

Can anyone please outline a strategy/methodology (or best practise) to implement such a security - including, if I have to do anything else to use HTTPS instead of HTTP - incidentally (may seem a dumb question), but what extra security does HTTPS offer over HTTP in such a scheme as the one I have described above?

I am particularly interested in:

1. RESTful authentication/authorization
2. Securely dealing with each client - so that the server can identify attempts by rogue clients attempting to "pretend" to be another client. For example, instanceA of the child app should NOT be able to masquerade as instanceB for example.

Answer 1

Focus first on sensible security measures

We have an application deployed widely (US and Europe) and it relies on several simple principles

• All communication is over HTTPS to prevent man-in-the-middle attacks

• All users (or apps in your case) have a username and password which is used to verify identity - verification is over HTTPS

• Verified users get a time-limited session-key which forces a re-verification when it expires

• The sys admin can revoke any session at any time

• All invalid logins are tracked and alerts sent to the sys admin so we can see an attack in progress.

Restful Authentication

Our app has a REST-style API which the remote UI uses as do third-parties (SAP / Excel ...). The REST aspect is pretty much orthogonal but we do use a Ruby RESTful authentication module. The key learning is that sessions are resources which can be created and destroyed by action on the /sessions set of resources. The session maps a client (user or app) to an authenticated session.

A nice article on the background to RESTful authentication can be found here. I particularly like this extract ...

Authentication is one of the hardest issues when developing software. Because if you got even one bit wrong, your solution is no longer secure. And your reputation may go down with it. So why do web developers insist on developing their own security? Why not use HTTP authentication which is probably far more secure than most programmers will ever be able to develop themselves?

There are some good resources already in Stackoverflow. Take a look here for example

Implementing HTTPS

You are probably pretty much aware of what you need for HTTPS

• A cert - we use GoDaddy - dreadful web site but pretty cheap and reliable. We use a global cert to cover our whole domain

• A web server which can handle HTTPS - all of them these days, we use NGINX because it is fast, reliable and easy to configure

• Appropriate client library which can handle HTTPS connections

Answer 2

You allread have a detailed but general answer, let me elaborate on your specifics:

• You don't need the certificates to be from a third party, you can issue them yourself.
• While you are at it make a cert for the server as well for the clients to verify. This is great against man in the middle attacks.
• One of the benefits of SSL (the S in HTTPS) is established tools for key management, you won't have to re-invent the wheel. (where do you keep the password now on the client?)
• With a unique cert for each client deployment you can forgo any further authentication.
• If you want to add one more factor (and also a honeypot for someone at endpoint trying to log in with someone else's password) you can add HTTP Basic, it's perfectly safe within HTTPS.
• The server terminating the SSL connection has access to the credential details of the certificate. If you use a dedicated proxy for this, it needs to add the relevant information to the request as a header.