Encryption In Blesta

[L3Y]

Hi,

I have a question about the Encryption  : http://docs.blesta.com/display/user/Encryption

 

Let's say we encrypt our data.

 

Is it still possible for us to go 100% custom later ?  I mean : is it possible for us to migrate to another platform? 

 

Is there any way to get back our data as it was before in case if we see problems?

 

What if we require to change the encryption passphrase someday - how can this be done?

 

I know we can migrate from whm** and get back our encrypted data.  I know Blesta is far better on this.  I'm affraid we may not be able to get back our data if we use this feature. 

Someone can tell me more about this?

 

Thank you,

Carl

 

 

[Michael]

Blesta encryption is only available on Blesta, if you try and move to other systems then you will need to crack the Blesta encryption which is next to impossible. But why would you leave Blesta anyway?

[Paul]

Blesta is transparent about encryption and what algorithms are used. You will always be able to decrypt your data, with the exception of hashed data, like passwords which are bcrypted HMAC-SHA-256 hashes and are not reversible, even by Blesta.

 

So yes, you can get your data out.

[Jonathan]

+1 for transparency :)

[L3Y]

Hi,

 

Thank you.

 

But can you please clarify more how i can recover the data once it's encrypted?

 

This is an important point : before you encrypt your data, to make sure at 100% you will be able to decrypt it! 

 

 

Thank you,

 

Carl

 

 

 

Blesta is transparent about encryption and what algorithms are used. You will always be able to decrypt your data, with the exception of hashed data, like passwords which are bcrypted HMAC-SHA-256 hashes and are not reversible, even by Blesta.

 

So yes, you can get your data out.

[Tyson]

Recovering encrypted data requires your system key (stored in your Blesta config file). Without it, the data is unrecoverable. Additionally, if you set a private key passphrase, certain encrypted data (e.g. credit card numbers) will need that entered as well to decrypt data.

 

"How" to recover the data depends on your situation and what you're trying to do. Blesta already provides methods of decrypting data via the interface, such as to view a credit card number, which occurs automatically. If you want to decrypt all system data, for example, it may be best to write a short custom script to do so. If Blesta is still installed when you want to do this, you can have a developer call AppModel::systemDecrypt on each encrypted field.

[L3Y]

Hi,

 

What if i don't want all the suggested fields to be encrypted, but only some of them.

 

...is there any ways for me to choose what i want to encrypt?

 

Also : do you think it may be possible for us to add a password field to the database backup feature?  

 

I mean : we need a password to modify some fields in the admin, but we don't require any password to export the database

 

I think it would me much better to ask for a password to export it, and also ask for another password if you require to decrypt the db, to work a little on your data. 

 

What if someday a disaster happen and we require to do a quick change on our encryption key?

 

Thank you for reading, and taking a couple minutes of your precious time to answer me  

Cheers and long life to Blesta  : i'm already addicted to this little smiley :  

 

Carl

[Paul]

Hi,

 

What if i don't want all the suggested fields to be encrypted, but only some of them.

 

...is there any ways for me to choose what i want to encrypt?

 

Also : do you think it may be possible for us to add a password field to the database backup feature?  

 

I mean : we need a password to modify some fields in the admin, but we don't require any password to export the database

 

I think it would me much better to ask for a password to export it, and also ask for another password if you require to decrypt the db, to work a little on your data. 

 

What if someday a disaster happen and we require to do a quick change on our encryption key?

 

Thank you for reading, and taking a couple minutes of your precious time to answer me  

Cheers and long life to Blesta  : i'm already addicted to this little smiley :  

 

Carl

 

What data specifically are you concerned about? Blesta encrypts a lot of things by default, but modules can also control what they want to store encrypted so there is flexibility there. We don't use any secret proprietary encryption algorithms, it's all open so the data can be decrypted, with some effort.

 

The database backups area in the settings should be restricted for staff groups that you don't want to have access. Under Settings > Staff > Staff Groups, edit the staff groups and remove permissions for those that should not have access. Without access, they will not be able to change the settings or generate a backup manually.

 

The encryption key currently should not be changed, but a utility that would allow you to re-crunch all of your encrypted data with a new key would be a good idea, it just hasn't been a high priority yet. A passphrase can be set for batch credit card processing, and the passphrase can be changed or removed without affecting the encrypted data.

 

Cheers!

[L3Y]

So if i understand correctly this feature will only encrypt the key i have in /config/blesta.php

 

...then should i require to export the data, and the passphrase is set, i only need to decrypt the key using the passphrase, and then decrypt the data using  AppModel::systemDecrypt 

 

Sounds good.  

 

I am looking at our database : most of the fields are encrypted, even without the passphrase.

 

But  : what if a Blesta customer need to perform a quick security audit on he's database?  He will only see encrypted data.  What if there is a hack somewhere, in those encrypted fields? 

 

Most serious solutions deliver a tool to decrypt the database : https://support.office.com/en-ie/article/Encrypt-a-database-by-using-a-database-password-fe1cc5fe-f9a5-4784-b090-fdb2673457ab#bm3

 

