For a security application I want to do the following:
Each data related to a user is encrypted with this user's key (the key is unique for each user).
The only data that are not encrypted are password (because it's already hashed, no need to crypt it on top of that), email (identifier for login) and the key (to decrypt data on server side).
The goal is to make data storage safe even if my database gets full dumped, since the attacker will have to find which algorithm(s) is used for the encryption, for each user, even if he has the key.
I'm making a RESTful API connected to this database, and I want to use Spring Data neo4j + spring Rest and Spring boot (just going to do API mapping by myself, since all my attempts to let spring generate API implementation failed).
So, the real question is How to encrypt/decrypt data in SDN's transactions? I mean I need to store data encrypted, and return it decrypted, so I need to be able to encrypt it on Java side.
If I can't do it with SDN, I'll do it using Neo4j Core API instead, just wanted to give SDN a chance since it can be really time saver.
Related
I need to store OAuth token, and various quite sensible user information data into my firestore. I've learned that Firestore is safe and that they already encrypt data, should I do it still ?
If I do it, I'll use a key stored in .env to encrypt / decrypt data via a aes-256-cbc cypher but I think it might be overkill...
PS. I use Next.js API Routes
Encrypting the data is entirely optional and doable, but the practicality of doing so far exceeds the actual usefulness of any encryption implementation.
The data is already transferred securely via HTTPS and decoded on the client. If you were to encrypt the data, any information to decode the data would also be available from within your app, making the encryption redundant.
The only reasonable risk is if the clients' device is compromised, hackers can access the decrypted data directly but that is not feasible to prevent.
We are building a multi-tenant cloud-based web product where customer data is stored in single Database instance. There are certain portion of customer specific business data which is highly sensitive. The sensitive business data should be protected such that nobody can access it except the authorized users of the customer (neither through application not through accessing Database directly). Customer want to make sure even the platform provider(us) is not able to access specific data by any means. They want us to clearly demonstrate Data security in this context. I am looking for specific guidance in the following areas:
How to I make sure the data is protected at Database level such that even the platform provider cannot access the data.
Even if we encrypt the Data, the concern is that anyone with the decryption key can decrypt the data
What is the best way to solve this problem?
Appreciate your feedback.
"How to I make sure the data is protected at Database level such that even the platform provider cannot access the data"
-- As you are in a Multi-Tenanted environment, First of all you would have to "single tenant your databases" so one DB per customer. Then you need to modify the application to pick up the database from some form of config.
For encryption as you are in Azure you would have to use the Azure Key vault with your own keys or customer's own keys. you then configure SQL to use these keys to encrypt the data. see here and here
if you want the database to stay multi-tenanted, you would need to do the encryption at the application level. However this would need the application to know about customer keys, hence I dont think that this would be a valid solution.
"Even if we encrypt the Data, the concern is that anyone with the decryption key can decrypt the data" - yep anyone with the keys can access the data. For this you would need to set the access controls appropriately on your key vault.. so the customer can see only their keys.
In the end as you are the service provider.. the customers would have to trust you some what :)
In light of the upcoming GDPR regulations, the company I work for is looking at upgrading their encryption algorithms and encrypting significantly more data than before. As the one appointed to take care of this, I have replaced our old CAST-128 encryption (I say encryption but it was more like hashing, no salt and resulting in the same ciphertext every time) with AES-256 and written the tools to migrate the data. However, the encryption key is still hardcoded in the application, and extractable within a couple of minutes with a disassembler.
Our product is a desktop application, which most of our clients have installed in-house. Most of them are also hosting their own DBs. Since they have the entirety of the product locally, securing the key seems like a pretty difficult task.
After some research, I've decided to go with the following approach. During the installation, a random 256-bit key will be generated for every customer and used to encrypt their data with AES encryption. The key itself will then be encrypted with DPAPI in user mode, where the only user who can access the data will be a newly created locked down domain service account with limited permissions, who is unable to actually log in to the machine. The encrypted key will the be stored in an ACL-ed part of the registry. The encryption module will then impersonate that user to perform its functions.
The problem is that since the key will be randomly generated at install time, and encrypted immediately, not even we will have it. If customers happen to delete this account, reinstall the server OS, or manage to lose the key in some other manner, the data will be unrecoverable. So after all that exposition, here comes the actual question:
I am thinking of having customers back up the registry where the key is stored and assuming that even after a reinstall or user deletion, as long as the same user account is created with the same password, on the same machine, it will create the same DPAPI secrets and be able to decrypt the key. However, I do not know whether or not that is the case since I'm not sure how these secrets are generated in the first place. Can anyone confirm whether or not this is actually the case? I'm also open to suggestions for a completely different key storage approach if you can think of a better one.
I don't see the link with GDPR but let's say this is just context.
It takes more than the user account, its password and the machine. there is more Entropy added to the ciphering of data with DPAPI.
See : https://msdn.microsoft.com/en-us/library/ms995355.aspx#windataprotection-dpapi_topic02
A small drawback to using the logon password is that all applications
running under the same user can access any protected data that they
know about. Of course, because applications must store their own
protected data, gaining access to the data could be somewhat difficult
for other applications, but certainly not impossible. To counteract
this, DPAPI allows an application to use an additional secret when
protecting data. This additional secret is then required to unprotect
the data. Technically, this "secret" should be called secondary
entropy. It is secondary because, while it doesn't strengthen the key
used to encrypt the data, it does increase the difficulty of one
application, running under the same user, to compromise another
application's encryption key. Applications should be careful about how
they use and store this entropy. If it is simply saved to a file
unprotected, then adversaries could access the entropy and use it to
unprotect an application's data. Additionally, the application can
pass in a data structure that will be used by DPAPI to prompt the
user. This "prompt structure" allows the user to specify an additional
password for this particular data. We discuss this structure further
in the Using DPAPI section.
I am developing a web based application that will be employed by numerous third party organisations
in numerous countries around the world.
The browser based client will feed sensitive data into a shared back end database.
All organisations in all countries will Read/Write data into the same database.
I wish to encrypt the data entered within the browser so that its safe while in transit
to the back end database. e.g. client side encryption.
I also wish to encrypt the data while at rest in my database.
This application will be developed using Java, Javascript (REACT.js), and Scala.
The backend database will be MongoDB.
I cannot find a good Key Management example/description e.g. how a key is properly generated,
distributed, stored, replaced, deleted, and recovered during its life time.
I have the following choices/decisions to make:-
Flavour of encryption, e.g TripleDES, RSA, Blowfish, Twofish, AES etc..
Key(s) Symmetric/Asymmetric and its/thier length
How should I securely distribute the keys to my clients.
How to keep my keys safe on my back end servers.
If keys should have a lifecycle of generated, distributed, stored, replaced, deleted.
How do I decrypt data that was encrypted with Key0 when I am now using Key1, or Key2?
How should I store my multiple keys for my multiple clients to enable me to encrypt/decrypt
each clients data.
Use HTTPS with certificate pinning to secure the data in transit.
Use AES for encryption. Do not use TripleDES, RSA, Blowfish or Twofish in new work.
Use an HSM.
Encrypt the data with a long-life key that is not distributed, encrypt that key with short life keys that can be changed as needed.
Considering the scope of the project get a cryptographic domain expert to design the security and vet the code.
I'm writing a Node.JS application that will store chat logs to a datastore (i.e. MongoDB), along with some other user information. I'm already using bcrypt to store salted hashes for user passwords, so I'm covered there.
What the best method of encrypting persisted data? I'm talking about sensitive user data such as phone numbers, and the chat logs. If my database gets compromised, I don't want this information being usable.
I do need two-way encryption/decryption, however, because I need to be able to use the plain-text values (i.e. the phone numbers are for Twilio, the chat logs are for users to see their old messages).
I'm looking into node-crypto but I haven't been able to find any examples of doing this in a performant/realtime fashion.
UPDATE: I should've mentioned that the chat "logs" are actually full conversations that get pushed to "rooms" in real-time when users join them (i.e. they can see the entire chat history, or at least a subset of it). So, I'd need to be able to encrypt and decrypt on the fly pretty quickly (if not in real-time, at least with some sort of worker process).
The best thing to do is use require('crypto').
You will however need to port it to the clientside. Good luck with that. (Shouldn't be too hard with browserify)
Do it all server side, if you do it client side you will need to expose your encryption keys.