Secure Confidential Information

Secure Confidential Information

  
OutSystems Platform 9 Bali brings security improvements  over how the Platform stores passwords and settings, in order to make it compliant with the established cryptographic practices.
The improvements are focused on two areas:

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.

The users password hashes will be upgraded when each user logins for the first time after the platform upgrade.
It would be great if we could use the same private key to Encrypt/Decrypt our app settings.

We could have an API with some actions:
- Encrypt()
- Decrypt()
- GetPrivateKey() - if we want to use the same private key on other components like the Crypto API.

I already found the key in the Platform installation folder, so it's not hard to do an extension to use it, but it would be better if there was a system API for this.
What will happen when a database is imported from one outsystems platform to another outsystems platform, will the password hash still be valid? (Where exactly is the salt stored?)


Carlos Henriques wrote:
It would be great if we could use the same private key to Encrypt/Decrypt our app settings.

We could have an API with some actions:
- Encrypt()
- Decrypt()
- GetPrivateKey() - if we want to use the same private key on other components like the Crypto API.

I already found the key in the Platform installation folder, so it's not hard to do an extension to use it, but it would be better if there was a system API for this.
 
That is an excelent ideia. Can you please submit it to the ideias page?

Thank you,
Rui Eugénio
Robert Chanphakeo wrote:
What will happen when a database is imported from one outsystems platform to another outsystems platform, will the password hash still be valid? (Where exactly is the salt stored?)

 
 
 The salt is stored next to the password so everything works regarding the users passwords. However there are still problems with the Confidential Settings because they are private to the environment. If you really want to re-use a database in a different installation please contact the OutSystems Support because that's a scenario that isn't directly supported now... However OutSystems Support can help you if you really need to do this.

Best Regards,
Rui Eugénio
Rui Eugénio wrote:
That is an excelent ideia. Can you please submit it to the ideias page?

Thank you,
Rui Eugénio
http://www.outsystems.com/ideas/Idea_View.aspx?IdeaId=2238 

Done :)



 
Hi there Carlos,

Version 1.5 of CryptoAPI adds a function to obtain the private.key. You can now use the environment's private key with Crypto API !

Based on the information from this post, I have also created a tool which allows you do decrypt the information in server.hsconf (or any other platform-encrypted data) so you can easily recover your passwords.

The tool can be found here:

https://github.com/ardoric/ardo.decrypter/releases

Best regards,
Ricardo Silva
Thanks Ricardo :)

I will upgrade CryptoAPI to v1.5.
There's also a .NET implementation of the tool available now:

https://github.com/ardoric/ardo.decrypter.net/releases

so you can decrypt your hsconf directly on a .net server without having to install java.