There is nothing to worry about allowing your customers to manage their data.  You'll be creating trust by doing this, because you know you don't have to be afraid : your customer like Blesta, and they will stick to it.

 

This is not only a question of being able to switch to another solution : it's a security question.

 

If you provide a feature to easily encrypt, you should also provide a feature to easily decrypt.

That's my opinion      Thank you for reading! 

 

Cheers!

Carl 

[mrrsm]

I am looking at our database : most of the fields are encrypted, even without the passphrase.

 

But  : what if a Blesta customer need to perform a quick security audit on he's database?  He will only see encrypted data.  What if there is a hack somewhere, in those encrypted fields? 

What fields do you think shouldn't be encrypted that currently are?

Looking through my database only sensitive data has been encrypted such as credit card info.

 

From my going through the code for blesta it doesn't seem like they are storing php code and executing it out of the database so I don't see a worry there.  The only thing may be XSS or javascript injection which I haven't tried but I am going to guess the Blesta team tests for so I don't need to worry too much about that.

[Tyson]

Most serious solutions deliver a tool to decrypt the database : https://support.office.com/en-ie/article/Encrypt-a-database-by-using-a-database-password-fe1cc5fe-f9a5-4784-b090-fdb2673457ab#bm3

 

I've never used Microsoft Access personally, but from your link, it sounds like it simply encrypts/decrypts your entire database using your passphrase. Blesta encrypts some individual fields in the database, but not the entire database. The two are very different.

 

 

But  : what if a Blesta customer need to perform a quick security audit on he's database?  He will only see encrypted data.  What if there is a hack somewhere, in those encrypted fields? 

I'm not sure what kind of security audit you're referring to, but I imagine that seeing password fields and credit card information as encrypted text is the expected result of a security audit. If there were a "hack" stored in an encrypted field, then you have vulnerabilities elsewhere that require attention.

 

 

If you provide a feature to easily encrypt, you should also provide a feature to easily decrypt.

 

Encryption occurs internally to Blesta. There is no separate solution crafted for the purpose of encrypting/decrypting data outside of Blesta. Such a solution would require knowledge of its presumed use, which is knowledge we don't possess.

[L3Y]

Hi,

 

Not that i want to argue with you on this, but...

 

How can i make it quick and easy to see if there is a major problem somewhere if i cannot decrypt the whole database, and look at it's content?  How can i know if there was some code injected in the database?  I understand Blesta peoples thought about protections on this, but if there was injections in framework like Rails, then there may be the same on other frameworks (a LOT harder to find, but still : everything is possible). In such case, or if there is a validation missing somewhere and someone is able to save corrupted data in the database, then we may never see it.

 

That being said, i can see Blesta have nothing to hide on this.  That's what i like : 

// Handle decrypting/encrypting the private key
$rules['private_key'] = array(
'empty' => array(
'rule' => "isEmpty",
'negate' => true,
// Decrypt the old passphrase whether it be with a previous passphrase or the default passphrase
'pre_format' => array(array($this, "systemDecrypt"), !empty($vars['current_passphrase']) ? $vars['current_passphrase'] : null),
// Encrypt the private key with the new passphrase or the default passphrase if not set
'post_format' => array(array($this, "systemEncrypt"), !empty($vars['private_key_passphrase']) ? $vars['private_key_passphrase'] : null)
)
);

...looking at this, i am wondering why WHM** developer warned me about Blesta, because in case if something happen and i use the systemEncrypt function, they won't be able to decrypt the database and help on a migration.  He said he tried, a lot to decrypt it, but he cannot create an import plugin that work if the db is encrypted    As far as i can see until now, the problem don't seems to be on Blesta side, but on whmcs dev. side 

 

I suggest if you are just afraid to help them to create an importer if you provide a way to decrypt the database, to simply Ioncube this tool.  

[Paul]

...looking at this, i am wondering why WHM** developer warned me about Blesta, because in case if something happen and i use the systemEncrypt function, they won't be able to decrypt the database and help on a migration.  He said he tried, a lot to decrypt it, but he cannot create an import plugin that work if the db is encrypted    As far as i can see until now, the problem don't seems to be on Blesta side, but on whmcs dev. side 

 

I suggest if you are just afraid to help them to create an importer if you provide a way to decrypt the database, to simply Ioncube this tool.  

 

I would be curious to see exactly what they told you. If you're up for it, please PM me or email sales (will go to me).

 

We are very transparent about how we do encryption. Our competitor has historically implemented custom caesar ciphers for things like client passwords (I think they changed this fortunately) which are incredibly weak. Blesta uses strong encryption, but there's nothing secret about it. All of the encrypted data can be decrypted (with the exception of passwords which are one way bcrypt hmac sha-256 hashes). I can't say I'm surprised they had trouble though. 

[Michael]

I would be curious to see exactly what they told you. If you're up for it, please PM me or email sales (will go to me).

 

