0

So I have a restful API that is responsible for handling the licenses for my app, it records

  • User ID
  • User email
  • Username
  • license expiry date

Currently what happens is the user authenticate via a third party auth service (firebase) then the app takes the user ID from firebase auth response and get the license info without any authorization on the license API. Essentially if you have a user ID you can get all the info mentioned above

My question: Is this a security flaw? or is this acceptable considering that it is very hard for a malicious user to obtain another user's ID and even if he obtains the ID the info is not really that useful

Ahmed Fawzy
  • 309
  • 2
  • 8
  • 1
    User email is not "insensitive data." That's sensitive information. To your question, however, how are user IDs generated? Are they UUIDs? User-picked strings? Sequential integers? Basically, how hard is it to guess a valid user ID? (Also I assume that this combination of information is sufficient to license your app; don't you consider that sensitive?) – Rob Napier Sep 02 '22 at 18:08
  • @RobNapier The user ID is UUID indeed, and I think that it is fairly hard to guess a valid ID, `Also I assume that this combination of information is sufficient to license your app; don't you consider that sensitive` The combination of information only contains the license expiry date the info is useless unless obtained by my app – Ahmed Fawzy Sep 02 '22 at 19:10
  • 1
    The only case I can think of someone using this info is if they crack my app to use a specific user ID that they can not authenticate to but somehow managed to guess it, then they could in theory have that user's license, but at this point it would be much easier for them to just crack the app and bypass the license checking entirely, so no I do not consider this combination of info sensitive – Ahmed Fawzy Sep 02 '22 at 19:13
  • If the only way to access the record is a randomly generated UUID, then it is reasonable to consider the UUID to be a "secret key" and knowing it the equivalent of an authentication token. The UIUD space is extremely sparse; they are not guessable any more than AES keys are guessable. So the data is as protected as the UUID. You of course should still use HTTPS to protect the URL in transit. I use these kinds of schemes regularly (where knowing the UUID or knowing the SHA of the data is the authentication). – Rob Napier Sep 02 '22 at 19:15
  • @RobNapier thanks for help, can you make an answer so I can close the question? – Ahmed Fawzy Sep 02 '22 at 19:19
  • 1
    UUID does not guarantee cryptographic randomness. They *may* be guessable depending on which version and which library you use. If you're going to use a hard-to-guess URI to get information (which is already not a good idea), at least make sure you use something that's truly random. – Evert Sep 03 '22 at 00:25

2 Answers2

1

This is a data protection question, not a programming question and you watch it from the wrong perspective in the comments. Information security and data protection and totally different jobs with different mindset.

User ID - personal data
User email - personal data
Username - personal data
license expiry date - probably company secret

What do we protect here?

Some not that sensitive personal data like username and email, which can be guessed by checking the companies webpage or linkedin. The license expiry date is not that important I guess, maybe the company wants to keep it in secret, who knows, better to ask them. The user ID if it is used only here is not a big deal.

What happens when somebody gets the user ID?

They can watch the upper data 24/7 until you add proper authentication or change the User ID. It does not matter how they get it, let's assume they can. They can watch HTTP packets, or an employee sends it by accident to somebody, or they steal this part from the database or they get it from HTTP server logs when you throw out a faulty HDD, who cares?!

What would be the effect to your company?

If your customers don't care about it, then ok. If they would terminate the contract immediately and report the data protection incident to an authority, you will be sued, etc. then it is an issue...

What else can happen?

Do you have support? Can somebody use the User ID and the upper infos to trick your support into terminating the contract and sending back money to the bank account they give? If so then it is an issue either.

Risk assessment is about checking the probabilities, motivations, consequences, etc. of something like the upper and mitigate them if necessary with risk reducing protective measures. Such a thing can be for example encrypting and signing the User ID and the session expiration date before sending it to your API, if it is possible to send encrpyted signed JWT by FireBase.

inf3rno
  • 24,976
  • 11
  • 115
  • 197
1

If the only way to access the record is a randomly generated UUID, then it is reasonable to consider the UUID to be a "secret key" and knowing it the equivalent of an authentication token. The UIUD space is extremely sparse; they are not guessable any more than AES keys are guessable. So the data is as protected as the UUID. You of course should still use HTTPS to protect the URL in transit. I use these kinds of schemes regularly (where knowing the UUID or knowing the SHA of the data is the authentication).

Rob Napier
  • 286,113
  • 34
  • 456
  • 610