How to prevent unintended REST API usage?

Question

For a university project, I am supposed to implement an API that allows storage and retrival of strings. Clients accessing this api can be mobile phone apps and low power embedded devices. The data stored is not sensitive, but I don't want attackers to alter or delete it. It will most probably not be used outside of our limited experiments, but I would very much like to understand how this would be done the right way.

I have the following constraints:

• For usability reasons, it would be nice if the user is not annoyed by having to create an account after installing the app. Instead, I want it to fetch an id/token on first launch, which is generated by the server that authenticates and identifies this user. This id/token has then supplied on all following requests
• My embedded devices can not use TLS due to storage, ram and cpu constraints

Given these restrictions, should I treat this API like a "public" API, even though I don't actually want it to be public? Is there anything I can do against (from my side) unintended use, besides rate limiting access?

Things I have considered:

I thought about at least having the part where you get a API id/token done over https, thus hiding where you can create an account, and potentially also requiring a secret key to be supplied as well. However, this looks much like security through obscurity to me, and will probably be prone to reverse engineering. But it might be better than nothing? Additionally, I think I should use tokens with limited rights after the sign up process, especially for my embedded devices, since those probably can not handle using https all the time. Otherwise I risk having my account identifier stolen, which could be used to delete all data or overwrite it. These embedded devices will be used only in trusted (home) wifi environments, but that should not prevent me from doing things right.

So to me, the situation looks like this:

• I can not reliably prevent people from using my API in ways I don't want it to be used
• I can and should protect existing users data from modification

Answer 1

Generating an API-Token without the user knowing is absolutely not uncommon. I do this all the time and this is not a problem itself. But sending the data unencrypted is a problem. If this is a allegation given by your professor you can't do anything about it but if you just don't want to use it because of the given reason of performence I have to dissagree with you!

Using https is nothing that really slows down a mobile device that much. Many people use https all the time on their mobile phones and don't even notice that encryption is used because it's not such a big differnce in time needed. If you really need a fast performence you can finetune the https options of your webserver. The performance intensive part is the initial handshake which includes asymmetric encryption that is used to exchange the masterkey. The masterkey is the symmetric key that is used for that session. You can set the livefime of the masterkey to a higher then default value on the serverside to avoid the performance intensive part of following ssl connections.