Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/joegoldbeck/mongoose-encryption
Simple encryption and authentication plugin for Mongoose
https://github.com/joegoldbeck/mongoose-encryption
Last synced: 3 months ago
JSON representation
Simple encryption and authentication plugin for Mongoose
- Host: GitHub
- URL: https://github.com/joegoldbeck/mongoose-encryption
- Owner: joegoldbeck
- License: mit
- Created: 2014-06-19T16:41:58.000Z (about 10 years ago)
- Default Branch: master
- Last Pushed: 2023-08-30T22:11:31.000Z (10 months ago)
- Last Synced: 2024-03-07T19:24:18.287Z (4 months ago)
- Language: CoffeeScript
- Homepage:
- Size: 362 KB
- Stars: 215
- Watchers: 12
- Forks: 48
- Open Issues: 21
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- License: LICENSE
- Security: SECURITY.md
Lists
- awesome-andy-node - mongoose-encryption - Encryption and Authentication for mongoose fields (Packages / Mongoose)
README
mongoose-encryption
==================
[](https://badge.fury.io/js/mongoose-encryption)
[](https://travis-ci.com/joegoldbeck/mongoose-encryption)
[](https://github.com/joegoldbeck/mongoose-encryption/blob/master/LICENSE)
Simple encryption and authentication for mongoose documents. Relies on the Node `crypto` module. Encryption and decryption happen transparently during save and find. Rather than encrypting fields individually, this plugin takes advantage of the BSON nature of mongoDB documents to encrypt multiple fields at once.
## How it Works
Encryption is performed using `AES-256-CBC` with a random, unique initialization vector for each operation. Authentication is performed using `HMAC-SHA-512`.
To encrypt, the relevant fields are removed from the document, converted to JSON, enciphered in `Buffer` format with the IV and plugin version prepended, and inserted into the `_ct` field of the document. Mongoose converts the `_ct` field to `Binary` when sending to mongo.
To decrypt, the `_ct` field is deciphered, the JSON is parsed, and the individual fields are inserted back into the document as their original data types.
To sign, the relevant fields (which necessarily include `_id` and `_ct`) are stably stringified and signed along with the list of signed fields, the collection name, and the plugin version. This signature is stored in `Buffer` format in the `_ac` field with the plugin version prepended and the list of signed fields appended. Mongoose converts the field to `Binary` when sending to mongo.
To authenticate, a signature is generated in the same fashion as above, and compared to the `_ac` field on the document. If the signatures are equal, authentication succeeds. If they are not, or if `_ac` is missing from the document, authentication fails and an error is passed to the callback.
During `save`, documents are encrypted and then signed. During `find`, documents are authenticated and then decrypted
## Before You Get Started
Read the [Security Notes](#security-notes) below
## Installation
`npm install mongoose-encryption`
## Usage
Generate and store keys separately. They should probably live in environment variables, but be sure not to lose them. You can either use a single `secret` string of any length; or a pair of base64 strings (a 32-byte `encryptionKey` and a 64-byte `signingKey`).
A great way to securely generate this pair of keys is `openssl rand -base64 32; openssl rand -base64 64;`
### Basic
By default, all fields are encrypted except for `_id`, `__v`, and fields with indexes
```
var mongoose = require('mongoose');
var encrypt = require('mongoose-encryption');
var userSchema = new mongoose.Schema({
name: String,
age: Number
// whatever else
});
// Add any other plugins or middleware here. For example, middleware for hashing passwords
var encKey = process.env.SOME_32BYTE_BASE64_STRING;
var sigKey = process.env.SOME_64BYTE_BASE64_STRING;
userSchema.plugin(encrypt, { encryptionKey: encKey, signingKey: sigKey });
// This adds _ct and _ac fields to the schema, as well as pre 'init' and pre 'save' middleware,
// and encrypt, decrypt, sign, and authenticate instance methods
User = mongoose.model('User', userSchema);
```
And you're all set. `find` works transparently (though you cannot query fields that are encrypted) and you can make `New` documents as normal, but you should not use the `lean` option on a `find` if you want the document to be authenticated and decrypted. `findOne`, `findById`, etc..., as well as `save` and `create` also all work as normal. `update` will work fine on unencrypted and unauthenticated fields, but will not work correctly if encrypted or authenticated fields are involved.
### Exclude Certain Fields from Encryption
To exclude additional fields (other than _id and indexed fields), pass the `excludeFromEncryption` option
```
// exclude age from encryption, still encrypt name. _id will also remain unencrypted
userSchema.plugin(encrypt, { encryptionKey: encKey, signingKey: sigKey, excludeFromEncryption: ['age'] });
```
### Encrypt Only Certain Fields
You can also specify exactly which fields to encrypt with the `encryptedFields` option. This overrides the defaults and all other options.
```
// encrypt age regardless of any other options. name and _id will be left unencrypted
userSchema.plugin(encrypt, { encryptionKey: encKey, signingKey: sigKey, encryptedFields: ['age'] });
```
### Authenticate Additional Fields
By default, the encrypted parts of documents are authenticated along with the `_id` to prevent copy/paste attacks by an attacker with database write access. If you use one of the above options such that only part of your document is encrypted, you might want to authenticate the fields kept in cleartext to prevent tampering. In particular, consider authenticating any fields used for authorization, such as `email`, `isAdmin`, or `password` (though password should probably be in the encrypted block). You can do this with the `additionalAuthenticatedFields` option.
```
// keep isAdmin in clear but pass error on find() if tampered with
userSchema.plugin(encrypt, {
encryptionKey: encKey,
signingKey: sigKey,
excludeFromEncryption: ['isAdmin'],
additionalAuthenticatedFields: ['isAdmin']
});
```
Note that the most secure choice is to include all non-encrypted fields for authentication, as this prevents tampering with any part of the document.
### Nested Fields
Nested fields can be addressed in options using dot notation. For example, `encryptedFields: ['nest.secretBird']`
### Renaming an Encrypted Collection
To guard against cross-collection attacks, the collection name is included in the signed block. This means that if you simply change the name of a collection in Mongo (and therefore update the model name in Mongoose), authentication would fail. To restore functionality, pass in the `collectionId` option with the old model name.
```
// used to be the `users` collection, now it's `powerusers`
poweruserSchema.plugin(encrypt, {
encryptionKey: encKey,
signingKey: sigKey,
collectionId: `User` // this corresponds to the old model name
});
PowerUser = mongoose.model('PowerUser', poweruserSchema);
```
### Encrypt Specific Fields of Sub Docs
You can even encrypt fields of sub-documents, you just need to add the `encrypt` plugin to the subdocument schema. *Subdocuments are not self-authenticated*, so you should consider adding the `encrypt` plugin to the parent schema as well for the authentication it provides, or if you would like to avoid that overhead, add the `encrypt.encryptedChildren` plugin to the parent schema if you will continue to work with documents following saves.
```
var hidingPlaceSchema = new Schema({
latitude: Number,
longitude: Number,
nickname: String
});
hidingPlaceSchema.plugin(encrypt, {
encryptionKey: encKey,
signingKey: sigKey,
excludeFromEncryption: ['nickname']
});
var userSchema = new Schema({
name: String,
locationsOfGold: [hidingPlaceSchema]
});
// optional but recommended: authenticate subdocuments from the parent document
userSchema.plugin(encrypt, {
encryptionKey: encKey,
signingKey: sigKey,
additionalAuthenticatedFields: ['locationsOfGold'],
encryptedFields: []
});
// alternative to the above. needed for continuing to work with document following a save
userSchema.plugin(encrypt.encryptedChildren);
```
The need for `encrypt.encryptedChildren` arises because of the order of middleware hooks in Mongoose 5.x.
### Save Behavior
By default, documents are decrypted after they are saved to the database, so that you can continue to work with them transparently.
```
joe = new User ({ name: 'Joe', age: 42 });
joe.save(function(err){ // encrypted when sent to the database
// decrypted in the callback
console.log(joe.name); // Joe
console.log(joe.age); // 42
console.log(joe._ct); // undefined
});
```
You can turn off this behavior, and slightly improve performance, using the `decryptPostSave` option.
```
userSchema.plugin(encrypt, { ..., decryptPostSave: false });
...
joe = new User ({ name: 'Joe', age: 42 });
joe.save(function(err){
console.log(joe.name); // undefined
console.log(joe.age); // undefined
console.log(joe._ct); // `encryptionKey`
- Add `signingKey` as 64-byte base64 string (generate with `openssl rand -base64 64`)
- Run migrations
- If you have encrypted subdocuments, first run the class method `migrateSubDocsToA()` on the parent collection
```
// Only if there are encrypted subdocuments
// Prepends plugin version to _ct
userSchema.plugin(encrypt.migrations, { .... });
User = mongoose.model('User', userSchema);
User.migrateSubDocsToA('locationsOfGold', function(err){
if (err){ throw err; }
console.log('Subdocument migration successful');
});
```
- Run the class method `migrateToA()` on any encrypted collections (that are not themselves subdocuments)
```
// Prepends plugin version to _ct and signs all documents
userSchema.plugin(encrypt.migrations, { .... });
User = mongoose.model('User', userSchema);
User.migrateToA(function(err){
if (err){ throw err; }
console.log('Migration successful');
});
```
- Suggestions
- Set `additionalAuthenticatedFields` to include, at minimum, all fields involved in authorizing access to a document in your application
- If using encrypted subdocuments, note additional recommendations [here](#encrypt-specific-fields-of-sub-docs)
- Deprecations
- Rename `fields` -> `encryptedFields`
- Rename `exclude` -> `excludeFromEncryption`
## Pros & Cons of Encrypting Multiple Fields at Once
Advantages:
- All Mongoose data types supported via a single code path
- Faster encryption/decryption when working with the entire document
- Smaller encrypted documents
Disadvantages:
- Cannot select individual encrypted fields in a query nor unset or rename encrypted fields via an update operation
- Potentially slower in cases where you only want to decrypt a subset of the document
- Transactions including the entire encrypted/authenticated block are effectively enforced. Updating any encrypted or authenticated field forces them all to be marked as modified.
## Security Notes
- Always store your keys and secrets outside of version control and separate from your database. An environment variable on your application server works well for this.
- Additionally, store your encryption key offline somewhere safe. If you lose it, there is no way to retrieve your encrypted data.
- Encrypting passwords is no substitute for appropriately hashing them. [bcrypt](https://github.com/ncb000gt/node.bcrypt.js) is one great option. Here's one [nice implementation](http://blog.mongodb.org/post/32866457221/password-authentication-with-mongoose-part-1). Once you've already hashed the password, you may as well encrypt it too. Defense in depth, as they say. Just add the mongoose-encryption plugin to the schema after any hashing middleware.
- If an attacker gains access to your application server, they likely have access to both the database and the key. At that point, neither encryption nor authentication do you any good.
## How to Run Unit Tests
0. Install dependencies with `npm install` and [install mongo](http://docs.mongodb.org/manual/installation/) if you don't have it yet
1. Start mongo with `mongod` (or `brew services start mongodb-community`)
2. Run tests with `npm test`
## Security Issue Reporting / Disclaimer
See [SECURITY.md](./SECURITY.md)
## Acknowledgements
Huge thanks goes out to [Cinch Financial](https://www.cinchfinancial.com) for supporting this plugin through version 1.0, as well as [@stash](https://github.com/stash) for pointing out the limitations of earlier versions which lacked authentication and providing invaluable guidance and review on version 0.12.0.
Feel like contributing with different kinds of bits? Eth: 0xb53b70d5BE66a03E85F6502d1D060871a79a47f7
## License
The MIT License (MIT)
Copyright (c) 2016-2022 Joseph Goldbeck
Copyright (c) 2014-2015 Joseph Goldbeck and Connect Financial, LLC
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.