couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jay Zamboni <jzamb...@vretina.com>
Subject Handling encryption keys in a disconnected environment
Date Wed, 09 Nov 2011 17:10:44 GMT
Hello fellow couchdb users



We are creating a couchapp that will reside on a wireless client.  There
will be one central server and multiple clients that are accessing and
syncing the same database.  We are using the couchdb session based
authentication for our login.



Some of the data we store on the client needs to be encrypted in case the
device is lost or stolen.  The server will encrypt the data before it is
sent to the client and the client can securely request the encryption key
from the server when needed.  This works fine when we have a network
connection, but we want the client application to be able to decrypt data
even when it cannot connect to the server.  This seems to force us to store
the decryption key on the client with the encrypted data.  Storing the key
locally seriously weakens our security so we would want to at least encrypt
the stored key with the users password(+salt).  The authentication in
couchdb does not store the password, it stores a password hash.  That’s a
good thing, but it means our users would have to enter their password for
every page that displays this encrypted data.  This would happen enough
that disconnected usage would become very frustrating.  We could pass the
password around from page to page, but that weakens our security even
more.



The current idea we are discussing is:



User logs in

            Decrypt stored key with user entered password

            Create session (Get session id for couch session.  Not sure how
to do this yet.)

            Encrypt key using session id and store in couch



As the user goes from page to page we would use the session id to load the
encryption key.  When the user logs out or the session times out, the
session id should not exist anywhere.



The application is planned as a free download for users interested in the
product, so we are trying to avoid options that will be obstacles to the
user being able to try it.  That being said, the security of this data is
very important, so we need to come up with a strong solution.  If anyone
has ideas or experience with this kind of thing, I would love to have more
input.



Thanks



Jay

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message