Is my design secure? [closed]

Question

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.

Answer 1

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.

Answer 2

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.