Direct OTP codes are ones that are delivered directly to
the user (e.g. SMS) via send_two_factor_authentication_code.
These are randomly generated, short lived, and stored
directly in the database.
TOTP (and the rotp gem) is now only enabled for those user
that have a shared secret (user.create_otp_secret).
**Why**:
When looking up a class with `Object.const_defined?`, `false` will be
returned the first time it is called, even when the class exists in the
Rails app. I think this might be due to the way Rails loads classes.
**How**:
Use `ActiveSupport::Inflector#constantize`, which returns the class all
the time when the class exists, and throws a `NameError` when it
doesn't.
The only way I was able to properly test this was to create the
`UserOtpSender` class as a real file in the test Rails app, and create
a Devise Admin user to test the scenario where `AdminOtpSender` does
not exist.
I verified that with the old code, `reset_otp_state` was not being
called when it should be, and that the new code makes the tests pass.
**Why**:
To provide an additional layer of security.
The TOTP spec (RFC 6238) recommends encrypting the keys.
http://tools.ietf.org/html/rfc6238
**How**:
Borrow the encryption code from the `attr_encrypted` gem and use it to
encrypt and decrypt the `otp_secret_key` attribute.
Allow users to add encryption by passing in `encrypted: true` to
`has_one_time_password`. This provides backwards-compatibility for
existing users of the gem.
See the README updates for more detailed instructions for both new
and existing users.
baarkerlounger
Andrés Riveros
Ryan McGeary
amoose
Sam Clegg
Moncef Belyamani
Dmitrii Golub
Ross Kaffenberger
Matt Mueller