IBM Security Verify

 View Only
Expand all | Collapse all

totp + pin/secret policy mechanism available out of the box?

  • 1.  totp + pin/secret policy mechanism available out of the box?

    Posted Tue September 22, 2020 06:45 AM
    Hi,
    Is there a policy mechanism that requires not only a TOTP generated code, but appended with a 'secret' (pincode for instance) for logging on?

    i.e. to allow me access I would have to enter the 6 (TOTP) digits + 6 digits I have entered when registering the otp QR/code to my device.
    It doesn't necessarily have to be 6 digits, as long as it is something that only I 'know'.

    Rgds

    ------------------------------
    Anders Domeij
    CGI Sweden AB
    ------------------------------


  • 2.  RE: totp + pin/secret policy mechanism available out of the box?

    Posted Tue September 22, 2020 12:10 PM
    Hi Anders,

    There isn't a mechanism to do exactly what you have requested.  However, "something I have" and "something I know" could be achieved by a policy that first requests username/password and then requests TOTP.  Both of these mechanisms are natively supported.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message


  • 3.  RE: totp + pin/secret policy mechanism available out of the box?

    Posted Wed September 23, 2020 05:17 AM
    Thanks Jon,
    >a policy that first requests username/password and then requests TOTP
    is what we have today.

    It's more a question of registering the TOTP to the users device.
    the /mga/...../otp.html can be used to generete the users OTP (QR)-code and the user can then register that in/to the his/her OTP-client. Unfortnately in that flow no information is kept within ISVA that the user actually has created the OTP code and (hopefully) registered it on the device.

    Hence if the username/passord fall into the "wrong hands", the "wrong hands" can register the same OTP code on a different device.

    One way to solve this would be to have the 'extended' OTP token (TOTP + secret) and a verification mechanism that knows how to parse it and verify both the OTP token and the secret, and some information stored hat the user from now on needs the extende token not only the TOTP token when identifying.

    So on the off chance that both the OTP client and username/password fall into the "wrong hands", the 'wrong hands' are still missing a crucial piece for gaining access.

    It's mostly related to the 'chicken and egg' problem with "we want you to have OTP but we don't want to give it to you if you just have username/password".

    Rgds

    ------------------------------
    Anders Domeij
    CGI Sweden AB
    ------------------------------

    Original Message