devise-two-factor 4.1.1 → 6.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 787116f2d8fd1e2ef5a6e663c0a3ed5a65ca6110a491f44d2de5eb1a985da516
-  data.tar.gz: f379bef9da0239c3697fe14dad33ba6c662ecfd2b6bcc3ab54fb184f75a970d4
+  metadata.gz: 131bab7308f2b9d46a41b5e11b85411e0cd097e97f16c82356eadb1cf87d5cc3
+  data.tar.gz: b117115cfbb9ffe4f6dcec8127de0e0d51ca5fa835407a82cad8afc17f923f5f
 SHA512:
-  metadata.gz: 23b55432e9df42fa8723db98cd38abe641656ed05ce6f5d9e5d7ee1a1179624ba7212209c460a7ff4b16d4f14347b11c69750d795e7ff9f56513e93af651c619
-  data.tar.gz: ce784140d65f12c6e46a51d86ed8e97edc6b98e706f276160e67f95bccf615c308a5cf273bd54ad71788b61e5dac92f9676c4e67ebfdd81c83584fa71e0bb509
+  metadata.gz: 187bd4ed05b0ad83da40cbe208c4bbe2ce91581d95f437cdaa27364ddb0be3696a2a03aad62e8a02f07adaeca24778202710f20f79422156b4aef63d13a03721
+  data.tar.gz: 5635dccf010dd259404e9e03092eb9e107896b31f178d1ae3760046aa794fe449eb3bd2929bfb08c29df725376d8abc3dbb3f80e2dfb63405172c6130c24c687

data/.github/dependabot.yml

@@ -0,0 +1,6 @@
+version: 2
+updates:
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"

data/.github/workflows/ci.yml

@@ -12,29 +12,14 @@ jobs:
       fail-fast: false
       matrix:
         # Due to https://github.com/actions/runner/issues/849, we should quote versions
-        ruby: ['2.3', '2.4', '2.5', '2.6', '2.7', '3.0', 'truffleruby-head']
-        rails: ['4.1', '4.2', '5.0', '5.1', '5.2', '6.0', '6.1', '7.0']
-        exclude:
-          - { ruby: '2.3', rails: '7.0' }
-          - { ruby: '2.4', rails: '7.0' }
-          - { ruby: '2.5', rails: '7.0' }
-          - { ruby: '2.6', rails: '7.0' }
-          - { ruby: '2.3', rails: '6.0' }
-          - { ruby: '2.3', rails: '6.1' }
-          - { ruby: '2.4', rails: '6.0' }
-          - { ruby: '2.4', rails: '6.1' }
-          - { ruby: '2.7', rails: '4.1' }
-          - { ruby: '2.7', rails: '4.2' }
-          - { ruby: '3.0', rails: '4.1' }
-          - { ruby: '3.0', rails: '4.2' }
-          - { ruby: 'truffleruby-head', rails: '4.1' }
-          - { ruby: 'truffleruby-head', rails: '4.2' }
+        ruby: ['3.1', '3.2', '3.3', 'truffleruby-head']
+        rails: ['7.0', '7.1']
 
     name: Ruby ${{ matrix.ruby }}, Rails ${{ matrix.rails }}
     env: # $BUNDLE_GEMFILE must be set at the job level, so it is set for all steps
       BUNDLE_GEMFILE: ${{ github.workspace }}/gemfiles/rails_${{ matrix.rails }}.gemfile
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@v4
       - name: Set up Ruby
         uses: ruby/setup-ruby@v1
         with:

data/.markdownlint.json

@@ -0,0 +1,6 @@
+{
+  "MD026": false,
+  "MD029": false,
+  "MD031": false,
+  "MD034": false
+}

data/CHANGELOG.md

@@ -2,6 +2,21 @@
 
 ## Unreleased
 
+## 5.1.0
+
+- Remove faker dev dependency
+- Insert two_factor_authenticatable at the top of the devise module list
+- README and CI improvements
+
+## 5.0.0
+
+**Breaking Changes**
+- attr_encrypted has been deprecated in favor of native Rails attribute encryption. See [UPGRADING.md](UPGRADING.md) for details on how to migrate your records. You **must** use or build a migration strategy (see examples in [UPGRADING.md](UPGRADING.md)) to use existing data!
+- Rails 7 is now required.
+
+## 4.1.0 / 4.1.1
+- Add support for attr_encrypted v4
+
 ## 4.0.2
 - Add Rails 7.0 support
 - Renew signing certificate

