CODEWITHSUNDEEP
iosobjective-capple-push-notifications
Dave Chen
Dave Chen

Reputation: 10975

Sending Device Token Safely for APNs

For iOS applications that require push notifications, it must first request the user for permission to do so. After that, a device token is generated and with this, the remote server may communicate to the user through this token.

I have read a similar question here and I do not feel it is enough. The picture below is a trusted certificate, it allows me to view all traffic that happens on this device.

With Fiddler2 as well as CertMaker, I can sniff HTTPS traffic, which means the client can probably know what data they are sending, and to where.

My question is, knowing that SSL is not secure from protecting my clients from seeing what I send to the remote server, should I simply encypt with a secret key found within my application?

Such as encrypt("device_token","secretkey_a0a0a0a") (pretend this is Objective-C)?

Couldn't someone just find that key within my application? I also read this question, and it seems that it would be possible to get back the secret key.

My plan for this goes like this:

  1. Within the iOS application, Generate a random string named activate.
  2. Encrypt (not hash), the token by the random string and a secret key that I only know. (secretkey_a0a0a0)
  3. Send the encrypted string along with the generated randomly generated string (active).
  4. Within serverside, I check if I can decrypt a valid token from using the active and my secret key.
  5. I save the token in my database if it is valid.

This prevents people from random entering tokens yes, however, secretkey_a0a0a0 is a string literal. It's very possible to get this within the application binary itself.

My question is, how do I protect this secret key? The answer can also be, how can I prevent people from sending invalid tokens to my server as well.

I have heard of encryption, but doesn't that only apply to resource files?

How should I approach this?

Upvotes: 4

Views: 3781

Answers (4)

Niggs
Niggs

Reputation: 11

To prevent someone maliciously spamming your server with tokens, I would hash the token when a secret key and send both the token and the hash to the server. You can then hash the token again on the server, with your secret key, and check that the request is valid.

Upvotes: 0

Danilo
Danilo

Reputation: 3327

If you do SSL-Pinning ( AFNetworking has this implemented ) you won't be able to (in a reasonable timeframe) sniff the https traffic between the client and server if you don't have the servers private key.

Upvotes: 3

pgb
pgb

Reputation: 25001

You might want to check the security section in the Push Notifications Guide, in particular the section titled "Token Generation and Dispersal".

The device token is generated by the device connecting through the Apple's APNS. My guess (they don't say in the docs) is that it's unique for a given app identifier.

The APNS then will probably match those identifiers with the pem certificate you use to communicate with it thus validating that the push notifications are actually originating from your app.

Encrypting the device token seems overkill in this scenario.

Upvotes: 2

Ivan Alek
Ivan Alek

Reputation: 1919

If your fear is that man in the middle can steal your token and send fake push notifications to users of your application, be sure that this cant happend. Since requests to apple apn servers must be signed with pem file, the main concern should be how to keep certificate file secured, and not apn token. If you want to prevent writing invalid tokens in your database then you should implement some CRC or odd/even bit mechanism.

Upvotes: 3

Related Questions