If you have an interest in maintaining this project... please see attr-encrypted#379
Generates attr_accessors that transparently encrypt and decrypt attributes.
It works with ANY class, however, you get a few extra features when you're using it with ActiveRecord
, DataMapper
, or Sequel
.
Add attr_encrypted to your gemfile:
gem "attr_encrypted", "~> 3.1.0"
Then install the gem:
bundle install
If you're using an ORM like ActiveRecord
, DataMapper
, or Sequel
, using attr_encrypted is easy:
class User
attr_encrypted :ssn, key: 'This is a key that is 256 bits!!'
end
If you're using a PORO, you have to do a little bit more work by extending the class:
class User
extend AttrEncrypted
attr_accessor :name
attr_encrypted :ssn, key: 'This is a key that is 256 bits!!'
def load
# loads the stored data
end
def save
# saves the :name and :encrypted_ssn attributes somewhere (e.g. filesystem, database, etc)
end
end
user = User.new
user.ssn = '123-45-6789'
user.ssn # returns the unencrypted object ie. '123-45-6789'
user.encrypted_ssn # returns the encrypted version of :ssn
user.save
user = User.load
user.ssn # decrypts :encrypted_ssn and returns '123-45-6789'
Two class methods are available for each attribute: User.encrypt_email
and User.decrypt_email
. They accept as arguments the same options that the attr_encrypted
class method accepts. For example:
key = SecureRandom.random_bytes(32)
iv = SecureRandom.random_bytes(12)
encrypted_email = User.encrypt_email('[email protected]', iv: iv, key: key)
email = User.decrypt_email(encrypted_email, iv: iv, key: key)
The attr_encrypted
class method is also aliased as attr_encryptor
to conform to Ruby's attr_
naming conventions. I should have called this project attr_encryptor
but it was too late when I realized it ='(.
By default, attr_encrypted
uses the :per_attribute_iv
encryption mode. This mode requires a column to store your cipher text and a column to store your IV (initialization vector).
Create or modify the table that your model uses to add a column with the encrypted_
prefix (which can be modified, see below), e.g. encrypted_ssn
via a migration like the following:
create_table :users do |t|
t.string :name
t.string :encrypted_ssn
t.string :encrypted_ssn_iv
t.timestamps
end
You can use a string or binary column type. (See the encode option section below for more info)
If you use the same key for each record, add a unique index on the IV. Repeated IVs with AES-GCM (the default algorithm) allow an attacker to recover the key.
add_index :users, :encrypted_ssn_iv, unique: true
By default, the encrypted attribute name is encrypted_#{attribute}
(e.g. attr_encrypted :email
would create an attribute named encrypted_email
). So, if you're storing the encrypted attribute in the database, you need to make sure the encrypted_#{attribute}
field exists in your table. You have a couple of options if you want to name your attribute or db column something else, see below for more details.
All options will be evaluated at the instance level. If you pass in a symbol it will be passed as a message to the instance of your class. If you pass a proc or any object that responds to :call
it will be called. You can pass in the instance of your class as an argument to the proc. Anything else will be returned. For example:
Here is an example class that uses an instance method to determines the encryption key to use.
class User
attr_encrypted :email, key: :encryption_key
def encryption_key
# does some fancy logic and returns an encryption key
end
end
Here is an example of passing a proc/lambda object as the :key
option as well:
class User
attr_encrypted :email, key: proc { |user| user.key }
end
The following are the default options used by attr_encrypted
:
prefix: 'encrypted_',
suffix: '',
if: true,
unless: false,
encode: false,
encode_iv: true,
encode_salt: true,
default_encoding: 'm',
marshal: false,
marshaler: Marshal,
dump_method: 'dump',
load_method: 'load',
encryptor: Encryptor,
encrypt_method: 'encrypt',
decrypt_method: 'decrypt',
mode: :per_attribute_iv,
algorithm: 'aes-256-gcm',
allow_empty_value: false
All of the aforementioned options are explained in depth below.
Additionally, you can specify default options for all encrypted attributes in your class. Instead of having to define your class like this:
class User
attr_encrypted :email, key: 'This is a key that is 256 bits!!', prefix: '', suffix: '_crypted'
attr_encrypted :ssn, key: 'a different secret key', prefix: '', suffix: '_crypted'
attr_encrypted :credit_card, key: 'another secret key', prefix: '', suffix: '_crypted'
end
You can simply define some default options like so:
class User
attr_encrypted_options.merge!(prefix: '', :suffix => '_crypted')
attr_encrypted :email, key: 'This is a key that is 256 bits!!'
attr_encrypted :ssn, key: 'a different secret key'
attr_encrypted :credit_card, key: 'another secret key'
end
This should help keep your classes clean and DRY.
You can simply pass the name of the encrypted attribute as the :attribute
option:
class User
attr_encrypted :email, key: 'This is a key that is 256 bits!!', attribute: 'email_encrypted'
end
This would generate an attribute named email_encrypted
If you don't like the encrypted_#{attribute}
naming convention then you can specify your own:
class User
attr_encrypted :email, key: 'This is a key that is 256 bits!!', prefix: 'secret_', suffix: '_crypted'
end
This would generate the following attribute: secret_email_crypted
.
The :key
option is used to pass in a data encryption key to be used with whatever encryption class you use. If you're using Encryptor
, the key must meet minimum length requirements respective to the algorithm that you use; aes-256 requires a 256 bit key, etc. The :key
option is not required (see custom encryptor below).
You can specify unique keys for each attribute if you'd like:
class User
attr_encrypted :email, key: 'This is a key that is 256 bits!!'
attr_encrypted :ssn, key: 'a different secret key'
end
It is recommended to use a symbol or a proc for the key and to store information regarding what key was used to encrypt your data. (See below for more details.)
There may be times that you want to only encrypt when certain conditions are met. For example maybe you're using rails and you don't want to encrypt attributes when you're in development mode. You can specify conditions like this:
class User < ActiveRecord::Base
attr_encrypted :email, key: 'This is a key that is 256 bits!!', unless: Rails.env.development?
attr_encrypted :ssn, key: 'This is a key that is 256 bits!!', if: Rails.env.development?
end
You can specify both :if
and :unless
options.
The Encryptor
class is used by default. You may use your own custom encryptor by specifying the :encryptor
, :encrypt_method
, and :decrypt_method
options.
Lets suppose you'd like to use this custom encryptor class:
class SillyEncryptor
def self.silly_encrypt(options)
(options[:value] + options[:secret_key]).reverse
end
def self.silly_decrypt(options)
options[:value].reverse.gsub(/#{options[:secret_key]}$/, '')
end
end
Simply set up your class like so:
class User
attr_encrypted :email, secret_key: 'This is a key that is 256 bits!!', encryptor: SillyEncryptor, encrypt_method: :silly_encrypt, decrypt_method: :silly_decrypt
end
Any options that you pass to attr_encrypted
will be passed to the encryptor class along with the :value
option which contains the string to encrypt/decrypt. Notice that the above example uses :secret_key
instead of :key
. See encryptor for more info regarding the default encryptor class.
The mode options allows you to specify in what mode your data will be encrypted. There are currently three modes: :per_attribute_iv
, :per_attribute_iv_and_salt
, and :single_iv_and_salt
.
NOTE: :per_attribute_iv_and_salt
and :single_iv_and_salt
modes are deprecated and will be removed in the next major release.
The default Encryptor
class uses the standard ruby OpenSSL library. Its default algorithm is aes-256-gcm
. You can modify this by passing the :algorithm
option to the attr_encrypted
call like so:
class User
attr_encrypted :email, key: 'This is a key that is 256 bits!!', algorithm: 'aes-256-cbc'
end
To view a list of all cipher algorithms that are supported on your platform, run the following code in your favorite Ruby REPL:
require 'openssl'
puts OpenSSL::Cipher.ciphers
See Encryptor for more information.
You're probably going to be storing your encrypted attributes somehow (e.g. filesystem, database, etc). You can simply pass the :encode
option to automatically encode/decode when encrypting/decrypting. The default behavior assumes that you're using a string column type and will base64 encode your cipher text. If you choose to use the binary column type then encoding is not required, but be sure to pass in false
with the :encode
option.
class User
attr_encrypted :email, key: 'some secret key', encode: true, encode_iv: true, encode_salt: true
end
The default encoding is m
(base64). You can change this by setting encode: 'some encoding'
. See Array#pack
for more encoding options.
You may want to encrypt objects other than strings (e.g. hashes, arrays, etc). If this is the case, simply pass the :marshal
option to automatically marshal when encrypting/decrypting.
class User
attr_encrypted :credentials, key: 'some secret key', marshal: true
end
You may also optionally specify :marshaler
, :dump_method
, and :load_method
if you want to use something other than the default Marshal
object.
You may want to encrypt empty strings or nil so as to not reveal which records are populated and which records are not.
class User
attr_encrypted :credentials, key: 'some secret key', marshal: true, allow_empty_value: true
end
If you're using this gem with ActiveRecord
, you get a few extra features:
The :encode
option is set to true by default.
Let's say you'd like to encrypt your user's email addresses, but you also need a way for them to login. Simply set up your class like so:
class User < ActiveRecord::Base
attr_encrypted :email, key: 'This is a key that is 256 bits!!'
attr_encrypted :password, key: 'some other secret key'
end
You can now lookup and login users like so:
User.find_by_email_and_password('[email protected]', 'testing')
The call to find_by_email_and_password
is intercepted and modified to find_by_encrypted_email_and_encrypted_password('ENCRYPTED EMAIL', 'ENCRYPTED PASSWORD')
. The dynamic scope methods like scoped_by_email_and_password
work the same way.
NOTE: This only works if all records are encrypted with the same encryption key (per attribute).
NOTE: This feature is deprecated and will be removed in the next major release.
The :encode
option is set to true by default.
attr_encrypted v2.0.0 now depends on encryptor v2.0.0. As part of both major releases many insecure defaults and behaviors have been deprecated. The new default behavior is as follows:
- Default
:mode
is now:per_attribute_iv
, the default:mode
in attr_encrypted v1.x was:single_iv_and_salt
. - Default
:algorithm
is now 'aes-256-gcm', the default:algorithm
in attr_encrypted v1.x was 'aes-256-cbc'. - The encryption key provided must be of appropriate length respective to the algorithm used. Previously, encryptor did not verify minimum key length.
- The dynamic finders available in ActiveRecord will only work with
:single_iv_and_salt
mode. It is strongly advised that you do not use this mode. If you can search the encrypted data, it wasn't encrypted securely. This functionality will be deprecated in the next major release. :per_attribute_iv_and_salt
and:single_iv_and_salt
modes are deprecated and will be removed in the next major release.
Backwards compatibility is supported by providing a special option that is passed to encryptor, namely, :insecure_mode
:
class User
attr_encrypted :email, key: 'a secret key', algorithm: 'aes-256-cbc', mode: :single_iv_and_salt, insecure_mode: true
end
The :insecure_mode
option will allow encryptor to ignore the new security requirements. It is strongly advised that if you use this older insecure behavior that you migrate to the newer more secure behavior.
Modify your gemfile to include the new version of attr_encrypted:
gem attr_encrypted, "~> 3.0.0"
The update attr_encrypted:
bundle update attr_encrypted
Then modify your models using attr_encrypted to account for the changes in default options. Specifically, pass in the :mode
and :algorithm
options that you were using if you had not previously done so. If your key is insufficient length relative to the algorithm that you use, you should also pass in insecure_mode: true
; this will prevent Encryptor from raising an exception regarding insufficient key length. Please see the Deprecations sections for more details including an example of how to specify your model with default options from attr_encrypted v1.x.
A bug was discovered in Encryptor v2.0.0 that inccorectly set the IV when using an AES-*-GCM algorithm. Unfornately fixing this major security issue results in the inability to decrypt records encrypted using an AES-*-GCM algorithm from Encryptor v2.0.0. Please see Upgrading to Encryptor v3.0.0 for more info.
It is strongly advised that you re-encrypt your data encrypted with Encryptor v2.0.0. However, you'll have to take special care to re-encrypt. To decrypt data encrypted with Encryptor v2.0.0 using an AES-*-GCM algorithm you can use the :v2_gcm_iv
option.
It is recommended that you implement a strategy to insure that you do not mix the encryption implementations of Encryptor. One way to do this is to re-encrypt everything while your application is offline.Another way is to add a column that keeps track of what implementation was used. The path that you choose will depend on your situtation. Below is an example of how you might go about re-encrypting your data.
class User
attr_encrypted :ssn, key: :encryption_key, v2_gcm_iv: is_decrypting?(:ssn)
def is_decrypting?(attribute)
encrypted_attributes[attribute][:operation] == :decrypting
end
end
User.all.each do |user|
old_ssn = user.ssn
user.ssn= old_ssn
user.save
end
While choosing to encrypt at the attribute level is the most secure solution, it is not without drawbacks. Namely, you cannot search the encrypted data, and because you can't search it, you can't index it either. You also can't use joins on the encrypted data. Data that is securely encrypted is effectively noise. So any operations that rely on the data not being noise will not work. If you need to do any of the aforementioned operations, please consider using database and file system encryption along with transport encryption as it moves through your stack.
Please also consider where your data leaks. If you're using attr_encrypted with Rails, it's highly likely that this data will enter your app as a request parameter. You'll want to be sure that you're filtering your request params from you logs or else your data is sitting in the clear in your logs. Parameter Filtering in Rails Please also consider other possible leak points.
When storing your encrypted data, please consider the length requirements of the db column that you're storing the cipher text in. Older versions of Mysql attempt to 'help' you by truncating strings that are too large for the column. When this happens, you will not be able to decrypt your data. MySQL Strict Trans
It is advisable to also store metadata regarding the circumstances of your encrypted data. Namely, you should store information about the key used to encrypt your data, as well as the algorithm. Having this metadata with every record will make key rotation and migrating to a new algorithm signficantly easier. It will allow you to continue to decrypt old data using the information provided in the metadata and new data can be encrypted using your new key and algorithm of choice.
On a related note, most algorithms require that your IV be unique for every record and key combination. You can enforce this using composite unique indexes on your IV and encryption key name/id column. RFC 5084
Lastly, while the :per_attribute_iv_and_salt
mode is more secure than :per_attribute_iv
mode because it uses a unique key per record, it uses a PBKDF function which introduces a huge performance hit (175x slower by my benchmarks). There are other ways of deriving a unique key per record that would be much faster.
- Fork the project.
- Make your feature addition or bug fix.
- Add tests for it. This is important so I don't break it in a future version unintentionally.
- Commit, do not mess with rakefile, version, changelog, or history.
- Send me a pull request. Bonus points for topic branches.