RESTful Application Protection

Question

I wrote a C ++ application framework that interacts with a server application using the RESTful API. Data transferred between the client and server currently uses a (32-bit) simple password, which is known (hard) on both the server and the client.

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

I know that this is perhaps the weakest form of security. I would like to strengthen security using HTPPS, as well as some other mechanism so that each client has a unique token that cannot be fake - even to those who might happen that it eavesdrops on messages. This is very important, since confidential personal and financial data will be transferred between the server and the client, so any security breaches can be considered fatal.

Can anyone describe a strategy / methodology (or best practice) for implementing this kind of security - including if I have to do something to use HTTPS instead of HTTP - by the way (it might seem like a dumb question), but what additional security does HTTPS offer over HTTP in a scheme like the one described above?

I am particularly interested in:

• Authentication / Authorization RESTful
• Safe handling of each client - so that the server can identify attempts by rogue clients to try to “pretend” to be another client. For example, instance A of the child application must NOT be a masquerade, for example instance B.

Answer 1

Focus on smart security first

We have widely used the application (USA and Europe), and it is based on several simple principles.

• All messages exceed HTTPS to prevent man-in-the-middle attacks

• All users (or applications in your case) have a username and password that are used to verify identity - verification is performed using the HTTPS protocol

• Verified users receive a time-limited session key that forces a re-validation upon expiration

• Sys administrator can cancel any session at any time

• All invalid logins are monitored and alerts are sent to the sys administrator so that we can see the attack.

Reauthentication

Our application has a REST API that uses a remote user interface, as well as third-party ones (SAP / Excel ...). The REST aspect is pretty orthogonal, but we use the Ruby RESTful authentication module. The key learning is that sessions are resources that can be created and destroyed through actions in a set of resources / sessions. A session maps a client (user or application) to an authenticated session.

A good article on RESTful authentication background can be found here . I especially like this passage ...

Authentication is one of the most difficult issues in software development. Because if you make a mistake, your decision ceases to be safe. And your reputation can go with him. So why do web developers insist on developing their own security? Why not use HTTP authentication, which is probably much more secure than most programmers will ever be able to develop on their own?

Stackoverflow has some good resources. Look here for example

HTTPS implementation

You probably know pretty well what you need for HTTPS

• A cert - we use GoDaddy - a terrible website, but rather cheap and reliable. We use a global certificate to cover the entire domain.

• A web server that can handle HTTPS is all these days, we use NGINX because it is fast, reliable and easy to configure.

• An appropriate client library that can handle HTTPS connections

Answer 2

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

• You do not need third-party certificates; you can issue them yourself.
• While you are making a certificate on it for the server, as well as for checking clients. This is great against a man in medium attacks.
• One of the advantages of SSL (S in HTTPS) is the key management tools, you do not have to reinvent the wheel. (where do you keep the password now on the client?)
• With a unique certificate for each client deployment, you can opt out of further authentication.
• If you want to add one more factor (as well as honeypot for someone at the endpoint trying to log in with someone else's password), you can add HTTP Basic, which is completely secure in HTTPS.
• The server terminating the SSL connection has access to the credentials of the certificate. If a dedicated proxy server is used for this, he needs to add the corresponding information to the request in the form of a header.