Upgrade devise, devise-two-factor, encryptor, and attr_encrypted

• Devise 4.x is required for Rails 5 compatibility.
• devise-two-factor will be releasing a v3.0.0 soon which adds support for Devise 4.
• attr_encrypted 3.x and encryptor 3.x are both optional upgrades, but we should probably upgrade to them anyway.

attr_encrypted 2.x and encryptor 2.x are not secure, we cannot use them. 3.x fixes the vulnerability introduced in 2.x, and so we should skip directly to it. Note also that 1.x contains no known vulnerabilities, so this isn't a problem for us at present.

We currently use the default encryption algorithm in 1.x, which is aes-256-cbc. 3.x updates the default to aes-256-gcm, thus the algorithm will need to be explicitly mentioned for encrypted attributes.

I don't know the exact performance/security tradeoffs here, others who are more knowledgeable about security can determine whether we should upgrade to aes-256-gcm (or aes-128-gcm, which is allegedly still more secure than aes-256-cbc while also being more performant than aes-256-gcm, but again, I defer to others). Also make sure to consider the ciphers supported by OpenSSL versions installed on customer machines. Upgrading would definitely require downtime, albeit I'm not sure how much.

Similarly, the mode we use with attr_encrypted (:per_attribute_iv_and_salt) is deprecated and meant to be removed in the next major version. It would be worth considering moving to a different mode if we intend to re-encrypt things anyway.

devise-two-factor 3.0.0 will require adding some compatibility code to the User model in order to remain compatible with attr_encrypted 3.0.0, unless we upgrade the encrypted information.

---

Changelogs:

• attr_encrypted
• encryptor
• devise-two-factor

Deprecations in attr_encrypted:

• 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.

cc: @balameb @DouweM @rspeicher @pcarranza

Suggested labels: security gem update

Added gem update label

So I took a shot at this (using the devise-two-factor devise-4 branch) and everything seems to be working fine (except for a grammar issue in Devise 4.1 which I've reported ).

Once devise-two-factor 3.0.0 is released (I'm told this will happen sometime in the next few days), I'll take the changes I made and put together an MR that upgrades attr_encrypted, encryptor, devise-two-factor, and devise, and removes devise-async. I have to do these all at once because the different versions rely on each other for compatibility. I'll split them into separate commits for cleanliness sake, though.

I decided not to upgrade the mode or algorithm for now, and based on my testing the changes are entirely backwards compatible with existing 2FA and other places we're using attr_encrypted (namely build variables and project importing), with no migrations or downtime needed. At some point in the future we'll have to move to attr_encrypted/encryptor 4.0 (whenever it's released) and change the mode/algorithm, although that's best left for a future merge request.

This is a pretty big step towards Rails 5 compatibility (#14286 (moved)), and one of the things I was most concerned about with regards to it, so I'm glad it's going to be out of the way soon :)

This was resolved by !4216 (merged)

Status changed to closed

mentioned in issue #19073 (closed)