2FA OTP token not accepted everywhere
9Lukas5 opened this issue · 7 comments
I newly created an Fedoraproject account and enabled 2FA, resulting in being locked-out from the account, as the log-in didn't accept the OTP token I entered.
After the token got reset I tried it again. This time I stayed logged in on one device to play around a bit more. Following are my steps taken and what I found:
Steps taken
from device 1:
- logged in
- added an OTP token
- confirmed with my password
- scanned the QR code
- entered the generated OTP token to confirm
- kept logged in
from device 2:
- tried to log in now with enabled 2FA
- failed with error "Unauthorized: bad credentials"
from device 1:
- went back to settings
- tried to disable 2FA again, but as it announced on enabling it
already, it doesn't allow to remove all OTP tokens - tried to add a second OTP token, which, now as 2FA is enabled already,
requires the password AND and OTP token to confirm - confirmation fails with "Incorrect password", weird because I use a
password manager and autofill it, so mistyping it is basically not a thing - as the password contained extended ASCII and specials I decided to
generate a new alphanumerical one to test - went to the password settings and filled in the current password, the
new one and the OTP token - changing the password went fine, so on changing the password it
accepted the OTP token :o
from device 2:
- tried logging in with new password and OTP token again
- still failed
from device 1:
- tried again to add another OTP token
- still fails with "Incorrect password"
Right now the OTP token got reset again on my account and I'll wait for a response from here, before I try it again.
I'm using a current Firefox on Fedora and the Authenticator App andOTP on Android.
I'm especially flustered that it works on confirming the new token and changing the password, but not for loggin in or adding another token.
bump, anyone?
cc @nirik , maybe I should have mentioned you in here right from the start 😬
I don't have any idea whats happening here... we need to wait for cycles from @abompard / a noggin developer.
The only thing that stands out to me is the "extended ASCII and specials" but you tried a password with just a-zA-Z0-9 and it did the same thing right? How many characters long was it?
128 chars only alphanumerical. That's the one I'm using right now which I can log in just fine. Didn't dare to touch the 2FA again since you reset it for me twice.
I have recreated this issue on IPA's demo server (authentication fails with long passwords when TOTP is enabled), and filed an issue here:
As I responded on the IPA's issue (thanks, @ryanlerch for filing that), we cannot support larger passwords for OTP/RADIUS pre-authentication methods without breaking RFC 2865 compatibility.
@9Lukas5, since MIT Kerberos internally uses RADIUS protocol for communication between KDC and the RADIUS backend in which we implement 2FA support, and that backend also implements RADIUS proxying to an external RADIUS servers, we have no chance to violate RFC 2865 requirements. We might have some changes for internal IPA use case but then it becomes quite confusing to users.
I'm inclined to document that both OTP and RADIUS authentication methods in FreeIPA only support up to 128 characters in user credentials (including OTP token value, in OTP case).
Okay, so now this issue really should be:
"Restrict Passwords in Noggin to 122 characters (122+6)"
Okay, so now this issue really should be:
"Restrict Passwords in Noggin to 122 characters (122+6)"
Based on the failure I just reproductive trying to authenticate to comment on the FreeIPA issue, the encoding overhead may reduce the available password length to less than 95 characters, though the inconsistency of authentication failure described in #1394 may indicate otherwise.
This situation appears analogous to the more common case of folks who use bcrypt but don't limit passwords to 72 characters.