We are very transparent about how we do encryption. Our competitor has historically implemented custom caesar ciphers for things like client passwords (I think they changed this fortunately) which are incredibly weak. Blesta uses strong encryption, but there's nothing secret about it. All of the encrypted data can be decrypted (with the exception of passwords which are one way bcrypt hmac sha-256 hashes). I can't say I'm surprised they had trouble though. 

 

I love it haha they can't make one so it makes my day

[mrrsm]

I suggest if you are just afraid to help them to create an importer if you provide a way to decrypt the database, to simply Ioncube this tool.  

 

Why would Blesta want to make an importer for another company to let a customer move away from Blesta?

 

There are a couple plugins that store and extract encrypted data into the database floating around the forums so there are plenty of people who figured out how to do this programmatically.

 

If the developer you are working with is having that much trouble I would suggest looking for a new developer to do this task for you.

 

A couple things to note:

1) You can't import directly from a database dump without having the system key. (If you have it you would just need to know what was encrypted and it shouldn't be that hard)

2) Blesta has a pretty good api that can get you most of the data you would need (the api supports decrypting and encrypting data (only some fields) I believe and if not you can add api calls to do just that)

 

 

How can i make it quick and easy to see if there is a major problem somewhere if i cannot decrypt the whole database, and look at it's content?  How can i know if there was some code injected in the database?  I understand Blesta peoples thought about protections on this, but if there was injections in framework like Rails, then there may be the same on other frameworks (a LOT harder to find, but still : everything is possible). In such case, or if there is a validation missing somewhere and someone is able to save corrupted data in the database, then we may never see it.

What is the size of your database, 1 or 2 clients with no plans to grow?  I can't even imagine going through an even remotely large database by hand trying to see if something was wrong.  As long as your database isn't corrupted (which would be a whole different issue) you should be able to view all of the data in the admin area and fix any bad data that exists for that one customer.

 

You have to have some level of trust with the software you are using.  Trusting that they are properly handling use data, encrypting, protecting from exploits, and more.  If you don't feel that a company has the same interests on security (or anything else for that matter), that company may not be a good fit for you.

[L3Y]

I would be curious to see exactly what they told you. If you're up for it, please PM me or email sales (will go to me).

 

We are very transparent about how we do encryption. Our competitor has historically implemented custom caesar ciphers for things like client passwords (I think they changed this fortunately) which are incredibly weak. Blesta uses strong encryption, but there's nothing secret about it. All of the encrypted data can be decrypted (with the exception of passwords which are one way bcrypt hmac sha-256 hashes). I can't say I'm surprised they had trouble though. 

 

Hi Paul,

 

I tried to find the ticket, but i can't.  I've had lot of tickets open with them.  I.e. :  terminate / suspend a customer may delete another account, + all data on the server.   haha.

 

It was just before i closed a ticket, i've asked something like "let's say i decide to try another provider, Blesta, do you have an import tool if something turn bad?"

 

And the reply was something like "Some may say we are not good developers because of this, but we are simply unable to decrypt the database in Blesta.  We tried many times, but we can't".

 

Concerning encryption, it's for security reasons. i think it may be useful to provide your users with a way to update or change the encryption passphrase, and/or perform security audits on their data.   

 

For example : Whm** do not provide any way to change the encryption key, but they provide a whmcs to whmcs migration plugin you can use to migrate the install to another, while changing the key. - please note i did not liked this idea,   There was bugs / missing data after.

 

I suggest to allow this option only through the command line for better security.  A tool like drush for Drupal would be nice to manage this side of Blesta (and updates) : https://github.com/drush-ops/drush

 

 

 i'm dreaming of  :

apt-get install blesta-manage-encryption

...and then 

blesta-manage-encryption /var/www/index.php --decrypt 
#please enter your password: 

[Paul]

 

Hi Paul,

 

I tried to find the ticket, but i can't.  I've had lot of tickets open with them.  I.e. :  terminate / suspend a customer may delete another account, + all data on the server.   haha.

 

It was just before i closed a ticket, i've asked something like "let's say i decide to try another provider, Blesta, do you have an import tool if something turn bad?"

 

And the reply was something like "Some may say we are not good developers because of this, but we are simply unable to decrypt the database in Blesta.  We tried many times, but we can't".

 

Concerning encryption, it's for security reasons. i think it may be useful to provide your users with a way to update or change the encryption passphrase, and/or perform security audits on their data.   

 

For example : Whm** do not provide any way to change the encryption key, but they provide a whmcs to whmcs migration plugin you can use to migrate the install to another, while changing the key. - please note i did not liked this idea,   There was bugs / missing data after.

 

I suggest to allow this option only through the command line for better security.  A tool like drush for Drupal would be nice to manage this side of Blesta (and updates) : https://github.com/drush-ops/drush

 

 

 i'm dreaming of  :

apt-get install blesta-manage-encryption

...and then 

blesta-manage-encryption --decrypt 
#please enter your password: 

 

 

That is funny. 

 

I get what you're saying, and I suspect we will have a method to change the private key in the future.