Security: never store fully decrypted private keys in session or local storages

[let4be]

Instead:

• api generates a secret token(urandom)
• client encrypts keys before persist them with this token
• client notifies api about success
• after N sec api generates new token etc

Use case: private keys never get persisted in plaintext decrypted form and we never(by design) persist secret token.

Computer may be stolen or persisted data may be read by some other application(sometimes even after deletion - I.e information restore techs), if this happens private key (encrypted with the secret token) won't be compromised.

This would require additional data to use this private key while api token(remember me) may effectively limit access to the secret key or be invalidated by request

I.e PC was stolen and user makes request to invalidate his api token(or it invalidates automatically due to IP change)

[let4be]

What do you think @andreis @pzduniak ?

[andreis]

http://en.wikipedia.org/wiki/Cryptographic_nonce

It's a good idea. If the nonce will be saved in session storage, too, then when the backend decides to rotate the nonce, the keys can be decrypted, old nonce deleted, and the keys can be encrypted with the new nonce again. Each auth token should have an associated nonce and nonce_expiration_date.

This sounds tricky to implement though, let's discuss implementation details at the next dev meeting.

PS: It's a great idea, good job :)

[andreis]

I'll say it again, it's a great idea!

One more thing. If we have a system-wide nonce, an attacker only has to record all past nonces (via an account, or even without one if we make the nonce endpoint public).

I recommend adding a nonce to the auth token itself, potentially like a new field (NoSQL ftw). We could use http://en.wikipedia.org/wiki/PBKDF2