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.
Related
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).
I'm working on a project with some sensitive data. I'm trying to do statistics about Facebook conversation with a client only website. Until now, I have a big JSON file of a Facebook conversation that I parse and do stuff with data. I want to be able to deliver this file only to my friends. So, what I thought is that I locally encrypt it (with I don't know yet which algo), deliver the encrypted file and give the password to my friend so only them can decrypt it. Do you think it will work and it will be secure enought ? I don't want someone to be able to bruteforce it or whatever, as it is private conversation. And do you have any recommendation about the algo I should use ?
You placed an abstract question so you may get only an abstract answer
deliver the encrypted file and give the password to my friend so only them can decrypt it. Do you think it will work and it will be secure enought ?
There are a few conditions to make encryption safe.
using any modern cipher which is not considered weak (e.g. AES-128 provides enough of security)
the encryption key is random (or password used to generate the key is long and random enough)
optionally you may add an authentication tag to ensure message integrity
And do you have any recommendation about the algo I should use ?
To encrypt data itself, any current modern cipher will do, e. g. aes, 3des,...
If you don't want to dive into security and you just want to encrypt a file, you can you some out of box tools which would do that for you. Try to look at openssl, pgp, gpg or nppcrypt (plugin for notepad++). Just make the password long and random.
The question is how do you get the key or password to your friend safely. You can either use different channel or using asynchronous (such as RSA or ECC). You can search, read, try out and ask more specific question
According to Google Cloud all customer data is encrypted automatically. Then why isn't my data encrypted when I export it to a google storage and download it from there? Do I need to enable some service anyway for the encryption to work?
I really appreciate your help, thanks!
Your data is always encrypted by default on server-side. What it means is that, once Google receives the data, it encrypts it. It is recommended that you always sent your data over HTTPS or TLS. Data is automatically and transparently decrypted when read by an authorised user.
You can use the other two options for server side encryption, and you can also encrypt the data on your side, before sending it. I think this option suits your concern, but you'll have to manage your own encryption from your side, and ensure you never less your keys. Nevertheless, GCP will encrypt your data again once received.
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).
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.