Is it inherently dangerous to expose/make public m

问题:

I am trying to figure out if it would somehow compromise users if the API Key used to send notifications to an app was made public. In what situations might it be dangerous?

As far as I can tell, an attacker would also need a valid registration id in order to be able to actually send a notification to a user of the app. If it is unlikely that an attacker gets hold of a registration ID is there any real danger? Are there ways to get hold of a registration ID, which don't involve somehow getting it from the app that creates it?

---

My use case, specifically, is making an app where it would be relevant for the user of the app to get hold of the API key and send notifications to his own device. I am trying to figure out if exposing the API Key would let him send notifications to other users as well (without knowing their registration IDs).

Update (due to The Anathema's answer): At no point will the registration ID leave the device (unless manually copied by the user of the app). There is no database storage, no web requests transmitting it. The registration ID is also exposed to the user of the app.

回答1:

It depends.

You don't want them to have both authentication tokens. If they have one, all they need is the other.

You have multiple failure points. When you're saving, storing, and retrieving the registration id, any of those points, improperly handled, can expose a registration id that would make you liable should an attacker have a handle on it, since that traffic is associated with you.

• A brute forced attack (waiting for a successful handshake/OK response)
• An unfortunate stack trace.
• A database exposure.
• A hacked/compromised user.
• Intercepted packets/HTTP non hashed data (if not HTTPS).
• A listener on the receiving device.
• ...

You want to build redundancy into any system, and It's why some services require a key, a name, a nonce (one-time string), a password, a token, etc.