Syspass: Encryption

[sdutina]

Could you please explain the encryption process?
Where are encryption (private) keys stored?

Thanks!

[nuxsmin]

Sure, the master password isn't stored anywhere, so it's encrypted with a derivated key from the user's login data, so every time a user logs in it's retrieved and saved into the session to decrypt the accounts password.

The PKI certs are only used to encrypt the password fields that are sent to the server, so if you aren't using https, the password data is secured. These certs are stored within the config directory.

Kind regards

[derStephan]

I do not get it, I am sorry.

Sure, the master password isn't stored anywhere

How is that possible if I only have to enter it on first login?

it's encrypted with a derivated key from the user's login data,

What is encrypted? The master password?

so every time a user logs in it's retrieved

Retrieved from where?

and saved into the session to decrypt the accounts password

Saving the master password on a shared server or a portable drive is obviously not a good idea. May I ask to explain the whole process of encryption, decryption and storage of the master password? And may I suggest to add this extensive explanation to the FAQs?

Thanks in advance
Stephan

[nuxsmin]

Hello @derStephan

you're right, the master password is encrypted within a blowfish key derivated from the user's pass and login and then it's stored in the database, so every user has its own master pass encrypted with its data.

Another point is when the user logs in, the master pass is decrypted with ther user's data and then stored in the session data (a file in the webserver) but before that, it has been encrypted (again) within a blowfish key derivated from the session unique id, so every time the user needs to get any account's pass, he would decrypt the session master pass and then the account's pass. Another important point is that the session id is regenerated every "session_timeout / 2" seconds, so when it takes place, the master pass is re-encrypted. When the session is finished, all its data is cleared, so we don't need to wait for the PHP GC to clear it.

Currently I'm writing the documentation and this point is written :)

Hope I've explained fine.

Kind regards

[derStephan]

Hello @nuxsmin

thank you very much for this excellent and quick explanation. It looks like you did some heavy thinking on how to protect the data. :-)

May I recap password saving mechanisms to be sure that I got it right? I just focus on saving the passwords not on using them during a session.

1. During install, a unique master key is generated but not stored anywhere on the server (whats the use of creating a master key then? Or has every user an own master key?)
2. when a user is created the master key and the user's password are to be entered
3. the user' password is used to encrypt the master key and this is stored to the data base
4. the user's password is stored as salted hash in the data base, I presume
5. when a user logs in, the master key is fetched from the data base and decrypted with the password provided with the login
6. the decrypted master key is then used to decrypt the actual data from the data base

Is that correct? It it very important for me that there is no way that a compromised server or a compromised data base leads to compromised user data.

[nuxsmin]

Hi, regarding your points:

1. In that step, the master password is only hashed (stored in db config table) and encrypted for the admin's account.
2. When users perform their first login, they will be asked for the master key, so you can tell them the real one or a temporary master key (at the encryption tab).
3. The user's password and login and a salt (got from the config file), but a blowfish derivated key from it is used to encrypt the master key.
4. Sure, the algorithm used is Blowfish (http://php.net/manual/en/function.crypt.php) with a cost of 7 rounds.
5. Partly right, see point 3
6. Right, but the data (accounts passwords and custom fields) are decrypted just-in-time, so the data is decrypted every time is needed.

Please, keep in mind that the highest risk is in the users themselves, because a compromised password could lead in a security glitch. A compromised server could be dangerous if the database is placed with the webserver, because the network data could be sniffed and then the passwords would be revealed.

It's worth to mention that every password field within a form is encrypted by using PKI, so the password data is sent encrypted to the webserver.

[derStephan]

Tank you very much. Keep up the good work.