I have a question about cloudant and data encryption, I’m doing a project, I don't know if I can encrypt the data in cloudant, I did an investigation but I did not find something in particular, someone here knows something about this topic?
Cloundant’s disks are encrypted at rest, and data in flight over https. Data in the database itself during normal operation isn’t encrypted—although it’s perfectly feasible for you to do so in the client. Note, however, if you encrypted the data client-side, Cloundant cannot index your data.
in addition to xpqz's answer, this blog shows how to do client side transformation of Cloudant data for additional encryption outside of "at-rest" and "in-motion"
https://blog.cloudant.com/2018/10/10/Client-Side-Transformation.html
Related
Let's admit this situation: i have a project that involves critical data. Server side is managed by Laravel/Symfony to retrieve, process and store these data.
Data are sent to the server through the API, they are encrypted and finally stored in the database.
My question is: if data are encrypted in my database, can i still retrieve these using a WHERE clause ? I'm thinking about something like On The Fly decryption, but i've found nothing about these terms on Google.
What is the best way to encrypt data in a database to improve data protection ?
The trick is to index the encrypted values, but this does limit what you can search for. You can improve things a bit by normalising the data beforehand, for example by forcing it to lower case before encryption to make matches more likely.
However, this is all academic because rather than reinventing the (potentially complicated and difficult as it may be) wheel, the best way to do this is to use a library that does it for you, and the library you need is CipherSweet by Scott Arciszewski.
With GDPR (General Data Protection Regulation) going into effect tomorrow, I am wondering whether Google encrypts data in their Datastore indexes on GAE. I know that they encrypt data stored in entities but it isn't clear that they encrypt the data in indexes. I can't imagine that this is even possible given that queries would never be able to run on encrypted data. If the indexed data is not encrypted, would this not be considered to make GAE non-compliant with GDPR?
I'm reasonably certain they don't actually. The HIPAA compliance guide specifically instructs you to encrypt PHI before using it as an index key. Here's the full text:
When creating or configuring indexes in Google Cloud Datastore, encrypt any PHI, security credentials, or other sensitive data, before using it as the entity key, indexed property key, or indexed property value for the index. See the Cloud Datastore documentation for information on creating and/or configuring indexes.
I'm assuming this means you need to do your own encryption here, otherwise I'm not sure why they'd mention it. And no, I don't know how a meaningful database index can be built from encrypted data.
Google encrypts and authenticates all data in transit at one or more network layers when data moves outside physical boundaries not controlled by Google, it also has 7 layer type of data encryption. More information about Encryption in Transit can be found here. There's also the Server-Side Encryption in Datastore.
All data in Cloud Datastore is encrypted at rest as documented at https://cloud.google.com/datastore/docs/concepts/encryption-at-rest .
I am looking for a database with HTTP REST API out of the box. I want to skip the middle tier between client and database.
One option I found is a HTTP Plugin for MySQL which operates with JSON format
http://blog.ulf-wendel.de/2014/mysql-5-7-http-plugin-mysql/
Can someone suggest other similar solutions? I want to save development time and effort for some queries.
You really should have a middle layer to sanitize input and prevent unwanted calls deleting or changing your data, IMO.
Since you claim to just be testing, though, the technologies I know off the top of my head that provide REST out of the box are mostly NoSQL. You mention MySQL with that JSON thing, but I imagine that just goes through a JDBC/ODBC layer.
So what I know is:
Solr/Elasticsearch - while not strictly a database, is useful for quickly searchable semi structured data
Couchbase - a distributed document and key value store for JSON documents
Neo4j - Graph database
Certain highly-sensitive information (payment info, usernames, passwords, etc.) should be encrypted before it can be persisted to my database.
Later, that information has to be decrypted in order to be fetched from persistence and used at a later time.
If I use, say, AES256 to encrypt a billing address, I'll still need to store that AES256 key/passphrase in persistence as well.
If the whole point behind encrypting information that is going into a database is to protect that information in case someone hacks into my database, and I'm storing the key to decrypt that same information in the database, then what's the point of encrypting the data in the first place?
If someone hacks into my database, they'll be able to find the persisted key and decrypt any encrypted data they want to anyways.
Am I missing something here?
There is an old saying "Encryption is easy, key management is hard". And that very much applies here.
If you need to store data in an encrypted format (you frequently don't because you only need to hash the data not encrypt it), you do not want the encryption key to be stored in the database. You want the key to be accessible when your applications need to decrypt the data but you don't want people like the DBA that has access to all the encrypted data to be able to get the key. You want to make sure that the key is backed up so that you can recover the data but you don't want those backups to comingle with your database backups. Key management, therefore, becomes a very thorny problem to solve.
In the vast majority of cases, you want to purchase some third-party key management solution that can deal with these contradictions. Just like you don't want to implement encryption algorithms on your own, you don't want to do key management on your own. The folks that attempt to solve key management on their own generally do not succeed.
A better option would be to use certificates and this can easily be done in most RDBMS.
The best option regarding passwords is to hash them. This is a one way hash, and is not decrypted. Basically, when a user logs in, you hash their input password, and compare the hash against the one stored in your db for a match - and a successful login.
Regarding payment information, you will need a random generated private key. Depending on the system and implementation this can be stored a number of different ways.
You can store this in a config file, encrypted using an RSA container for example so it is not readable.
There are other solutions as well.
You can also encrypted db connection strings and the like with the RSA container method above to help prevent anybody actually seeing you db username password your application will use to access the db.
In some project we have very that even our staff is not suppose to have access to. In theory, we have policies to ensure they don't. In practice, we are in Africa and policies don't mean a lot, no matter how strongly you enforce it.
I would like to know is there is a way to encrypt data in your database so:
each user password encrypt and decrypt its own data, and its own data only;
data is decrypted as late as possible in the process to ensure maximum security to the user. Ideally it would be on the client side I guess, but I'd love to hear that it's possible to do some crazy thing I don't know about on the server side.
data is still searchable. Is that even possible?
My first idea was: "if a customer want THAT level of protection, then give him its own hosting on a virtual machine and encrypt the hardrive, then all maintenance must be done with it's allowance".
I can't come up with a fancy strategy just how I've implemented this:
Keep in mind that you have to re-encrypt everything when the user changes his password. I'm using always the same encryption key but the key is encrypted using the user's plaintext password. So I just have to re-encrypt the key. The user's password is stored as a salted hash so nobody can decrypt the key and the data even if he sees the hash.
It works like this:
User enters his plaintext password
Create salted hash
Check if the generated hash matches the one in the database (authentication)
If yes, then decrypt the key for the data using his plaintext password
Decrypt stored data using the key
This won't give you 100% security but improves it.
Here are a few things I can think of:
You should encrypt data stored when it is stored in the and when you read it back. Use a solution that integrates at an RDBMS level rather than the data layer.
For the transport of data to and from the application, use HTTPS web services.
If you have a Desktop application, do not store any data and log files etc locally.
If it is a web app, make the app HTTPS as well.
Security is bound to make the app a little slower than using plain data, but that's the price you will pay.
It really depends on what and where (on the client or server) you are doing with the data.
For example, your application don't need to know the password itself to verify it during authentification. Best practice for this use case is to store only a cryptographic hash (e.g. sha1) of the password and a random salt. That is sufficient to verify it, but giving only the hash and salt, it would take a nearly infinte amount of time to figure out the plain password.
Encryption can be a soultion if you have to exchange data over unsecure channels. But keep in mind that in order to process the data you have to decrypt them. So if de- and encryption is done on the same machine, it's rather pointless. And if decryption is required it doesn't matter how late you are going to do it, because of the key must be given anyway.
You can use encryption to secure the communication between the server and the client, for example. You could even generate messages on the server that only the client will be able to read and vice versa using asynchronous encryption. So once the message was generated on the server and encrypted using the client's public key even the server isn't able to read the message anymore, because of the private key only the client knows is required for the decryption.
What you denfinetly can not solve by cryptography is, when you have data on the server, that the server should be able to read in order to process them but human users unrestricted with priveleages to this server shouldn't.