search

pmorrill / DendroicaAPI

Issues and documentation regarding the Mobile App API
2 stars 0 forks source link

API security #6

Open pmorrill opened 4 years ago

pmorrill commented 4 years ago

Now that the api is documented and somewhat public, I am considering an increase in it's security. As it stands, anyone with an account within NatureInstuct could use the api to construct an offline dataset that includes the Dendroica records.

This is probably too public, given the copyright agreements with the photographers and recordings.

Therefore, I suggest that we should include a new factor in the authentication step, amounting to a shared secret of some sort that ensures that the client is in fact the mobile app. Can we bury a secret in the app, that would be hard to reverse-engineer, and then use it with a fingerprint of some sort to identify the client as the app?

RobynVG commented 4 years ago

I've been looking into this and doing a lot of research on the topic. I can add some encryption for the authentication step but would this mean that we can't have unauthenticated access? Also burying a secret key in the application won't make it 100% secure although I understand it does add an extra level of security so I'd be happy to implement it. Would it suffice to encrypt the username and/or password with the secret key? this way you can decrypt it on your end which would ensure that it was correct and encrypted in the first place. This also reminds me of another security issue I'd like to bring up but I"ll open a new issue for it

pmorrill commented 4 years ago

As I say - we use SSL for the transfer protocol, so this is just as secure as entering a password into the web sign-in form. I am not worried about that. But, password storage is a different question. In the web database I am moving towards NOT storing passwords at all (I store salt and password hash), which is one reason why you can no longer recover an existing password (you can only reset it). This transition is not complete, but almost.

The question here though is whether to use a secret key to ensure that data pull requests are coming from the app. Does not preclude a system that would work for unauthenticated users. Which are not supported at the moment.

I agree that burying a shared secret is not fool-proof, but adds just one more difficulty for someone who wants to grab all the data via the API. Let's leave this for now, but maybe revisit after some thought.