Disabled Tokens Not Being Skipped


#1

It appears that when a token is disabled, it is still being checked during /validate/check call. For testing I have a user with a SPass token and a RADIUS token. I have the RADIUS token disabled. However, if I enter the proper OTP for the RADIUS token, the is_challenge_response and is_challenge_request functions of the radius token are still processed.

I’ve worked around this issue by updating the check_token_list function in token.py to remove any inactive tokens (in addition to revoked tokens). I also fixed the bug there where the removal wasn’t working at all since the loop was trying to remove an item from itself which tends to not function properly.

# Remove locked tokens from tokenobject_list
if len(tokenobject_list) > 1:
    for tokenobject in tokenobject_list[:]:
        if tokenobject.is_revoked():
            tokenobject_list.remove(tokenobject)
        elif tokenobject.is_active() is False:
            tokenobject_list.remove(tokenobject)

    if len(tokenobject_list) == 0:
        # If there is no unlocked/active token left.
        raise TokenAdminError(_("This action is not possible, since the "
                                "tokens are locked or disabled"), id=1007)

#2

it is on purpose that disabled tokens are processed. THis is also specified in the RFCs.
Why? If the user uses a real OTP value from a disabled token, an attacker could use this OTP value if the token is enabled again later.
So this OTP value needs to be invalididated.


#3

Well that’s unfortunate. Some of the RADIUS tokens we have are SMS On-Demand. So if the token is disabled but the user enters their correct PIN, they get an SMS sent to them, but they also at the same time receive the ‘incorrect passcode’ error since the token was disabled.

These tokens will be moved to be SMS tokens within PI in the future. Do the SMS tokens in PI have the same issue? Will they send a tokencode even if the token is disabled and they enter the correct PIN?


#4

I think you are right, a disabled token should not send a challenge in the first place. We need to look into this, if there is any logic, I can not remember, yet.
I opened an issue at github.


#5

I think this issue may be of my own doing. I had to add strange logic to the radiustoken to be able to handle challenges that come in a chain. I believe the standard code properly does not send challenges.

Not sure if you had a chance to review https://github.com/privacyidea/privacyidea/pull/1389#discussion_r249508396 in my pull request. Therein lies my dilemma.