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).
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.
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).
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.
A pair of Amazon Lambdas will symmetrically encrypt and decrypt a small piece of application data. I want to use Amazon KMS to facilitate this, because it solves the problems of secret storage and key rotation, and then some.
The Amazon KMS Developer Guide indicates:
These operations are designed to encrypt and decrypt data keys. They use an AWS KMS customer master key (CMK) in the encryption operations and they cannot accept more than 4 KB (4096 bytes) of data. Although you might use them to encrypt small amounts of data, such as a password or RSA key, they are not designed to encrypt application data.
It goes on to recommend using AWS Encryption SDK or the Amazon S3 encryption client for encrypting application data.
While the listed advantages of the AWS Encryption SDK are clear as day, and very attractive, especially to a developer who is not a cryptographer, let's assume for the purpose of this question that circumstances are not favorable to those alternatives.
If my application data is sure never to exceed 4k, why specifically shouldn't I simply use Amazon KMS to encrypt and decrypt this data?
Use case
My team is implementing a new authentication layer to be used across the services and APIs at our company. We're implementing a JWT specification, but whereas we intend to steer clear of the widely documented cryptographic grievances beleaguering JWE / JWS compliant token signing, we're symmetrically encrypting the payload. Thus, we keep the advantage of standard library implementations of non-cryptographic token validation operations (expiry and the rest,) and we leave behind the cryptographic "foot-gun."
I suspect it's about performance: scaling and and latency.
KMS encrypt/decrypt has a limit of 5500 reqs/s per account, which is shared with some other KMS operations.
"Why?" Is also discussed a bit more thoroughly in the FAQ.
Why use envelope encryption? Why not just send data to AWS KMS to encrypt directly?
While AWS KMS does support sending data less than 4 KB to be encrypted, envelope encryption can offer significant performance benefits. When you encrypt data directly with KMS it must be transferred over the network. Envelope encryption reduces the network load for your application or AWS cloud service. Only the request and fulfillment of the data key through KMS must go over the network. Since the data key is always stored in encrypted form, it is easy and safe to distribute that key where you need it to go without worrying about it being exposed. Encrypted data keys are sent to AWS KMS and decrypted under master keys to ultimately allow you to decrypt your data. The data key is available directly in your application without having to send the entire block of data to AWS KMS and suffer network latency.
https://aws.amazon.com/kms/faqs/
I am going through this issue with AWS support right now. There is the throttling limit mentioned in the accepted answer. Also, if you reuse and cache data keys as allowed by the SDK, you can save money at the expense of lowered security (one data key can decrypt multiple objects).
However, if neither of those are relevant to you, direct CMK encryption is appealing. The security is excellent because the data key cannot be leaked, every decryption requires a API call to KMS and can be audited. In the KMS Best Practices whitepaper, it states that encryption of credit card numbers in this way is PCI compliant.
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.