Offline user authentication

Question

One of our customers had a pen test performed on our application this week and let's just say it didn't go well.

The main issue they have is that user authentication takes place on the client, rather than the server. The reason being that an attacker could decompile our (C#) application and build a modified version which could allow any password to be accepted.

The problem is, a requirement from our customer is that the application needs to work offline, so some sort of authentication will need to be done by the application without communicating with the server.

The pen testers suggested using a token system where the user authenticates with the server and it stores a token in the local database which would be used while offline, but I don't see how this solves the decompiling issue. Surely this could be bypassed in the same way?

Is my only option to tell the customer that if they want the application to be secure, then it can't work offline?

-- additional details

There isn't an "offline-mode" as such, just when an Internet connection is not available (several of the users might take a laptop to farms, for example), so authenticating with a server isn't possible. Admittedly, this isn't as much of an issue as it used to be, with 4G/5G availability.

On first login, after the initial authentication with the server, settings/config data is downloaded and stored in a local database (MSSQL or SQLite). Logging in while offline would allow access this data (so the program can function) and data the user has entered/saved.

The program has to "phone home" occasionally already (the settings expire after a week of no contact with the server), but I can't see how to stop a user from logging into the program if it is decompiled. If it downloads a token from the server, checking this could be bypassed in the same way entering a password could be.

I guess this question boils down to "is it possible to prevent an attacker decompiling my program to circumvent authentication without requiring a server?". So far the only option seems to be to use the user's password as a key to encrypt the data, but then if (when!) the user forgets their password, the data is lost.

Answer 1

I'd have to agree that a stored token doesn't solve the local attack problem.

Consider encryption.

The security model you're looking for is one where the thing doesn't work when the password isn't present. So store locally but encrypt data so that without the password it's useless gobbledy gook.

Don't store the password. Just it's salted hash. Since the attacker is local you have to assume they have access to everything stored in the clear.

The chief problem here is now you need a decryption layer when accessing data locally. This isn't a small architecture change. Don't cheat and dump decrypted copies on the hard drive. Your pen tester will find them laying around even after the password has been removed. Even if you delete them.

Answer 2

The main issue they have is that user authentication takes place on the client, rather than the server.

So you do have a server?

a requirement from our customer is that the application needs to work offline

All the time?

Is there no opportunity to have the client "phone home" now and then?
It might be acceptable to generate a[n encrypted] Token on the server and store that locally, but have it expire after a period of time, at which point the User has to "hook up" to the server again and acquire a new Token.

Answer 3

In addition to all the previous answers...

An offline mode can be as secure as its counterpart (online). The key difference between the two modes is all the actions you stop allowing due to the authorization need.

Offline modes should be compatible with the fact that some data won't be available or up-to-date and some changes won't be committed to change the server state or the state of data in the datastore.

However, it doesn't prevent you from allowing the user to "identify" himself on the client. Of course, its veracity remains to be seen, but this is something that will happen eventually. Eventually, all the changes will be authorized (or rejected). The offline mode can just postpone this last step.

Under the hood, it tracks and enqueue all the operations required to reproduce the client state on the server. Once online, if credentials bound to these operations are valid, the client push all the operations upstream and hope for the best.¹

But you will find that such pre-authentication is useless and irrelevant for the whole process. And, as you know, insecure. So just leave the user to operate with the data cached on the client and once online and authenticated, do authorize or reject these changes.

Even if the server provides clients with tokens, public keys or certificates, these can change while the client is offline. By the time it gets online again, the secret key might have changed, the certificate could have expired or tokens could have been revoked. Even accounts cached on the client from previous logins can fail if they were removed/blocked on the server-side.

---

^{1: Why hope for the best? Because other offliners might have gone online as well, requesting a different set of changes on the same resources.}