data/README.md

@@ -1,7 +1,6 @@
 # Devise-Two-Factor Authentication
-By [Tinfoil Security](https://www.tinfoilsecurity.com/) (acq. [Synopsys](https://www.synopsys.com/) 2020). Interested in [working with us](https://www.synopsys.com/careers.html)? We're hiring!
 
-![Build Status](https://github.com/tinfoil/devise-two-factor/actions/workflows/ci.yml/badge.svg)
+![Build Status](https://github.com/devise-two-factor/devise-two-factor/actions/workflows/ci.yml/badge.svg)
 
 Devise-Two-Factor is a minimalist extension to Devise which offers support for two-factor authentication, through the [TOTP](https://en.wikipedia.org/wiki/Time-based_One-Time_Password) scheme. It:
 
@@ -11,89 +10,109 @@ Devise-Two-Factor is a minimalist extension to Devise which offers support for t
 * Is extensible, and includes two-factor backup codes as an example of how plugins can be structured
 
 ## Contributing
+
 We welcome pull requests, bug reports, and other contributions. We're especially looking for help getting this gem fully compatible with Rails 5+ and squashing any deprecation messages.
 
 ## Example App
-An example Rails 4 application is provided in the `demo` directory. It showcases a minimal example of Devise-Two-Factor in action, and can act as a reference for integrating the gem into your own application.
 
-For the demo app to work, create an encryption key and store it as an environment variable. One way to do this is to create a file named `local_env.yml` in the application root. Set the value of `ENCRYPTION_KEY` in the YML file. That value will be loaded into the application environment by `application.rb`.
+See [examples](demo/README.md).
 
 ## Getting Started
-Devise-Two-Factor doesn't require much to get started, but there are a few prerequisites before you can start using it in your application.
+
+Devise-Two-Factor doesn't require much to get started, but there are two prerequisites before you can start using it in your application:
+
+1. A Rails application with [devise](https://github.com/heartcombo/devise) installed
+1. Secrets configured for ActiveRecord encrypted attributes
 
 First, you'll need a Rails application setup with Devise. Visit the Devise [homepage](https://github.com/plataformatec/devise) for instructions.
 
-You can add Devise-Two-Factor to your Gemfile with:
+Devise-Two-Factor uses [ActiveRecord encrypted attributes](https://edgeguides.rubyonrails.org/active_record_encryption.html). If you haven't already set up ActiveRecord encryption you must generate a key set and configure your application to use them either with Rails' encrypted credentials or from another source such as environment variables.
 
-```ruby
-gem 'devise-two-factor'
+```bash
+# Generates a random key set and outputs it to stdout
+./bin/rails db:encryption:init
 ```
 
-Next, since Devise-Two-Factor encrypts its secrets before storing them in the database, you'll need to generate an encryption key, and store it in an environment variable of your choice. Set the encryption key in the model that uses Devise:
-
-```ruby
-  devise :two_factor_authenticatable,
-         :otp_secret_encryption_key => ENV['YOUR_ENCRYPTION_KEY_HERE']
+You can load the key set using Rails' credentials.
 
+```bash
+# Copy the generated key set into your encrypted credentials file
+# Setting the EDITOR environment variable is optional, but without it your default editor will open
+EDITOR="code --wait" ./bin/rails credentials:edit
 ```
 
-Finally, you can automate all of the required setup by simply running:
+To learn more about credentials run `./bin/rails credentials:help`.
+
+Alternatively, you can configure your application with environment variables rather than Rails' credentials.
 
 ```ruby
-rails generate devise_two_factor MODEL ENVIRONMENT_VARIABLE
+# Copy the generate key set and set them as environment variables
+
+config.active_record.encryption.primary_key = ENV['ACTIVE_RECORD_ENCRYPTION_PRIMARY_KEY']
+config.active_record.encryption.deterministic_key = ENV['ACTIVE_RECORD_ENCRYPTION_DETERMINISTIC_KEY']
+config.active_record.encryption.key_derivation_salt = ENV['ACTIVE_RECORD_ENCRYPTION_KEY_DERIVATION_SALT']
 ```
 
-Where `MODEL` is the name of the model you wish to add two-factor functionality to (for example `user`), and `ENVIRONMENT_VARIABLE` is the name of the variable you're storing your encryption key in.
+Add Devise-Two-Factor to your Gemfile with:
 
-This generator will add a few columns to the specified model:
+```ruby
+# Gemfile
 
-* encrypted_otp_secret
-* encrypted_otp_secret_iv
-* encrypted_otp_secret_salt
-* consumed_timestep
-* otp_required_for_login
+gem 'devise-two-factor'
+```
 
-Remember to apply the new migration.
+There is a generator which automates most of the setup:
 
-```ruby
-bundle exec rake db:migrate
+```bash
+# MODEL is the name of the model you wish to configure devise_two_factor e.g. User or Admin
+./bin/rails generate devise_two_factor MODEL
 ```
 
-It also adds the `:two_factor_authenticatable` directive to your model, and sets up your encryption key. If present, it will remove `:database_authenticatable` from the model, as the two strategies are incompatible. Lastly, the generator will add a Warden config block to your Devise initializer, which enables the strategies required for two-factor authentication.
+Where `MODEL` is the name of the model you wish to add two-factor functionality to (for example `user`)
 
-If you're running Rails 3, or do not have strong parameters enabled, the generator will also setup the required mass-assignment security options in your model.
+This generator will:
 
-If you're running Rails 4, you'll also need to whitelist `:otp_attempt` as a permitted parameter in Devise `:sign_in` controller. You can do this by adding the following to your `application_controller.rb`:
+1. Create a new migration which adds a few columns to the specified model:
 
-```ruby
-before_action :configure_permitted_parameters, if: :devise_controller?
+    ```ruby
+    add_column :users, :otp_secret, :string
+    add_column :users, :consumed_timestep, :integer
+    add_column :users, :otp_required_for_login, :boolean
+    ```
 
-...
+1. Edit `app/models/MODEL.rb` (where MODEL is your model name):
+    * add the `:two_factor_authenticatable` devise module
+    * remove the `:database_authenticatable` if present because it is incompatible with `:two_factor_authenticatable`
+1. Add a Warden config block to your Devise initializer, which enables the strategies required for two-factor authentication.
 
-protected
+Remember to apply the new migration after you run the generator:
 
-def configure_permitted_parameters
-  devise_parameter_sanitizer.for(:sign_in) << :otp_attempt
-end
+```bash
+./bin/rails db:migrate
 ```
 
-If you're running Devise 4.0.0 or above, you'll want to use `.permit` instead:
+Next you need to whitelist `:otp_attempt` as a permitted parameter in Devise `:sign_in` controller. You can do this by adding the following to your `application_controller.rb`:
 
 ```ruby
-before_action :configure_permitted_parameters, if: :devise_controller?
+# app/controllers/application_controller.rb
 
-...
+  before_action :configure_permitted_parameters, if: :devise_controller?
 
-protected
+  # ...
 
-def configure_permitted_parameters
-  devise_parameter_sanitizer.permit(:sign_in, keys: [:otp_attempt])
-end
+  protected
+
+  def configure_permitted_parameters
+    devise_parameter_sanitizer.permit(:sign_in, keys: [:otp_attempt])
+  end
 ```
 
-**After running the generator, verify that `:database_authenticatable` is not being loaded by your model. The generator will try to remove it, but if you have a non-standard Devise setup, this step may fail. Loading both `:database_authenticatable` and `:two_factor_authenticatable` in a model will allow users to bypass two-factor authenticatable due to the way Warden handles cascading strategies.**
+Finally you should verify that `:database_authenticatable` is **not** being loaded by your model. The generator will try to remove it, but if you have a non-standard Devise setup, this step may fail.
+
+**Loading both `:database_authenticatable` and `:two_factor_authenticatable` in a model is a security issue** It will allow users to bypass two-factor authenticatable due to the way Warden handles cascading strategies!
 
 ## Designing Your Workflow
+
 Devise-Two-Factor only worries about the backend, leaving the details of the integration up to you. This means that you're responsible for building the UI that drives the gem. While there is an example Rails application included in the gem, it is important to remember that this gem is intentionally very open-ended, and you should build a user experience which fits your individual application.
 
 There are two key workflows you'll have to think about:
@@ -103,8 +122,8 @@ There are two key workflows you'll have to think about:
 
 We chose to keep things as simple as possible, and our implementation can be found by registering at [Tinfoil Security](https://www.tinfoilsecurity.com/), and enabling two-factor authentication from the [security settings page](https://www.tinfoilsecurity.com/account/security).
 
-
 ### Logging In
+
 Logging in with two-factor authentication works extremely similarly to regular database authentication in Devise. The `TwoFactorAuthenticatable` strategy accepts three parameters:
 
 1. email
@@ -114,11 +133,13 @@ Logging in with two-factor authentication works extremely similarly to regular d
 These parameters can be submitted to the standard Devise login route, and the strategy will handle the authentication of the user for you.
 
 ### Disabling Automatic Login After Password Resets
+
 If you use the Devise `recoverable` strategy, the default behavior after a password reset is to automatically authenticate the user and log them in. This is obviously a problem if a user has two-factor authentication enabled, as resetting the password would get around the two-factor requirement.
 
 Because of this, you need to set `sign_in_after_reset_password` to `false` (either globally in your Devise initializer or via `devise_for`).
 
 ### Enabling Two-Factor Authentication
+
 Enabling two-factor authentication for a user is easy. For example, if my user model were named User, I could do the following:
 
 ```ruby
@@ -149,6 +170,7 @@ current_user.current_otp
 ```
 
 The generated code will be valid for the duration specified by `otp_allowed_drift`. This value can be modified by adding a config in `config/initializers/devise.rb`.
+
 ```ruby
 Devise.otp_allowed_drift = 240 # value in seconds
 Devise.setup do |config|
@@ -165,13 +187,27 @@ However you decide to handle enrollment, there are a few important consideration
 It sounds like a lot of work, but most of these problems have been very elegantly solved by other people. We recommend taking a look at the excellent workflows used by Heroku and Google for inspiration.
 
 ### Filtering sensitive parameters from the logs
+
 To prevent two-factor authentication codes from leaking if your application logs get breached, you'll want to filter sensitive parameters from the Rails logs. Add the following to `config/initializers/filter_parameter_logging.rb`:
 
 ```ruby
 Rails.application.config.filter_parameters += [:otp_attempt]
 ```
 
+### Preventing Brute-Force Attacks
+
+With any authentication solution it is also important to protect your users from brute-force attacks. For Devise-Two-Factor specifically if a user's username and password have already been compromised an attacker would be able to try possible TOTP codes and see if they can hit a lucky collision to log in. While Devise-Two-Factor is open-ended by design and cannot solve this for all applications natively there are some possible mitigations to consider. A non-exhaustive list follows:
+
+1. Use the `lockable` strategy from Devise to lock a user after a certain number of failed login attempts. See https://www.rubydoc.info/github/heartcombo/devise/main/Devise/Models/Lockable for more information.
+2. Configure a rate limit for your application, especially on the endpoints used to log in. One such library to accomplish this is [rack-attack](https://rubygems.org/gems/rack-attack).
+3. When displaying authentication errors hide whether validating a username/password combination failed or a two-factor code failed behind a more generic error message.
+
+#### Acknowledgements
+
+Thank you to Christian Reitter (Radically Open Security) and Chris MacNaughton (Centauri Solutions) for reporting the issue.
+
 ## Backup Codes
+
 Devise-Two-Factor is designed with extensibility in mind. One such extension, `TwoFactorBackupable`, is included and serves as a good example of how to extend this gem. This plugin allows you to add the ability to generate single-use backup codes for a user, which they may use to bypass two-factor authentication, in the event that they lose access to their device.
 
 To install it, you need to add the `:two_factor_backupable` directive to your model.
@@ -186,17 +222,39 @@ You'll also be required to enable the `:two_factor_backupable` strategy, by addi
 manager.default_strategies(:scope => :user).unshift :two_factor_backupable
 ```
 
-The final installation step is dependent on your version of Rails. If you're not running Rails 4, skip to the next section. Otherwise, create the following migration:
+### Migration
+
+The final installation step may be dependent on your version of Rails.
+
+#### PostgreSQL
 
 ```ruby
 class AddDeviseTwoFactorBackupableToUsers < ActiveRecord::Migration
   def change
-    # Change type from :string to :text if using MySQL database
     add_column :users, :otp_backup_codes, :string, array: true
   end
 end
 ```
 
+#### MySQL
+
+```ruby
+# migration
+class AddDeviseTwoFactorBackupableToUsers < ActiveRecord::Migration
+  def change
+    add_column :users, :otp_backup_codes, :text
+  end
+end
+
+# model
+class User < ApplicationRecord
+  devise :two_factor_backupable
+  serialize :otp_backup_codes, Array
+end
+```
+
+### Generation
+
 You can then generate backup codes for a user:
 
 ```ruby
@@ -214,23 +272,8 @@ devise :two_factor_backupable, otp_backup_code_length:     32,
                                otp_number_of_backup_codes: 10
 ```
 
-### Help! I'm not using Rails 4.0!
-Don't worry! `TwoFactorBackupable` stores the backup codes as an array of strings in the database. In Rails 4.0 this is supported natively, but in earlier versions you can use a gem to emulate this behavior: we recommend [activerecord-postgres-array](https://github.com/tlconnor/activerecord-postgres-array).
-
-You'll then simply have to create a migration to add an array named `otp_backup_codes` to your model. If you use the above gem, this migration might look like:
-
-```ruby
-class AddTwoFactorBackupCodesToUsers < ActiveRecord::Migration
-  def change
-    # Change type from :string_array to :text_array if using MySQL database
-    add_column :users, :otp_backup_codes, :string_array
-  end
-end
-```
-
-Now just continue with the setup in the previous section, skipping the generator step.
-
 ## Testing
+
 Devise-Two-Factor includes shared-examples for both `TwoFactorAuthenticatable` and `TwoFactorBackupable`. Adding the following two lines to the specs for your two-factor enabled models will allow you to test your models for two-factor functionality:
 
 ```ruby
@@ -241,6 +284,7 @@ it_behaves_like "two_factor_backupable"
 ```
 
 ## Troubleshooting
+
 If you are using Rails 4.x and Ruby >= 2.7, you may get an error like
 
 ```
@@ -250,9 +294,11 @@ Failure/Error: require 'devise'
 NoMethodError:
   undefined method `new' for BigDecimal:Class
 ```
+
 see https://github.com/ruby/bigdecimal#which-version-should-you-select and https://github.com/ruby/bigdecimal/issues/127
 for more details, but you should be able to solve this
 by explicitly requiring an older version of bigdecimal in your gemfile like
-```
+
+```ruby
 gem "bigdecimal", "~> 1.4"
 ```

data/SECURITY.md

@@ -0,0 +1,5 @@
+# Security Policy
+
+## Reporting a Vulnerability
+
+Please report any vulnerabilities to the [Black Duck PSIRT](psirt@blackduck.com).

data/UPGRADING.md

@@ -1,4 +1,220 @@
-# Guide to upgrading from 2.x to 3.x
+# Upgrading
+
+## Upgrading from 5.x to 6.x
+
+### save!
+
+`consume_otp!` and `invalidate_otp_backup_code!` now call `save!` instead of `save` (or nothing at all in the case of `invalide_otp_backup_code!`). If you manually called `save`/`save!` after calling `invalidate_otp_backup_code` you may be able to remove it.
+
+### Secret Lengths
+
+The `otp_secret_length` and `otp_backup_code_length` options have changed to be the number of random bytes that are generated.
+If you had configured these values you may want to change them if you wish to keep the same output length.
+
+`otp_secret_length` now has a default value of 20, generating a 160 bit secret key with an output length length of 32 bytes.
+
+`otp_backup_code_length` now has a default value of 16, generating a 32 byte backup code.
+
+## Upgrading from 4.x to 5.x
+
+### Background
+
+#### Database columns in version 4.x and older
+
+Versions 4.x and older stored the OTP secret in an attribute called `encrypted_otp_secret` using the [attr_encrypted](https://github.com/attr-encrypted/attr_encrypted) gem. This gem is currently unmaintained which is part of the motivation for moving to Rails encrypted attributes. This attribute was backed by three database columns:
+
+```
+encrypted_otp_secret
+encrypted_otp_secret_iv
+encrypted_otp_secret_salt
+```
+
+Two other columns were also created:
+
+```
+consumed_timestep
+otp_required_for_login
+```
+
+A fresh install of 4.x would create all five of the database columns above.
+
+#### Database columns in version 5.x and later
+
+Versions 5+ of this gem uses a single [Rails 7+ encrypted attribute](https://edgeguides.rubyonrails.org/active_record_encryption.html) named `otp_secret`to store the OTP secret in the database table (usually `users` but will be whatever model you picked).
+
+A fresh install of 5+ will add the following columns to your `users` table:
+
+```bash
+otp_secret # this replaces encrypted_otp_secret, encrypted_otp_secret_iv, encrypted_otp_secret_salt
+consumed_timestep
+otp_required_for_login
+```
+
+We have attempted to make the upgrade as painless as possible but unfortunately because of the secret storage change, it cannot be as simple as `bundle update devise-two-factor` :heart:
+
+### Assumptions
+
+This guide assumes you are upgrading an existing Rails 6 app (with `devise` and `devise-two-factor`) to Rails 7.
+
+This gem must be upgraded **as part of a Rails 7 upgrade**. See [the official Rails upgrading guide](https://guides.rubyonrails.org/upgrading_ruby_on_rails.html) for an overview of upgrading Rails.
+
+### Phase 1: Upgrading devise-two-factor as part of Rails 7 upgrade
+
+1. Update the version constraint for Rails in your `Gemfile` to your desired version e.g. `gem "rails", "~> 7.0.3"`
+1. Run `bundle install` and resolve any issues with dependencies.
+1. Update the version constraint for `devise-two-factor` in your `Gemfile` to the the latest version (must be at least 5.x e.g. `~> 5.0`
+1. Run `./bin/rails app:update` as per the [Rails upgrade guide](https://guides.rubyonrails.org/upgrading_ruby_on_rails.html) and tweak the output as required for your app.
+1. Run `./bin/rails db:migrate` to update your DB based on the changes made by `app:update`
+1. Add a new `otp_secret` attribute to your user model
+    ```bash
+    # TODO: replace 'User' in the migration name with the name of your user model
+    ./bin/rails g migration AddOtpSecretToUser otp_secret:string
+    ./bin/rails db:migrate
+    ```
+1. Add a `legacy_otp_secret` method to your user model e.g. `User`.
+  * This method is used by the gem to find and decode the OTP secret from the legacy database columns.
+  * The implementation shown below works if you set up devise-two-factor with the settings suggested in the [OLD README](https://github.com/devise-two-factor/devise-two-factor/blob/8d74f5ee45594bf00e60d5d49eb6fcde82c2d2ba/README.md).
+  * If you have customised the encryption scheme used to store the OTP secret then you will need to update this method to match.
+  * If you are unsure, you should try the method below as is, and if you can still sign in users with OTP enabled then all is well.
+    ```ruby
+    class User
+      # ...
+
+      private
+
+      ##
+      # Decrypt and return the `encrypted_otp_secret` attribute which was used in
+      # prior versions of devise-two-factor
+      # @return [String] The decrypted OTP secret
+      def legacy_otp_secret
+        return nil unless self[:encrypted_otp_secret]
+        return nil unless self.class.otp_secret_encryption_key
+
+        hmac_iterations = 2000 # a default set by the Encryptor gem
+        key = self.class.otp_secret_encryption_key
+        salt = Base64.decode64(encrypted_otp_secret_salt)
+        iv = Base64.decode64(encrypted_otp_secret_iv)
+
+        raw_cipher_text = Base64.decode64(encrypted_otp_secret)
+        # The last 16 bytes of the ciphertext are the authentication tag - we use
+        # Galois Counter Mode which is an authenticated encryption mode
+        cipher_text = raw_cipher_text[0..-17]
+        auth_tag =  raw_cipher_text[-16..-1]
+
+        # this algorithm lifted from
+        # https://github.com/attr-encrypted/encryptor/blob/master/lib/encryptor.rb#L54
+
+        # create an OpenSSL object which will decrypt the AES cipher with 256 bit
+        # keys in Galois Counter Mode (GCM). See
+        # https://ruby.github.io/openssl/OpenSSL/Cipher.html
+        cipher = OpenSSL::Cipher.new('aes-256-gcm')
+
+        # tell the cipher we want to decrypt. Symmetric algorithms use a very
+        # similar process for encryption and decryption, hence the same object can
+        # do both.
+        cipher.decrypt
+
+        # Use a Password-Based Key Derivation Function to generate the key actually
+        # used for encryption from the key we got as input.
+        cipher.key = OpenSSL::PKCS5.pbkdf2_hmac_sha1(key, salt, hmac_iterations, cipher.key_len)
+
+        # set the Initialization Vector (IV)
+        cipher.iv = iv
+
+        # The tag must be set after calling Cipher#decrypt, Cipher#key= and
+        # Cipher#iv=, but before calling Cipher#final. After all decryption is
+        # performed, the tag is verified automatically in the call to Cipher#final.
+        #
+        # If the auth_tag does not verify, then #final will raise OpenSSL::Cipher::CipherError
+        cipher.auth_tag = auth_tag
+
+        # auth_data must be set after auth_tag has been set when decrypting See
+        # http://ruby-doc.org/stdlib-2.0.0/libdoc/openssl/rdoc/OpenSSL/Cipher.html#method-i-auth_data-3D
+        # we are not adding any authenticated data but OpenSSL docs say this should
+        # still be called.
+        cipher.auth_data = ''
+
+        # #update is (somewhat confusingly named) the method which actually
+        # performs the decryption on the given chunk of data. Our OTP secret is
+        # short so we only need to call it once.
+        #
+        # It is very important that we call #final because:
+        #
+        # 1. The authentication tag is checked during the call to #final
+        # 2. Block based cipher modes (e.g. CBC) work on fixed size chunks. We need
+        #    to call #final to get it to process the last chunk properly. The output
+        #    of #final should be appended to the decrypted value. This isn't
+        #    required for streaming cipher modes but including it is a best practice
+        #    so that your code will continue to function correctly even if you later
+        #    change to a block cipher mode.
+        cipher.update(cipher_text) + cipher.final
+      end
+    end
+    ```
+2. Set up [Rails encrypted secrets](https://edgeguides.rubyonrails.org/active_record_encryption.html)
+    ```bash
+    ./bin/rails db:encryption:init
+    # capture the output and put in encrypted credentials via
+    ./bin/rails credentials:edit
+    ```
+3. Complete your Rails 7 upgrade (making whatever other changes are required)
+
+You can now deploy your upgraded application and devise-two-factor should work as before.
+
+This gem will fall back to **reading** the OTP secret from the legacy columns if it cannot find one in the new `otp_secret` column. When you **write** a new OTP secret it will always be written to the new `otp_secret` column.
+
+### Phase 2: Clean up
+
+This "clean up" phase can happen at the same time as your initial deployment but teams managing existing apps will likely want to do clean-up as separate, later deployments.
+
+1. Create a rake task to copy the OTP secret for each user from the legacy column to the new `otp_secret` column. This prepares the way for us to remove the legacy columns in a later step.
+    ```ruby
+    # lib/tasks/devise_two_factor_migration.rake
+
+    # Use this as a starting point for your task to migrate your user's OTP secrets.
+    namespace :devise_two_factor do
+      desc "Copy devise_two_factor OTP secret from old format to new format"
+      task copy_otp_secret_to_rails7_encrypted_attr: [:environment] do
+        # TODO: change User to your user model
+        User.find_each do |user| # find_each finds in batches of 1,000 by default
+          otp_secret = user.otp_secret # read from otp_secret column, fall back to legacy columns if new column is empty
+          puts "Processing #{user.email}"
+          user.update!(otp_secret: otp_secret)
+        end
+      end
+    end
+    ```
+1. Remove the `#legacy_otp_secret` method from your user model (e.g. `User`) because it is no longer required.
+1. Remove the now unused legacy columns from the database. This assumes you have run a rake task as in the previous step to migrate all the legacy stored secrets to the new storage.
+    ```bash
+    # TODO: replace 'Users' in migration name with the name of your user model
+    ./bin/rails g migration RemoveLegacyDeviseTwoFactorSecretsFromUsers
+    ```
+    which generates
+    ```ruby
+    class RemoveLegacyDeviseTwoFactorSecretsFromUsers < ActiveRecord::Migration[7.0]
+      def change
+        # TODO: change :users to whatever your users table is
+
+        # WARNING: Only run this when you are confident you have copied the OTP
+        # secret for ALL users from `encrypted_otp_secret` to `otp_secret`!
+        remove_column :users, :encrypted_otp_secret
+        remove_column :users, :encrypted_otp_secret_iv
+        remove_column :users, :encrypted_otp_secret_salt
+      end
+    end
+    ```
+1. Remove `otp_secret_encryption_key` from the model setup. This also assumes you successfully ran the rake task in step 1.
+    ```ruby
+    # from this:
+    devise :two_factor_authenticatable,
+        otp_secret_encryption_key: ENV['YOUR_ENCRYPTION_KEY_HERE']
+
+    # to this:
+    devise :two_factor_authenticatable
+    ```
+
+## Upgrading from 2.x to 3.x
 
 Pull request #76 allows for compatibility with `attr_encrypted` 3.0, which should be used due to a security vulnerability discovered in 2.0.
 
@@ -18,7 +234,7 @@ class User < ActiveRecord::Base
          :otp_secret_encryption_key => ENV['DEVISE_TWO_FACTOR_ENCRYPTION_KEY']
 ```
 
-# Guide to upgrading from 1.x to 2.x
+## Upgrading from 1.x to 2.x
 
 Pull request #43 added a new field to protect against "shoulder-surfing" attacks. If upgrading, you'll need to add the `:consumed_timestep` column to your `Users` model.
 

data/devise-two-factor.gemspec

@@ -5,12 +5,11 @@ Gem::Specification.new do |s|
   s.name        = 'devise-two-factor'
   s.version     = DeviseTwoFactor::VERSION.dup
   s.platform    = Gem::Platform::RUBY
-  s.licenses    = ['MIT']
+  s.license     = 'MIT'
   s.summary     = 'Barebones two-factor authentication with Devise'
-  s.email       = 'engineers@tinfoilsecurity.com'
-  s.homepage    = 'https://github.com/tinfoil/devise-two-factor'
-  s.description = 'Barebones two-factor authentication with Devise'
-  s.authors     = ['Shane Wilton']
+  s.homepage    = 'https://github.com/devise-two-factor/devise-two-factor'
+  s.description = 'Devise-Two-Factor is a minimalist extension to Devise which offers support for two-factor authentication through the TOTP scheme.'
+  s.authors     = ['Quinn Wilton']
 
   s.cert_chain  = [
                     'certs/tinfoil-cacert.pem',
@@ -23,7 +22,6 @@ Gem::Specification.new do |s|
 
   s.add_runtime_dependency 'railties',       '~> 7.0'
   s.add_runtime_dependency 'activesupport',  '~> 7.0'
-  s.add_runtime_dependency 'attr_encrypted', '>= 1.3', '< 5', '!= 2'
   s.add_runtime_dependency 'devise',         '~> 4.0'
   s.add_runtime_dependency 'rotp',           '~> 6.0'
 
@@ -32,5 +30,4 @@ Gem::Specification.new do |s|
   s.add_development_dependency 'bundler',    '> 1.0'
   s.add_development_dependency 'rspec',      '> 3'
   s.add_development_dependency 'simplecov'
-  s.add_development_dependency 'faker'
 end