What is the best model for taking user authentication off-line?

Question

I am building authentication into a client-server application, and some of the feedback I've received is that I should leave the hash calculation to the server (it was initially implemented to have the client receive the hash, calculate a hash from the client's entered password, and compare them). That seems to make sense, but I am left with a problem -- how can I authenticate users that are off-line?

For example, if I deployed to a mobile device without internet access, what is the most secure way to handle authentication?

The way I see it, I will have to either allow the client to receive the hash + any salt information, OR use a separate pin/password and allow the client to receive the hash+salt for that password.

I would favor the latter because it seems to limit the attack vector -- if a mobile device is compromised, then the security of the whole system (e.g. all the network-authenticated pieces) stays intact.

What are my best options and considerations?

Answer 1

I guess it may depend on your problem domain, but for a secure application, authorization cannot be done client side because of the lack of trust. In the simple case you stated where the hash computation and comparison is done client side, all that someone would have to do to get access is hook a debugger up, step through the code and find where the comparison is done, and replace a value on the stack just before the return (for instance). Congratulations, you've been hacked.

I'd want to know more information about what operations your specific app would want to enable when in "offline" mode, and what your plan would be for reconciliation once the device was reconnected before I'd look at enabling partial functionality offline.

Answer 2

If you explain your application in more detail, I might find that I'm off base here, but for now I'll make some assumptions about your use case and threat model.

My understanding is that you have some sensitive information that you want to synchronize between a mobile device with intermittent connectivity and some remote service. The service is only accessible to authenticated users, and users must authenticate themselves to the mobile device to access its copy of the information, even if it is offline.

If you want strong security, encrypt the mobile device's copy using password-based encryption.

You could use the same password used to authenticate to the service, but in general, I'd avoid reusing the same key for different purposes. A better approach would be to have a master encryption password for the mobile device, which encrypts the mobile database as well as the "password" used to authenticate the user to the synchronization service. Note that the service authentication password could actually be a private key for SSL client-cert authentication, or a character-based password.

You'll have to evaluate the risk of having just one password, but in many cases, I think the convenience this offers the user, combined with the safety provided by one strong master password as opposed to two weak-but-easily-remembered passwords is a good balance.

Note that this approach will allow user whose service access has been revoked to continue to access their local copy, but without any new updates. You could include some notion of a time limit to be enforced by the mobile software, but a determined attacker could circumvent this.

If you just need toy security, your suggestion of storing the correct hash on the mobile device is adequate, and it really doesn't matter whether you hash the real password or an alternate, because if you use the right hash, it should take them a few billion years to find a password collision that would allow them to access the remote service.

However, assuming an attacker can see the password hash, what's stopping them from looking at the synced data too? Why would they need to recover the password? Encrypting the mobile database would prevent this.

Answer 3

I posted a similar question just minutes ago, and after some more thinking, I might have found an acceptable approach, using public/private keys. Here are the steps I outlined for my app:

1. When the user goes offline, he can choose to use a password to secure access to the app while offline (with optional encryption to protect against theft).

2. Upon going online, the client will send an id for the current user (it could be like a hash or something that uniquely identifies that user).

3. The server sends an authorization token encrypted with that user's public key.

4. The client sends back the token decrypted with his private key.

5. The server finally sends a session token to continue further communications (this last step might be unnecessary, maybe the already established auth token can be used?).

I'm no expert on encryption or security, but it would seem to me this approach is very secure, as the only way I can think of to hack into the server would be for the attacker to have the user's private key along with its pass phrase.

In the case of sensitive data, this can be protected by encryption as I mentioned, by either a password just to authenticate the user, or with the data itself encrypted so in case the device gets lost, it isn't compromised.