3

So I have an iOS app written in Swift that communicates with a node.js server with an SQL database behind it. The app uses database IDs to retrieve objects from the database. So a search feature on the app will return an array of IDs and the app requests the object data from the server using those IDs of the objects it needs.

The IDs correspond to an auto-incrementing primary key integer in the objects table, for example:

CREATE TABLE database.events (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT,
    name VARCHAR(100) NOT NULL,
    description VARCHAR(1000) NOT NULL
);

From what I've seen some people think this is an awful thing to do and others say if done correctly this shouldn't be a problem. I think in my instance the latter is what I agree with. By 'thing' I mean exposing database IDs to the frontend (the client app).

My understanding is there can be 2 main issues with this:

  1. If a hacker exploited the app and figured out how it makes requests to the server they could send malicious requests requesting data that they should not be allowed to see.
  2. Auto-incrementing IDs can reveal user count, information about the number of clients and customers the business may have.

Am I right in these being the only real issues with it?

For the first one I've put the necessary checks in (server-side) to make sure that a user cannot request or gain access to data they do not have permission to view.

For the second issue, and this I guess is more of why I'm posting this question is how to deal with this elegantly. Admittedly it isn't as bad as the IDs being exposed in a URL as with the app it would require hacking the app to view the data it is sending and receiving. However I still consider that to be an issue and do wish to obscure IDs to stop anyone potential gaining information mentioned above from the IDs.

I was thinking of creating a kind of hashed ID from the auto-incrementing IDs initially from using hash-id but they recommended using Optimus if you only want to generate numerical IDs which I would prefer. It would then be this hashed ID that the app client would use to request objects from the server.

My question is, is this a rational and elegant solution? Is there a better way? Or have I missed a critical vulnerability that I am creating from doing any of this?

Joe Blakes
  • 103
  • 7
  • @RyanVincent I wouldn't necessarily need to know if people are attempting to create 'malicious' requests as I have no interest in recording or prosecuting attempts. If you are essentially talking about the server encoding the primary key ID each time it retrieves it from the database I feel like that makes it unnecessarily complicated and adds a small computational overhead that I'm not sure is necessary when compared to having a one time generated encoded ID stored in the database – Joe Blakes Oct 19 '15 at 20:51

1 Answers1

3

The idea of a hashed ID is good, most databases use a GUID for that. On the other hand these do not provide any security, they only help against problem 2.

For more information read: http://blog.codinghorror.com/primary-keys-ids-versus-guids/

The goal of a GUID (and many hashes) is to be unique, not to be cryptographically secure (unpredictable). Problem 1 can only be solved by an actual secure authentication mechanism.

See: Is Microsoft's GUID generator cryptographically secure

Community
  • 1
  • 1
mevdschee
  • 1,625
  • 19
  • 16
  • I've looked into to GUIDs and the reason why I like what Optimus offers is that it creates fairly short numeric only IDs. GUIDs I feel are unnecessarily long for what I wish to achieve, which is create unique IDs based on the auto-incrementing primary key just to obscure the sequential nature of the primary key. So I guess based on what you've said I'm pretty much on the right track with my thinking – Joe Blakes Oct 19 '15 at 20:47
  • @Joe Yes, I agree :-) – mevdschee Oct 19 '15 at 21:09