Overview
For a product like this, the two main security considerations are:
- Preventing un-authorized access.
- Protecting the content of the transferred data.
Preventing un-authorized access
- Each server installation has a unique 128-bit identifier that is used to generate tokens. It should not be necessary, but it is easy to generate a new identifier for the server periodically.
- Clients use that same identifier to generate an equivalent token. The client generated token must match the server's in order for a request to be honored.
- Tokens change every minute.
- In installations where a client also has a .Net environment available, the tokens are generated independently on the client and server.
- In cases where there is no .Net environment on the client, the client can request a token from the server before submitting the actual data request.
- Requesting a token from the server requires supplying the server's unique 128-bit identifier and the data transfer is encrypted.
Protecting transferred data
- When an installation is entirely within the confines of a local network, it may not be necessary to secure the content of messages. In these cases, it is possible to configure the system to use plain HTTP requests.
- The default behavior is to use HTTPS to encrypt all communication between the client and the server using SSL.
- In many cases, the actual data is not highly confidential and in that case, it is possible to generate and use a self-signed certificate.
- When the interaction is over the public Internet and tokens are requested from the server, an existing trusted certificate should be used or a new one purchased.