3

So Im creating an API for an app that in the backend involves updating users, deleting users, and some other user related stuff.

Im using the slim framework and I was wondering when the user wants to update there details (Name, email, phone) should I make the API retrieve an auth token or the users password before the details are updated??

Example of my curl command ATM: So at the moment I am passing it the uID (prim key of user) which will be stored on the phone.

curl -i -X PUT -H 'Content-Type: application/json' -d '{"name": "Jimbo Change", "email": "jimbo@change.com.au","mobile":"0442889283","uID":"12"}' http://example.com/api/users/

Should I maybe replace the uID with an authentication token that is stored in the database or should I create an encrypted md5/sha of the email and then salt the password and mobile number into it?

Appreciate any feedback/advice!

Ps: Im just getting into security and am loving it so far :)

James111
  • 131
  • 3
  • 1
    A lot of APIs generally do a secret key. This can look like an MD5 digest but should be unique, hard to reproduce and the key shouldn't be something as trivial as 12. – Michael Bailey Aug 27 '15 at 07:41
  • 1
    @MichaelBailey - Would something like an MD5 of the userID (auto increment) be sufficient? Or would it be a lot safer to salt that mD5'ed userID? E.g- md5(TEST_MD5_STRING.$username) Also is it better to pass the "secret" key in the url of the api call or the body? I mean I don't think it would matter but what would you do? – James111 Aug 27 '15 at 07:47
  • 2
    An MD5 hash of the user ID would have no value because an attacker could easily construct the entire range of valid values, starting with MD5(1), MD5(2) and so on. An authentication token should be arbitrary and unguessable. If you store it separately in the DB you can nullify it or issue a fresh token to the user. – Alfred Armstrong Aug 27 '15 at 08:33
  • Couldn't I create an MD5, store that in the database for the particular user and then also store a hashed version of that mD5? I would then store the un hashed md5 on the phone and when they goto update there account details I would validate that md5 with the other values associated to the user? If that didn't make sense then ignore it, trying to explain a lot in such a little paragraph! – James111 Aug 27 '15 at 09:54
  • i believe the discussion here may be useful http://security.stackexchange.com/questions/7057/i-just-send-username-and-password-over-https-is-this-ok – JOW Aug 27 '15 at 11:59
  • 1
    The thing about just MD5ing the userID or something is an attacker can do that about as easily. I'd recommend MD5ing a random value and telling the user "this is your secret key" and keeping it in a DB for auth. Developers generally use secret keys and there is benefit to it not literally being your password. – Michael Bailey Aug 27 '15 at 15:18

1 Answers1

1

should I make the API retrieve an auth token or the users password before the details are updated?

NO because I am assuming that this backend app will be used mainly by the web admins/operations and why should they have access to the user's password or auth token?

Also, whoever is going to use this app must login to the system themselves and you should log the API Calls they made.

JOW
  • 2,317
  • 2
  • 17
  • 24
  • Well basically the app is getting all the content from the database (through the API) as well as updating data in the database! E.g the user can update there password through the API call? They can also update there account details (email, name, mobile number)! Wouldn't it be necessary to pass some sort of auth key through the API call that will be validated before there account information is updated? This auth key could be generated when they sign up and placed on there phone so when they want to update there account that auth key is then passed through the api POST body. – James111 Aug 27 '15 at 09:46
  • if someone can access this authkey, they can easily craft their own API request using this authkey and get access – JOW Aug 27 '15 at 09:55