Users Password Hashing

As with all previous platform versions, the password column of the User entity never contains the user password.

Passwords are salted and hashed before being stored in the DB. Each password has its own salt, which is a 32 bytes random number. Salts are generated using a random number generator, seeded with a source of high-entropy, which generates secure random numbers, when the password is stored in the DB for the first time.

The hash algorithm is the SHA-512, but it can be seamlessly changed in the future, as the algorithms became deprecated due to the ever growing generalized computational power.

Finally, passwords are stored in the DB using a mechanism that relies on the algorithm version, the password’s salt, the computed password hash and some limiters that eases our parsing.

Notes:

1. Passwords hashed with the new algorithm can be distinguished from the ones hashed with the former algorithm, by looking at the first byte, which should be ‘$’.  

2. Since we don’t known the users passwords, their hashes aren’t changed when upgrading. We upgrade the user password hash when that user logs in for the first time.

Confidential Settings

There are some settings that need to be stored by the platform in order for it to operate correctly. Some of those settings contain confidential information. Examples of those settings include: database credentials (both the platform database and any external database integration), email server password, eSpace Run As credentials, etc.).

In the OutSystems Platform 9 Bali those settings are encrypted with AES, with a 128-bit, in CBC mode and PKCS7 padding mode and their SecretKey is generated during the platform installation and stored in a private file in the server.

Finally, all these settings are stored using a mechanism that relies on the algorithm version, an initialization vector for the algorithm (commonly called IV, generated using a secure random number generator seeded with a source of high-entropy), the encrypted setting and some limiters that eases our parsing.

Notes:

1. The SecretKey used by the encryption algorithm is private and different for each environment. This makes it imposible to get the original information without the private key since each environment has it's own.  

2. The SecretKey is stored in the filesystem. So, in a event where the database is compromised, your information is still safe, as long as the attacker can't get access to the filesystem (which is usually much harder to get to). 

What do I do to start using those improvements?

Good news! You don’t have to do nothing at all.

With the upgrade to the OutSystems Platform 9 Bali, the encryption of the confidential settings will be upgraded automatically to the new security schema.