I've experience of system design and programming but not of internet security. Can someone help to determine if the following design is reasonably secure?

The system consists of two parts:

Firstly a website / server (secured with SSL) which displays a map and plots a breadcrumb trail of a user's location. Friends & relatives, given a password by the user, can log in and see where users are located and where they've been (e.g. for the last 24 hours).

Secondly, a phone app which sends GPS data up to the server. The main design consideration of the latter is to keep location messages as short as possible, to minimise both battery life and the user's data allowance. So I don't really want to use SSL for sending messages from the phone (it will add a large overhead to an otherwise small message - probably sent every minute). It also adds to the app's complexity and size.

My proposed solution is the following:

  1. When registering (via the website) the system creates a hash for the user, based on username and password, which is stored in the database as a 'user ID' (this would be a different hash from one used to just store the password). Possibly SHA512 although that might be unneccesarily long.

  2. When installing the app on their phone, users would enter username & password. The app then uses the same hash algorithm, and sends the hash value to the server via a non-SSL endpoint. If recognised, the server responds OK and the app stores the hash as a user ID.

  3. While the app is running, every time a new location is noted it is sent, along with a timestamp and the user ID, to the server (again non-SSL). The server stores the data accordingly against the correct user ID.

  4. The server would be running two separate web services, one SLL and one not, both talking to the same database.

There's probably a flaw here somewhere, please let me know if so! The security consideration is, of course, that someone who hasn't been given a password should not be able to see a user's whereabouts. Thanks in advance.

  • 1
    so you are fine with folks phones constantly broadcasting their location unencrypted? Security can mean a lot of things, and privacy isn't always one of them, but I would struggle to call an app that tracks my location, and sends it through unsecured networks using unsecured protocols and which can be identified to a unique user, secure. Jun 6, 2017 at 15:32
  • As others have pointed out, the flaw is that others could impersonate you (send incorrect location data) but they still wouldn't know who you were, i.e. which unique user you actually are (unless they physically saw you and listened to your messages at the same time.)
    – quilkin
    Jun 6, 2017 at 16:36
  • Thats not the extent of the issue. A third party on the network path between the user and the server would be able to observe all the broadcasts, and modify them mid stream should they choose. This is called a Man-in-the-middle attack. Any time you are sending data over untrusted networks, Encryption is the only way to achieve the secrecy necessary for privacy. Jun 6, 2017 at 17:08

2 Answers 2


As @Eugen pointed out, there is a flaw from both point's of view:

  • We can identify the hash and watch a user
  • We can use a hash to impersonate a user

Additionally, the payload is "in the clear", which is probably not at all suitable for a user's location data...

You could look at salting the hashed data with a timestamp, which would at least create a new hash for each report, but this increases the workload on the server to authenticate a hash (you need to try each user, perhaps with a range of timestamps).

Signing is a good way to get around this - it might be good to look at JSON Web Tokens for ideas, though this is really intended for verifying the authenticity of session data etc... and the payload is still in the clear.

SSL does indeed add an overhead when establishing the connection, but have you actually quantified it? Are you sure that this is an issue? Also, in terms of increased complexity in an App, there isn't much. As you're reporting location once per minute, could you not look at keeping an SSL session active between reports, eliminating the overhead in establishing the connection?

Remember also that SSL is not the only way to encrypt the payload. You could encrypt using some other asymmetric encryption (do not use symmetric encryption)... with asymmetric encryption anyone can encrypt data for a specific target (using the public key), but only the target can decrypt it (using the private key). Look at GPG for a popular starting point - this will also add some overhead, but it would not really be acceptable to transmit such data in the clear.

  • OK, thanks, I guess I will need to use SSL from the client. I had a figure of at least 1500 bytes extra from somewhere (can't find where now) compared with <100 bytes for non SSL. I doubt I can keep a connection open reliably between posts since the system will be used in countryside areas with poor 3G/4G coverage.
    – quilkin
    Jun 6, 2017 at 16:03
  • TCP is magic... it can take hours for a connection to timeout...
    – Attie
    Jun 6, 2017 at 16:04

Your design indeed has a privacy flaw: Once an attacker has figured out the hash value for a user, he can then impersonate the user, i.e. send wrong location data to the server.

This stems from the fact, that your hash is static - once known, always known.

There is a way around this: On the client concatenate the payload data and the current timestamp, then use the hash to sign this. Send the timestamp (in clear) with the request and have the server reject obviously wrong timestamps.

  • The hash is never sent, so can't be snooped
  • The validity of the timestamp can be verified by checking the signature
  • If an attacker eavesdrops on the messages, he can't impersonate the device.

What of course remains as a privacy risk is, that the GPS data is open to everybody who listens in - this might or might not be acceptable to you.

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