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 or Sequel.

Add attr_encrypted to your gemfile:

  gem "attr_encrypted"

Then install the gem:

  bundle install

If you're using an ORM like ActiveRecord 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 incorrectly 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)
      attr_encrypted_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 your 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.