Jonathan Posted October 11, 2014 Report Posted October 11, 2014 For example, the enom module stores and displays the account password in plain text. It would add a bit of peace of mind if this could be stored using some sort of two-way encryption like mcrypt perhaps and then obviously displayed as a password field and not plain text. This would probably be a pretty minor fix. Quote
Michael Posted October 11, 2014 Report Posted October 11, 2014 +1 would be nice if it was bcrypt & SHA256 or something which Blesta uses Quote
Jonathan Posted October 11, 2014 Author Report Posted October 11, 2014 +1 would be nice if it was bcrypt & SHA256 or something which Blesta uses To my knowledge bcrypt isn't reversible. Whatever is used has to be reversible since the password has to be sent to the API as the password, not an ecrypted value. Quote
Michael Posted October 11, 2014 Report Posted October 11, 2014 To my knowledge bcrypt isn't reversible. Whatever is used has to be reversible since the password has to be sent to the API as the password, not an ecrypted value. Blesta has a decryption for their sort of encryption things so they can use what they do for fields and card details Quote
Paul Posted October 11, 2014 Report Posted October 11, 2014 Service meta data (service_fields table values) can be encrypted with AES256. The module controls this, and an example is the cPanel module, which encrypts cPanel passwords. I believe module row data can also be encrypted, but Cody or Tyson will need to confirm. Michael 1 Quote
Jonathan Posted October 11, 2014 Author Report Posted October 11, 2014 Service meta data (service_fields table values) can be encrypted with AES256. The module controls this, and an example is the cPanel module, which encrypts cPanel passwords. I believe module data can also be encrypted, but Cody or Tyson will need to confirm. Great! Then I guess my request is even easier: lets make this default for the key/password field in the enom module in the core release so I don't have to merge changes every release. It's a better default setting anyway, why not secure anything powerful since the ability is already there and sounds so easy to use. A tad bit of overhead for decryption here is not a bad tradeoff for immensely better storage of such credentials. Quote
Michael Posted October 11, 2014 Report Posted October 11, 2014 Service meta data (service_fields table values) can be encrypted with AES256. The module controls this, and an example is the cPanel module, which encrypts cPanel passwords. I believe module row data can also be encrypted, but Cody or Tyson will need to confirm. That's it haha AES256, can maybe all modules on Blesta encrypt the passwords with it mate? Quote
PauloV Posted October 11, 2014 Report Posted October 11, 2014 For example, the enom module stores and displays the account password in plain text. It would add a bit of peace of mind if this could be stored using some sort of two-way encryption like mcrypt perhaps and then obviously displayed as a password field and not plain text. This would probably be a pretty minor fix. Blesta does able to encrypt every field with a simple modification For exemple the Private Notes encrypted that we have relesed or the openSRS modules, aldo has the keys and salti hash encrypted o database Quote
domaingood Posted October 11, 2014 Report Posted October 11, 2014 I think add API Key password (encrypted) and IP allow option Thank you PauloV 1 Quote
Cody Posted October 13, 2014 Report Posted October 13, 2014 The enom module already encrypts the API key. The only other module data stored is the username and whether or not sandbox should be used. Neither of which need to be encrypted. It's important to keep in mind that encrypted text is unsearchable. Quote
Jonathan Posted October 14, 2014 Author Report Posted October 14, 2014 Hmm looks like you're right. The display of it in plain text threw me. Would love it if the text box for the field could be converted to type="password". Quote
PauloV Posted October 14, 2014 Report Posted October 14, 2014 The enom module already encrypts the API key. The only other module data stored is the username and whether or not sandbox should be used. Neither of which need to be encrypted. It's important to keep in mind that encrypted text is unsearchable. I think its because the <input type="text" and i should be <input type="password" that is not available in the core funtion the type "password" (I have tried in Blesta 3.1 for the InternetBS Module and I saw that is not available the type password) Quote
Cody Posted October 14, 2014 Report Posted October 14, 2014 I think its because the <input type="text" and i should be <input type="password" that is not available in the core funtion the type "password" (I have tried in Blesta 3.1 for the InternetBS Module and I saw that is not available the type password) That's not true. <?php $this->Form->fieldPassword("field_name", array('value' => "field_value")); ?> PauloV 1 Quote
PauloV Posted October 17, 2014 Report Posted October 17, 2014 That's not true. <?php $this->Form->fieldPassword("field_name", array('value' => "field_value")); ?> You are right Cody I have found what I did rong In the past I had try like this: $this->Form->fieldPassword("hashkey", $this->Html->ifSet($vars->hashkey), array('id' => "hashkey")); And as you can see I only changed the "fieldText" to "fieldPassword", and I can see its not complete (beginners, that didnt saw correctly the blesta classes) and the correct id add an Array to the "types" like so: $this->Form->fieldPassword("hashkey", array('value' => $this->Html->ifSet($vars->hashkey), 'id' => "hashkey")); And voila its working Alredy implemented in all our Modules/Plugins that asks for sensitive data Thanks cody for clarifing that, and sorry to misleading people Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.