Save passwords and account information in an encrypted form

[juniorz]

Should we really save passwords? Is this only interesting on a multi-account scenario?

[olabini]

Well, we probably want to do something to save configuration data, including things like TLS fingerprints and other stuff like it - basically, I think the whole config file should optionally be encrypted so you can save all your account information in one place, and then not have to enter all the info every time. xmpp-client already saves passwords, but in a plain text file.

[tdruiva]

Jitsi use masterpassword approach.
For xmmp-client I use to type the pass of each account, but with Jitsi I only need to do it one time.
Apparently they are using AES algorithm to encrypt this info.

[olabini]

When we do this, we should use something like bcrypt/scrypt to make the unlocking of the file take 0.5-1s - we can then cache the bcrypted value in memory for the duration of the program so we don't have to redo it every time we save the config file.

We might also give the user the possibility of turning off the caching and always ask for the password when reading or saving the file.

[olabini]

We should use scrypt for this. We save the parameters first in the file and then use scrypt to generate a good AES-128 or 256 key and encrypt the whole file.

[olabini]

BTW, that Jitsi thing is a bit scary - fixed salt, fixed amount of iterations and it uses ECB. We should definitely not follow that pattern.

[olabini]

OK, working on this today. These are the sub tasks:

• Decrypt existing configuration file
• Encrypt existing configuration file
• Ask for password to load config file (GUI)
• Ask for password to load config file (CLI)
• Ask whether config file should be encrypted when creating (GUI)
• Ask whether config file should be encrypted when creating (CLI)

[olabini]

This has been fixed. The only thing you can't do is set up encrypted storage using the CLI, and since the CLI can't store the account passwords either, I tihnk that's fine for now.