← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 2060452] [NEW] TOTP with 'short' shared secrets not supported

 

Public bug reported:

We are migrating our users from an older backend to keystone and want to
keep the current 2FA tokens for the end-users to make is as seamless as
possible.

Historically it was common practice to generate TOTP secrets of 16 chars
[1] and users still use them.

One issue we are facing is that keystone (implicitly) does not accept
the 2FA TOTP secrets our older user base currently has, as the keysize
is not long enough for the default settings of cryptography.

We can just pass enforce_key_length=False[2] along when initializing the
crypography totp class [3], and that would solve this issue, so maybe it
would be a possibility to allow an operator to 'enable' this flag though
a new config option for the TOTP auth plugin?

[1] https://github.com/pyca/cryptography/issues/2915
[2] https://cryptography.io/en/latest/hazmat/primitives/twofactor/#cryptography.hazmat.primitives.twofactor.hotp.HOTP
[3] https://github.com/openstack/keystone/blob/master/keystone/auth/plugins/totp.py#L74

** Affects: keystone
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/2060452

Title:
  TOTP with 'short' shared secrets not supported

Status in OpenStack Identity (keystone):
  New

Bug description:
  We are migrating our users from an older backend to keystone and want
  to keep the current 2FA tokens for the end-users to make is as
  seamless as possible.

  Historically it was common practice to generate TOTP secrets of 16
  chars [1] and users still use them.

  One issue we are facing is that keystone (implicitly) does not accept
  the 2FA TOTP secrets our older user base currently has, as the keysize
  is not long enough for the default settings of cryptography.

  We can just pass enforce_key_length=False[2] along when initializing
  the crypography totp class [3], and that would solve this issue, so
  maybe it would be a possibility to allow an operator to 'enable' this
  flag though a new config option for the TOTP auth plugin?

  [1] https://github.com/pyca/cryptography/issues/2915
  [2] https://cryptography.io/en/latest/hazmat/primitives/twofactor/#cryptography.hazmat.primitives.twofactor.hotp.HOTP
  [3] https://github.com/openstack/keystone/blob/master/keystone/auth/plugins/totp.py#L74

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/2060452/+subscriptions