Security concept for Android app with PHP based REST API

Question

I'm trying to build my own PHP based REST Api for my Android app and I'm a litte bit confused by all the different user authentication stuff one can find on the internet. So I want to present my security considerations and would be glad about some feedback.

First, I want to make clear that I don't want to build a public API where 3rd parties could register for an API key, instead I want only be able for users of my app to do all the register/login/sending requests stuff. So my plans are as follows:

1. When a user wants to register, my app first exchanges generated keys with my server using the Diffie-Hellman method. For this, my server and my app store information about the same prime number and the same base (often called p and g). My app then generates a secret and creates a public key out of p, g and the secret. The public key is send to the server, which answers with sending back a user id in the Java UUID format and the server's public key based on the server's secret, p, and g. At the end, both parties are able to generate a common secret. The whole transaction is done using TSL/SSL and can be seen here. Instead of the whole numeric, pretty long secret, a SHA-512 hash is stored in the database and the app.

2. After exchanging the key, I can now send the user's account information (userid, password and other stuff) to the server using TSL/SSL. The app's secret is used for HMAC making sure that the app instance (the user) is authorized to send me this stuff. I can check this as I stored the SHA-512 hashed secret and the userid in the database. The password needs to be transmitted to be able to re-login if the user logged out or for wants to change his password. The password is hashed follwowing these instructions. After logging in, a random login token is returned to the user representing his logged in state. This login token is also stored in the database.

3. Instead of sending the user's credentials with every request, the login token is used as login credentials and the secret generated in the first step is used to do HMAC. So if I get a request, I can first check if the user is authorized to sent me a request by doing the message authentication with HMAC and then I can check if the user is logged in comparing the transmitted login token with the one stored in the database. This transaction may also be done with TSL/SSL but doesn't need to.

Is this a valid concept or does it lack of some crucial points, contains misunderstandings or is there any other kind of problem with it?

Answer 1

This proposed security system is vulnerable to CWE-602: Client-Side enforcement of server-side security, and does not limit an attacker's ability to access this RESTful API. Fundamentally, any secret provided to the mobile app will be known by the attacker. An attacker with a jail-broken phone can observe memory used by any running process.

It must be assumed that an attacker will have full access to your API. Any functionality provided to the client is by definition attacker-accessible, and must undergo a security review. A good place to start is look for issues found on the OWASP top 10.

Answer 2

Not really a detailed description, but from what I understood, I have few questions :)

In step 1: The Diffie-Hellman key exchange is vulnerable to a man-in-the-middle attack. Even if it is running inside a secure connection TLS/SSL. The only way to avoid that is to use PKI certificates.

In step 2: How do you plan to recycle the secure token. I mean for how long it is valid for authentication? I am sure you thought about that. REST is stateless, so, I am not sure what you mean by login/logout. You do not have session to validate. I think the token should be valid for a specific time window.

In Step 3: if the connection is not secure by TLS/SSL how do you plan to prevent someone from eavesdropping the connection get the secure token and use it to access your RESTFul APIs??