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
  • I see that there are some questions similar to this one, but none with the combination of low performance devices, automated sign up and users storing their data with the api.
    – connan
    Commented Dec 26, 2015 at 12:38
  • have you considered encrypting just the HTTP BODY alone, using symmetric cryptography? do you see any challenges with it?
    – JOW
    Commented Dec 27, 2015 at 14:03

1 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.

  • My problem with https is that I (probably) can not use it my low power sensors, as the certificate chain needs more space than i have available. I agree with you that I should use https all the time on a mobile device. Maybe I should try to get more capable sensors, but thats kinda expensive.
    – connan
    Commented Dec 26, 2015 at 16:58
  • How much space do you have available?
    – davidb
    Commented Dec 26, 2015 at 16:59
  • I am not working on the hardware in this project, but I believe it's around a few kilobytes (~5 to 30). I think it's a esp8266 with some additional hardware. I guess it might be possible using only certificate fingerprints, I will investigate in this direction as well.
    – connan
    Commented Dec 26, 2015 at 17:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .