Thanks for the input Jens



<< Is this a pure web-app or will it have native components?



The ideal solution was intended to be a pure web app.  We have considered a
native/html solution like PhoneGap for other reasons.  I suppose this adds
more weight in that direction.



<<I don’t know the implementation details of how CouchDB tracks sessions,
but if it stores the currently active session IDs on disk, then this won’t
be secure,



The session id would not necessary have to be the couch session id.  If we
generate an id on login and post it as we go from page to page it would not
be stored on disk, however it would be in the browser memory, so the
session concept is a flawed solution.



Thanks again



Jay

On Wed, Nov 9, 2011 at 2:13 PM, Jens Alfke <jens@couchbase.com> wrote:

>
> On Nov 9, 2011, at 9:58 AM, Jay Zamboni wrote:
>
> 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).
>
> Is this a pure web-app or will it have native components? iOS has APIs for
> storing secrets like keys in a secure encrypted “keychain”. I’m sure
> Android has a similar feature. (Even if you’re going to use a wrapper like
> PhoneGap to package your app for mobile devices, then that’s likely to have
> JavaScript bindings for those APIs.)
>
>           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.
>
> I don’t know the implementation details of how CouchDB tracks sessions,
> but if it stores the currently active session IDs on disk, then this won’t
> be secure, as an attacker can look at the server’s files and locate both
> the session key and the server key that was encrypted with it.
>
> —Jens
>