The way to authenticate to mobile application based on server's user record?


I am trying to implement following:

  • replicate _users database on my mobile device
  • login with user name and password on mobile offline

The problem I have - replicated database records have no password, instead - salt. Question - how could I check user name and password on mobile device without having server connection? The question is actually - how to calculate salt…but it should not be possible on mobile - only on the server where user is created…

Could someone suggest any appropriate mechanism, how could I check user name and password?

There isn’t such a database, not in the Couchbase Mobile sense of “database”. The username/password info that SG uses is stored in keys in the same bucket as the database, but it’s not accessible to clients (for security reasons) and can’t be replicated.

how could I check user name and password on mobile device without having server connection?

You can’t. Think of it this way: if the user hasn’t already authenticated to the server, there’s no way to get their password, even in hashed form, because it would be a security leak for the server to hand out information about passwords to unknown clients. If the user has authenticated to the server, then all your app has to do is remember those credentials for future connections. (Actually CBL stores those for you, in the cookie store or the keychain.)

Maybe you can describe what feature you’re trying to implement?

Hi Jens,

Thanks, I was actually the same view, otherwise that would be security problem.

Ok what I want to implement -

  • my mobile application should have log in
  • if user entered his credentials, and in a local DB there is no his data, then I user authenticates agains server (if device in online - if not - no login). If his data is in local database - let him start.
  • if user successfully authenticates against server - save his login data locally to be able login offline.
  • In any case if successful login start continues replication for particular this user record. If password changes - immediately logout user.

As workaround I would probably do:

  • if user is not in local db - simply start replication with user name and password to the remote _users db with filter - only this user. If replication will be successful (replication also requires authentication) that would mean user name and password is correct. Replication will replicate me this user record into local database instance “users”.

In parallel I will store salt from replicated record, username and password in another local database “local_users”, which will be used for offline log in.

After successful login (offline or online) I will start always replication of remote _users database for this particular user, and if user record changes and SALT is also updated and not the same as in “local_users” table - log out user and assumed password is wrong (set password to null in “local_users” or remove user at all from local_users).

It is a bit complicated, but I can’t see another approach… Do you see any chance to simplify it?

PS: Yes, my Couch DB server instance is not “Admin Party”, authentication required.

OK, sounds like you’re trying to protect local data from being viewed by an attacker.

Using the same password as the one the user logs into the server with is not a good idea.

  • First, a password used on the server needs to be strong since it can come under online attack. A password that strong will be way too inconvenient to type in on a mobile keyboard every time a user wants to access the app. The end result is that the user will either turn off the feature that asks for the on-app password (if they’re allowed to), or will set their server password to be as short/easy/weak as possible. Bad.

  • Second, if an attacker with the device in hand works out the user’s password, they now have the server password too and can do even more damage with it.

Instead, the user should be asked to create a local passcode for the app, which will be easier to use to log into it. Meanwhile, the app stores the server credential in a protected store like the iOS Keychain. That way the user still only has to remember one password.

The best solution is to encrypt the database too. That way the passcode is directly used to derive the encryption key. This is way more secure on Android, where very few devices have on-disk encryption. And on iOS you can hook this up to Touch ID so that the user doesn’t need to enter a passcode at all, just their fingerprint.

Sounds more complicated that my approach. My needs:

  • only server users should be able to open app. So an admin should define users on server.
  • app creates records in local database, associated with this user. replication makes possible sync databases on iOS, Android and Server web application, so user can process his own records on any device he logged in.
  • for replication I need to have server credentials.

Really thanks for your comments. I will think how to implement my needs most secure way. But I can not agree that password for entering into app could be simple.

Let say for example Lotus Notes Traveler - this is what I want to implement, the same password for server and mobile…

Your needs sound identical to basic replication.

Let say for example Lotus Notes Traveler - this is what I want to implement, the same password for server and mobile…

Users tend to hate apps that make them enter a password every time. 4-digit passcode are generally acceptable, but personally, I’ll only use an app that makes me enter a password if it’s something I’m forced to use, like if it’s for my bank or some work system. If people have a choice of whether to use your app, entering a long password on their phone will be a minus.

But obviously it’s your app.

Back to your question — it sounds like you’re using CouchDB. It does have a users database but it definitely won’t make passwords accessible. Most likely CouchDB doesn’t even store the password itself, just a digest. I don’t believe there’s any way for a client to get the digests — it’s way too easy to crack passwords once you have those.