Store some or all answers encrypted in database about govready-q

[JoshData]

We'd need to talk more about how this would work, since the hard thing here is where the decryption key lives --- obviously not in the same database that it's protecting. Is the key specific to an org? How do we securely grant site users and GovReady administrative staff access to it?

Est: A few days to a week, depending on the details, and there would likely be some technical debt until a security expert could look over the implementation.

[JoshData]

Some possibilities for how to securely, and possibly ephemerally, store answers like credentials for other services (like Jira):

a) Answer is stored In the database and encrypted with a key known and entered by the user, e.g. possibly reusing the user's password at login (but not the hash of the password stored in the database, because then the key is stored in the same database as the encrypted content). But where is the key persisted so that the user doesn't have to enter it on each HTTP request?
b) Answer is stored In the database and encrypted with a key stored in a HTTP cookie, so that the key is not stored in our database and we can make the key expire quickly to make the stored value ephemeral (after expiry, the value can no longer be decrypted).
c) Answer is stored in the database session storage, so it would get purged shortly after a user's login session expires - at logout, or after a few weeks. The encryption key would be stored... somewhere else.
d) Answer is stored in a cookie specifically for holding ephemeral answers to questions, which would allow us to expire it sooner. But the cookie would need to be encrypted (for the user's protection) and signed (for ours), jacking up the size of the payload and limiting what we can put in the cookie.
e) Answer is stored In browser local storage so that the Q server doesn't actually see it until it needs it, and it would be sent via AJAX to Q only sometimes.

[gregelin]

This is a good task for the roadmap. We will do it as part of the work with Selection Pressure b/c it integrates with API endpoints.

We could also store and retrieve the secret via an API end-point, possibly in common with a "pop-up" variable.

Once we have an API-endpoint integration, we could target an endpoint that was responsible for storing secrets.

A "pop-up" variable would be a special variable that was collected and immediately used. The variable might even be collected by a special pop-up javascript (like an alert). The variable would be captured by that process, used immediately, and never kept.

[gregelin]

@jlyon @aschmoe Can you share with us a couple of links for documentation you used to encrypt the GovReady Dashboard database?

[gregelin]

Closing due to age.