Encryption

Warning

If you already use a sysPass version <= 2.0, it’s advisable to update to 2.1 version and then to 3.0, in order to use the new security improvements on the encryption mechanisms (CVE-2017-5999)

sysPass encryption is based on AES-256 in CTR mode by using PHP’s OpenSSL module. It uses the Defuse/php-encryption library for the encryption modules and functions management.

The encrypted data (up to 3.0 version) are:

  • Accounts’ passwords (always)
  • Accounts’ public links (always)
  • Custom fields’ data (if set)
  • sysPass XML format export (if set)
  • PHP’s session data (if set)

In order to use the application, for every user first login, either a master password or a temporary master key (see Temporary Master Key) will be needed. That is so because the master password is not stored in the web server but a a generated Blowfish hash is saved in order to check if the user is using the correct master password.

After logging in with the master password, it’s encrypted and stored within the user’s data in the database. The encryption key is generated using a derived key from user’s password and login, and a secure random salt generated by openssl_random_pseudo_bytes (stored in “config.xml” file).

On next user logins the master password is got from the user’s data and decrypted by using the derived key. After this, the master password is encrypted again for storing it in the user’s PHP session, so every time the master password is needed it must be decrypted using a session-based generated key. This key is regenerated every 120 seconds.

The master password will be prompted again if:

  • The user changes its login password. The previous password will be requested.
  • It has been changed by the administrator.
  • The user changes its login username.
  • The configuration salt is changed.

Note

A temporary master key (see Temporary Master Key) could be used instead of the real master password

Temporary Master Key

A temporary master key could be generated to be used by the application users, so it won’t be needed to tell the real master password.

For the temporary master key generation the real master password is encrypted using a secure key generated by openssl_random_pseudo_bytes. Then a Blowfish generated hash of it is stored in the database “”Config” table.” in order to check it when the temporary master key is provided on login.

Note

The real master password is never stored unencrypted. For checking the temporary master key a Blowfish generated hash is only used

PKI-RSA

In order to improve the security of the sent data, RSA (PKI) is being used for encrypting the passwords that are being sent from the application forms. This prevents to send sensitive date through plain channels.

Public and private RSA keys are generated within the application “config” directory.

Diagrams

Login Process

@startuml

start

:Login;

:Get user data;

:Retrieve the encrypted master key;

note right
  Generated a secure key protected by a password using:
  password + login + hash
end note

if (Does it have the key saved?) then (Yes)
  :Decrypt the master key;
else (No)
  :Login;

  :Request master key;

  if (Is it a temporary master key?) then (Yes)
    :Verify;
  else (No)
    :Verify master key;
  endif
endif

:Encrypt and save in the user's session;

note right
  Generated a secure key protected by a password using:
  session_id + sid_start_time
end note

stop

@enduml

Master Password Process

@startuml

start

:New master key;

:Begin SQL transaction;

:Decrypt accounts
and encrypt them again;

:Decrypt accounts history
and encrypt them again;

:Decrypt custom fields
and encrypt them again;

if (Is there any error?) then (Yes)
  :Rollback transaction;

  :Display error and finalize;
else (No)
  :Finalize SQL transaction;

  :Generate a Blowfish hash an save it in the DB;

  note right
    Saved in the config table.
  end note

  :Update generation date in the DB;

  note right
   It forces to all users to change the master key
  end note

  :Send email;
endif
stop

@enduml

Temporary Master Key Process

@startuml

start

:Retrieve the master key from the session;

:Generate password protected key for
encrypting the master key;

note right
  Generated from a password using:
  random_hash + config_salt
end note

:Save encrypted in the DB;

note right
 Saved in the config table.
end note

:Generate a Blowfish hash and save it in the BD;

note right
 Saved in the config table.
end note

:Display the encryption key
in the current session;

note right
 It's deleted on log out
end note

:Send email;

stop

@enduml

PKI Process

@startuml

== Initialization ==
Client -> Server: Requests environment data within PKI
Server --> Client: Sends the public key

note right
  Key pairs (public and private)
  are created if not exists
end note

== Sending form data ==

Client -> Server: Sends password data encrypted

note left: Using public key within Javascript

Server --> Client: Decrypts the password, stores it and sends response

@enduml

Warning

Be aware that the highest security risk is in the users themselves, because a compromised password could cause a security leak.

A sysPass compromised server could be dangerous if the database is placed alongside the web server, because the network data could be sniffed so the passwords would be revealed.