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.
Related
I have an SQLite3 database that I need to secure.
I'm confused between using sqlcipher to encrypt the whole database that I use in my Electron app or simply encrypt the data using crypto dependency.
Any clarification or explanation would be welcome.
There are two different types of encryption: "encryption at rest" and "row level encryption".
What if someone gets access to your SQLite file? They have all your data. "Encryption at rest" protects you against this by encrypting the SQLite file itself. If someone steals your SQLite file it will be useless to them. sqlcipher provides encryption at rest. This is a good idea in general.
What if someone hacks into your application and injects SQL commands? What if they select all your customer data? It doesn't matter if the file is encrypted, the SQL connection will decrypt it. To protect against this you can add a layer of "row level encryption". This is where your application encrypts the data it writes and decrypts the data it reads. The data being stored is encrypted. This is more complicated and has more performance impacts. Since the data is inserted encrypted, it is more difficult to search and index. Use it only for very valuable data that you're not likely to have to search. You're better off securing your application against SQL injection in general.
Folks,
I need to encrypt some string data into a SQL database from and MVC Core 2.0 application.
I'm thinking of using the Data Protection API with PersistKeysToFileSystem so that I can restore the data to another server and decrypt the data using the same key file.
I am impressed with the performance of the DPAPI in Net core and I don't want to fo for any custom crypto solution as its too risky. I would be storing bulk uploads of data to SQL. Strings before encryption would be 200 chars or less.
I believe that DPAPI is considered more suited to encrypting small pieces of data e.g. passwords as opposed sql bulk operations. Do folks consider using DPAPI to encrypt data into a database a good use case?
The Data Protection API is not necessarily only for small pieces of data, but it is meant for relatively transient data. In other words, it's not really intended to be used to encrypt/decrypt long-term. The keys will be cycled at some point, and while old keys are kept around to allow for transition to new keys, you should not really rely on that.
According to the docs:
The ASP.NET Core data protection APIs are not primarily intended for indefinite persistence of confidential payloads. Other technologies like Windows CNG DPAPI and Azure Rights Management are more suited to the scenario of indefinite storage, and they have correspondingly strong key management capabilities.
It does go on to say that you can do so if you desire, though. However, things have to be handled in a different way if you might potentially be working with revoked keys. The documentation link above goes into all the detail on that. However, bear in mind that you're inherently operating on your data in a less secure way, since you're explicitly allowing revoked keys to be used to decrypt data.
Does anyone know about what type of encryption is used to store data securely on CouchDB? How one can change/control this encryption mechanism for data security on CouchDB?
CouchDB does not encrypt data at rest (except passwords, by way of a PBKDF2 one-way hash).
It does allow the encryption of data in transit, by use of HTTPS, but for at-rest encryption, your options are:
Device/filesystem-level encryption. This is handled by your OS, and is completely invisible to CouchDB (and all other apps).
Application-level encryption. You can have your application encrypt data before marshaling it to JSON for storage in CouchDB. The crypto-pouch plugin is one example of this, which works for PouchDB (Note: I've never used it, so can't vouch for its usefulness).
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 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.