0

Im building a REST api for an ios application!

Would it be a good idea to send the user id (primary autoincrementing token in my mySQL database) of an account when authenticating with user token? (Happens on each get/post)

I thought it might significantly increase performance when checking for authencity of the token? What do you guys think? Does it reduce security? Is this common practice?

I am using HTTPS only of course.

  • An autoincrement token itself is a potential problem, as it's possible for an attacker to extract information from the knowledge IDs exist. For example, an attacker might be able to enumerate all users (if you ever expose data to a user via their ID) and can also find information like how many users are registered at any point or even how many users register in any timeframe. It's not mandatory to hide that information but it's usually a good idea. – VLAZ Mar 3 at 16:03
  • @VLAZ Hhmm. Yeah I would have to store the user id inside the application. But thats what alot of apps do? Atleast many games have ”user id 192727” or similar mentioned in the settings! Many popular games! Why do they do that then? Dont they auto increment? I thought everyone used autoincrement. Anyway, would the performance boost be significant? – user109321948492842303 Mar 3 at 16:19
  • Some do it because they simply don't know better. Others know but don't care - exposing yourself to enumeration isn't necessarily bad. And others still may not even have sequential IDs but random ones, so "user id 192727” wouldn't be preceded by 192726 or followed by 192728. At any rate, as I said - it's a potential consideration. You may actually decide this is OK. – VLAZ Mar 3 at 16:27
  • @vlaz But I dont even need to expose the id in any way not even to the app right? I can just use the accessToken for everything and the id never leaves my servers, right? – user109321948492842303 Mar 3 at 16:33
  • That's possible yes. Yet again, I'm just pointing out a potential issue. I don't know either your app nor your intention, so I can't say what exactly you need to do. It's up to you to decide. – VLAZ Mar 3 at 16:36
0

Sharing the internal ID of a user with the user himself is not considered a bad practice, many apps do it. Relying on the secrecy of such an ID is, especially if it is autoincremented. This is called security through obscurity.

Would it be a good idea to send the user id (primary autoincrementing token in my mySQL database) of an account when authenticating with user token? (Happens on each get/post)

This can work, but be aware of the checks you need to make on the server side.

For identification and authentication

  • Make sure the user ID exists in your app
  • Make sure the token is valid
  • Make sure the token belongs to the user id passed with the request

For authorization

  • Make sure the user, who is now authentication, has access to the requested resource

I thought it might significantly increase performance when checking for authencity of the token? What do you guys think? Does it reduce security? Is this common practice?

Depending on what authentication scheme you use, you may need to hit the DB anyway. The performance gain if any depends on your use-case. Generally, I would avoid premature optimization. Build the app, measure your bottleneck and if it ever looks like the authentication, authorization needs speeding up, that's when you start thinking.

For your use-case, I would probably go with JWT tokens, where you can encode the user id inside the token. This will take care of the identification and authentication part: as only you can issue such tokens, and the token content cannot be tampered with. Beware, JWT has some limitations when dealing with session management and you still need to deal with authorization!

For alternative authentication methods take a look at the Web Authentication Guide I compiled a while ago.

0

If you find yourself concerned about passing the ID to either GET or POST a few changes to your design or approach may be needed.

  • When creating a user account, generate a unique identifier (UUID) based either on ID or some other means like first-name, last-name. If the backend is python have a look at this
  • Generate a slug based on first-name, or last-name eg. (firstname.lastname) or any other thing to generate a slug with.
  • Encrypt the ID and decrypt it at the backend (quite expensive on memory)

This way you don't need to worry about predictive eyes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.