End-to-End Communication: General Contract

[FastFelix771]

Basic concept of the communication between our application end-points. (the front- and backend(s))

There backend communicates exclusively via its RESTful interface with the outside world. The frontend contacts the backend(s), never the other way around. (WebSockets, SSE may be excluded)

Every request to the backend contains an alphanumeric token of not yet specified length. 32 maybe? The token is mapped to a profile on the backend, which contains roles, groups, permissions etc. - there is no password or password hash to authenticate and authorize, just tokens. similiar to JWTs, but not self-contained, as the use of such functionality would be very limited in our case.

During the backend installation, a master token will be generated: The master token has access to EVERYTHING. It has no special role or permission, its exclusively categorized as mastertoken.

Using the mastertoken, you may create Slave Tokens to give to users with less powers and restricted access, which can be, dynamically, adjusted using the mastertoken or another slave token with enough permissions attached.

These tokens may be cascaded by an extra login layer with username & password for simplicity, to enhance the user experience of an frontend application. The frontend will never need to transfer any kind of user password to the backend - the tokens will be generated randomly without ANY manipulatable factor from outside.

The communication between front- and backend should be encrypted to increase general security and enable secure operation in environments without SSL encryption and to prevent 3rd party services that may hook into the SSL stream from sniffing any sensitive data by any chance. cough CloudFlare cough

To ensure both ends communicate securely, i suggest this: The Server provides an RSA public key via its REST endpoint. The client encrypt his request body (including the clients' token!) and sends the request to the backend. The backend decrypt the requests via its private key and validates the contents. The backend responses will be AES-256 encrypted, using the clients' token as the AES secret.

Now only the Client and the Server should know the unencrypted token and a secure data exchange would be ensured. Only thing im worried about are possible Man-in-the-Middle attacks which could send a fake public key and compromise the whole data exchange this way... but this probably only affects non-SSL environments. Maybe we can add some kind of fingerprint check to validate its origin. Any ideas for that @jens1o ?

Beside that, the RESTful endpoints will be using different HTTP codes to respond, depending on which code describes the executed operation best. The HTTP method that will be used is probably 99% POST - for some things maybe also PUT and DELETE, and rarely, for public and unencrypted informations for example, GET.

Any additions?

[jens1o]

Maybe we can add some kind of fingerprint check to validate its origin.

That's a good point, but we need to explore deeper into this.

[FastFelix771]

That's a good point, but we need to explore deeper into this.

And we should also put our main focus on SSL secured environments - legacy security standards should not be priotized over modern environments. Admins should move to SSL instead. But still, this should be kept in mind.

[jens1o]

Maybe we can do something like a readme with all defintions and standards we accepted? Like normal RFCs, and proposed, standard, deprecated directories?

[jens1o]

So, basically, like this: https://github.com/php-fig/fig-standards/

[FastFelix771]

Looks good, but PHP is in another dimension of size and organisatoric requirements. We should create some RFCs, thats what the mac-doc repo should be used for, but dont go overkill directly.

[jens1o]

That was an example. I like their structure ;)

[FastFelix771]

Every request to the backend contains an alphanumeric token of not yet specified length.

Case sensitive tokens? (uppercase)

[FastFelix771]

I think we should also limit the Tokens character-range to [A-Z0-9] to prevent encoding issues. Having the tokens "limited" to only uppercase characters, they may become less secure, which can be compensated by making them longer. But i think something like 32 to 64 characters will be absolutely fine.

Using only uppercase characters and numbers, a token with a length of 32 characters will look like this: Q3TSM4GFZGEZFJKVBSGLWHE8SB2H9QVB

According to some up-to-date password security check web pages and programs, such a token would take centuries to brute-force. Its unclear how true this formula is, in the real world, though.

I guess with some quota-limit for failed requests per [minute / hour / day ?], this will be bullet-proof for quite a while.

[jens1o]

Case sensitive tokens? (uppercase)

I would set it to lowercase, because most libraries are converting them to lowercase after converting from binary...

Concerning the limit: I would set 5 requests per minute, and when failed, we do something like NUMBER_OF_FAILED_ATTEMPTS ** 2 minutes.

[FastFelix771]

I would set it to lowercase, because most libraries are converting them to lowercase after converting from binary...

Hmm... then so be it.

I would set 5 requests per minute, and when failed, we do something like NUMBER_OF_FAILED_ATTEMPTS ** 2 minutes.

Sounds good! :)

[FastFelix771]

Nearly 2 years later, i need to confess that i believe we went a bit too far into the paranoias here. Shouldn't an SSL encrypted HTTP connection fit? If goddamn banks are trusting on it, why shouldn't we?

This would also provide us with far more flexibility and enable people to script against the APIs even with Bash or such. Getting RSA encryption to work in Bash or PowerShell is probably(?) possible, but "easy-to-use" is something else, for sure!

That token thing is still an idea. But not at that level of paranoia. What do you think, @jens1o?

[jens1o]

I think it is a great idea to make this a little bit more realistic; I agree with you.