Question

I’m developing a mobile application for a company. Everyone at the company has an @company.com email address. The app itself is confidential, so it will only be installed on employees’ devices. This app communicates with an external server to store and retrieve data.

Ideally what I would like to accomplish is to let people log in to the app by just providing their email address, without a password. Here is my current thinking:

1. A new user opens the app for the first time on a certain device and puts in their email address. The email address is sent to the server, along with a static token embedded in the application (which is the same for all instances of the application).
2. The server verifies the token and the fact that the email address is @company.com. It responds with a new token/key for use only with that user and device, which the client stores in plain text locally. That key is effectively the user’s password. It is hashed, stored in the server database, and marked as disabled.
3. There are two possibilities at this point:
   1. The server sends an email to that address confirming that they want to log in on a new device. The email contains a link which, when clicked, marks the key as enabled. There would need to be rate-limiting on new device requests so people can’t get spammed if someone discovers the token embedded in the app.
   2. An administrator specifically approves new device requests.
4. Every subsequent client request to the server must include the key.

Assuming all communication is over SSL, does this sound like a secure strategy? Is there a more secure or simpler approach?

Additionally, what is the best way to generate the token that will be stored client-side? Since I want users to only put in their email address the first time they use the app, I believe that this token will never change. Here is my current algorithm (PHP) loosely based on Drupal’s drupal_get_token():

// Usage: get_token($email) or get_token($client_token)
function get_token($value = '') {
  $salt = hash('sha256', 'Some static, predefined phrase');
  $hmac = base64_encode(hash_hmac('sha256', $email, $salt, TRUE));
  return $hmac;
}

As you can see it doesn’t protect against parallel attacks (e.g. if someone figured out the predefined phrase and algorithm and they had access to the database, they could generate hashes and compare them against the ones stored in the database) but because the original key value is already long I don’t think this would be nearly as effective as it would be against normal passwords. Additionally I am not sure of a way to create a dynamic salt that an attacker would not already have access to if they could access the database (or honestly if it would even matter at that point, since getting access to the database would expose the data we’re trying to keep confidential anyway).

Answer 1

After some research and more thought, I believe that the answer to this question comes down to the vulnerability of the local storage. Since it’s safe to assume in this case that only company employees will be using the app, there is insignificant risk of malicious code running in it even if there was a problem in the code that would make that possible. As a result the main risk is from some other app taking advantage of a security hole in the OS’s local storage implementation to read the local private key off the disk. Since the existence of the app should not be known to anyone outside the company, it is very unlikely that this information would be directly targeted. So I think this is an acceptable process for this company.

In the general case though, anyone considering implementing a similar model should be aware of the risks of basically storing a password in plain text locally. (This is as opposed to storing a password in the user’s head, or equally likely in plain text in a password file elsewhere on their machine; it’s your call which is more secure.)