Offline web app authorization.

961 views
Skip to first unread message

Tomasz Guziałek

unread,
Jan 21, 2015, 2:09:49 PM1/21/15
to pou...@googlegroups.com
Hello all,

I am considering an offline web app using a central CouchDB and local PouchDBs in the browser. The requirement is that the user can both read and write to the database while offline, so authorization is a must.

However, keeping sensitive data in the localStorage is unsafe. I am wondering if there is a battle-tested approach for offline authorization in web apps? Does using PouchDB change the situation in comparison to localStorage or IndexedDB/WebSQL?

The best design I can come up with now is:
  • Only the credentials of the users logging in on that particular machine are replicated from CouchDB to PouchDB. The purpose is not to give away the whole database, but only these particular user's credentials are at risk.
  • The credentials are transferred only when the user ticks the checkbox that it is a trusted computer. For example, working on an operating system account that only this user has access to.
  • Passwords are stored in a hashed form, together with a salt. The salt will not help to slow down brute force / dictionary attack on a single password, but at least it cannot be directly compared with an unsalted hash from a different source.
  • During replication, the unhashed password is sent in HTTPS as a second check (to do the hashing on server side again) - even if an attacker tampers the data locally, it will not be replicated to the central CouchDB.

What do you think about such design? Do you find these security tradeoffs for offline capabilities acceptable?

Nolan Lawson

unread,
Jan 22, 2015, 11:29:43 AM1/22/15
to pou...@googlegroups.com
Your concerns are very valid. I recommend you read the following documents:

* PouchDB Authentication, which gives an overview of CouchDB security: https://github.com/nolanlawson/pouchdb-authentication
* Crypto Pouch, which gives you encrypted local databases: https://github.com/calvinmetcalf/crypto-pouch
* Perform all HTTP operations using HTTPS

Basically what you are going to want is a one-database-per-user model (not as crazy as it sounds; "databases" are cheap in CouchDB), where that user has full read-write access to the entire database.

As for "replicating credentials," this is probably not something you want to do. :) Use normal cookie-based authentication; let the browser handle storage of sensitive material (i.e. passwords) for you.

Cheers,
Nolan

Tomasz Guziałek

unread,
Jan 23, 2015, 4:10:47 PM1/23/15
to pou...@googlegroups.com
Hello Nolan,

Thank you for your response. I am not sure if I understand the pouchdb-authentication features correctly. Does it allow the user to login to the application when offline (assuming that the first login was when online and at that time the local PouchDB has retrieved data from CouchDB)? Or is it rather authentication without application server (CouchDB takes over its role), but requires online state to login?

Best regards,
Tomasz

Giovanni P

unread,
Jan 23, 2015, 4:46:31 PM1/23/15
to pou...@googlegroups.com
Tomasz, as I understand it, I am trying to do the same as you are, running a PouchDB only app that works offline and only syncs to CouchDB sometimes. I am not storing credentials, currently. Whenever the user wants to sync he must login (at an external server) from a popup the main app opens, then the database credentials are returned and then the popup passes the credentials down to the main app, which only then starts syncing.

My current approach is bad. It only allows for one instance of the application to be run at each browser (the PouchDB database name is hardcoded and if you try to sync with other account it will mix documents from different DBs and bad things will happen).

--
You received this message because you are subscribed to the Google Groups "PouchDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pouchdb+u...@googlegroups.com.
To post to this group, send email to pou...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pouchdb/7cf112a9-b383-4966-95d7-44519f8a602e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Tomasz Guziałek

unread,
Jan 23, 2015, 6:15:48 PM1/23/15
to pou...@googlegroups.com
Hello Giovanni,

Yes, our thinking is similar. In my last bullet point I forgot to mention that during sync the user should be asked to login again (or there is a cookie present if the user logged in online recently enough). So that is what you are doing.

In order to support multiple users in the same browser, some kind of local authentication would be needed. It seems to me though, the offline authentication in a safe manner is not possible or at least complicated. This thread is to ask if anyone implemented such a feature...

Evernote lets you login only online, but later one can sync without being asked for password. It survives reboots, so the password needs to be storred locally. Same story with Windows 8 login that has an online profile, but of course one can login while offline. Unfortunately, none of these examples is a web app.

Best regards,
Tomasz

--
You received this message because you are subscribed to a topic in the Google Groups "PouchDB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pouchdb/5BfRJRNFJA4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pouchdb+u...@googlegroups.com.

To post to this group, send email to pou...@googlegroups.com.

Giovanni P

unread,
Jan 23, 2015, 8:02:16 PM1/23/15
to pou...@googlegroups.com
Well, this can be done, you can just save a session cookie, like any web app does. I don't have to log in to Gmail every time I power up the computer, because of session cookies, I imagine. My approach today is that the user has to type his password every time, but it could be done with a session cookie that lived for years, I imagine. Is that what you're saying?

I don't want to do local authentication, and I don't need it, the owner of the computer should have (and ultimately has, no mather what we do he can still delete everything if he wants) control over the app instances he have on his browser. Local authentication can be done by Linux user accounts. I just want a way for the user to select the instance he will use, and have this instance linked to some external Couches, so he never synced to/from the wrong Couch. Ok, I can do this, I'm just being lazy and waiting for some magic solution to appear (it is strange to think I am the only one in this situation).

I understand I am not helping you with these comments, but here is something about local encryption: the links Nolan pasted are for encrypting remote Couches, as I understood, but there is https://github.com/blackchair/loveseat for local encryption.

Tomasz Guziałek

unread,
Jan 28, 2015, 3:43:47 PM1/28/15
to pou...@googlegroups.com
Hello Giovanni,

Sorry for such a delay in respoding. If the assume that in one browser only one user can use the app, the session cookie should do the trick. If we want to permit multiple users to use the app offline in the same browser then some kind of offline authentication should be in place. However, considering all the security issues associated with sensitive data stored locally, I will limit the usage to one browser = one user of the app.

I will have a look at the links about crypto from you and Nolan, thank you both!

Pozdrawiam / Regards / Med venlig hilsen
Tomasz Guziałek

Kyaw

unread,
Feb 1, 2015, 10:52:40 PM2/1/15
to pou...@googlegroups.com
There is not really way to hide browser database, if you still want offline access.

For my web app, not PouchDB, I use database name prefix with userid.

Database is encrypted with a key send from server, see detail here http://dev.yathit.com/ydn-db/doc/usage/encryption.html The key is removed when user logout.

The trade off between security and easy of use depends on how key is stored. There is no way to have both.

1. The key is in memory, so user can access even if when offline, but it will not survive browser refresh.

2. The key is saved in sessionStorage, so it survives refresh, but not on different instance of browser window.

3. The key is stored in localStorage, so it survives until user logout. 

The app may ask user if using public or private computer so choose approriate key storage.
Reply all
Reply to author
Forward
0 new messages