yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #93815
[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