I need to use sensitive data with Drupal for a custom module to use. If I simply set them through the GUI, they will be stored unencrypted in the database. Anyone having access to it will have access to my sensitive data.
I can see two solutions for the moment:
Find a way to securely store those credentials into the database;
Put those sensitive data into a credentials_inc.php file, include it in settings.php to set variables my custom module could use and make sure that nobody else can read the file.
Which solution is best according to you? What do you recommend? Is there any other best option?
Best regards.
I would start off by using SecurePages module, to make sure the data entered somewhere along the way is not snooped.
Then to encrypt the information try using php's mcrypt with a short example of how to encrypt and decrypt.
Once the information is secured, you should have no problem storing the data in drupal's db structure. Also, an important note, you might check out hook_init() instead of trying to append something in settings.php. That is in general a bad practice.
The Encryption module provides an API that supports a few different encryption methods, including mcrypt (if you have it enabled).
The Encryption module is an excellent way to encrypt sensitive data within Drupal. However, this module does not provide adequate key management (it stores the encryption key within the Drupal database - like storing the keys to your house under your Welcome mat).
Along with Encrypt, you will also need an additional module like Townsend Security Key Connection which allows you to manage the encryption keys outside of the Drupal database in an encryption key manager (HSM, Cloud, VMware, etc.). Just remember - if you aren't properly managing your encryption keys, you aren't properly encrypting your data.
Full Disclosure: I work with Townsend Security on the Drupal team.
Related
Right now the only way to encrypt a Cassandra database at rest seems to be with their enterprise edition which costs thousands of dollars: How to use Cassandra with TDE (Transparent Data Encryption)
Another solution is to encrypt every value before it enters the database, but then the key will be stored somewhere on every server in plaintext and would be easy to find.
I understand they offer "free" use for certain companies, but this is not an option and I am not authorized to pay $2000/server. How do traditional companies encrypt their distributed databases?
Thanks for the advice
I took the approach of encrypting the data disk on AWS. I added a new volume to the instance and checked the option to encrypt the volume. Then I edited cassandra.yaml to point to the encrypted volume.
We have done similar requirement in one of our project. Basically, I made use of trigger feature in Cassandra with custom implementation to perform encryption. It seems to be working fine for us.
You can refer below docs on how to create trigger and sample implemention of ITrigger interface
https://docs.datastax.com/en/cql/3.3/cql/cql_reference/cqlCreateTrigger.html
https://github.com/apache/cassandra/blob/2e5847d29bbdd45fd4fc73f071779d91326ceeba/examples/triggers/src/org/apache/cassandra/triggers/AuditTrigger.java
Encrypting before inserting is a good way. The keys will either be on each application or on each cassandra node. There isnt much difference really, either way you should use filesystem permissions to restrict access to key just the apps user. Theres steps to get more secure from there like requiring entering of passphrase on startup vs storing on disk, but it makes operational tasks horrific.
I want to store an API key for a service that the WordPress plugin I am developing needs to get information from an API. There are two options that I am aware of:
1) WordPress's options mechanism
2) Create a new database table
As far as I can tell, at the end of the day both are the same in that they are storing the information in a MySQL table and that data could potentially be accessed by another plugin.
Is there any way to store data so that it cannot be read by other plugins?
Is this even a concern I should be worried about?
A plugin can potentially dump your entire database and send it to it's authors through email, so one way or other to store it's pretty much useless.
This boils down essentially to 2 things, store it in an external database, where just your plugin have access to that or just do a two-way encode/decode with a salted key so your plugin it's the only thing can decrypt it.
If database access from other plugins is still a concern then store the API key within your PHP file. It won't be replaceable but you can take MySQL off the list.
On a personal opinion unless you are installing the worst and least known plugins on Wordpress you probably should be quite confident about the security of your website. To be fair probably caring about an API key to be stolen is the least concerning thing when you have someone that could access all your user details and passwords and potentially FTP access to your server.
We are going to store some sensitive information about our customers in the db model res_partners.
However we don't want to store this information in a simple text field. We would prefer
some basic encrypting if possible for those fields. We do not want someone who
has access to the db to have access to these fields.
Is there a way we can get this done in openerp or postgres ?
Thank you,
Vishal Khialani
There is no such thing as "basic" encryption. Rot13 is not getting to get you anywhere here. If your data is sensitive enough to deserve protection, then you need to use state of the art cyphers such as Blowfish. I advise you give a good long look at Bruce Schneier's book Applied Cryptography
The easy (and insecure) way to achieve this is to overload the write and read methods of your model to encrypt before writing and decrypt after reading.
The tricky part is storing the encryption key. You could store it in a file on the computer running the OpenERP server (assuming the database is running on another server). This is still pretty weak, as the key will be available in clear on the server, but could still be useful if you don't trust your database server admin, but do trust you openerp server admin. It's still way easier to get the database server in a secure and trusted place, and if required to crypt offline copies of the database (such as backups).
If you want more security, you'll have to send the data encrypted to the client application, and let the decryption happen there, using a user-supplied key. I'm not enough knowledgeable of this part of openerp to say if it is easily feasible or not.
I need to use one of the encryption algorithms say DES encryption to store all the data in my Drupal database. Is there a way I can do that? Based on my understanding there needs to go some encrypt/decrypt functions in all database calls from the code?
Have a look at http://drupal.org/project/encrypt it might be worth a try.
Encrypt
Encrypt is a Drupal module that provides an application programming
interface (API) for performing two-way data encryption. It allows
modules to encrypt data such that it can be decrypted using the same
key that was used to encrypt the data. This is useful for storing
sensitive information.
There is no native way to do two-way encryption in Drupal. There is
also not a very standard way of performing encryption in PHP without
extensions. This module aims to make it easy for other modules to keep
data secured in an extensible way that does not inherently require any
other dependencies.
What are your thoughts about SQL Server's symmetric key functions? Specifically, I have two questions:
Which set of functions is better... EncryptByKey or EncryptByPassPhrase?
Both functions require a passphrase of some kind. In a typical web-application architecture, where should this passphrase be stored? (i.e., hard coded within a stored procedure in the database, or stored as a configuration setting in the web application)
I'm eager to see what the best practice is for these functions.
Encrypting using a passphrase is easier but the advantage of using a key is that the key can be secured using built in SQL sever roles. You can lock down use of the key to only those users that require access to that data.
If you use a certificate then you only need plain text during the initial setup and can store it outside your system. Again, the certificate is a securable object and can be locked down.
Hope this helps.