Do you recognize a good idea when you see one? We want to hear from you!
Header Image

I suggest you ...

When manually defining Soft Token, provide a RANDOM Secret button.

When using the One Time Password (OTP) facility to manually build Soft Tokens for users; it would be nice if the UTM could provide a 'Generate Random Secret' button; as currently you have to manuall source/define a 128 bit hex secret key. Using a Random string generator that confirms to the UTM requirements of manually defined OTP secrets would make things easier.

5 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Aaron BugalAaron Bugal shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    3 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Rolf MüllerRolf Müller commented  ·   ·  Flag as inappropriate

        Dear Alan,
        I can fully understand Aron's request. The use case described by Alan has one Major security risk. The user is able to download the token seed to multiple devices without the admin to have notice. This means that the user might Hand over the seed to a second Person and by this the 2 factor authentication is compromised or deceived.
        Therefore we don't let anybody scan the qr code from the userportal, instead the user has to go to the Helpdesk and the admin presents the qr code to the user for scaning. This is where Aarons request makes sense!
        So either do implement the generate button, or provide us with another secure process, so that the user can only see the qr code if the admin has control.
        Thank's and regards, Rolf

      • Aaron BugalAaron Bugal commented  ·   ·  Flag as inappropriate

        The primary use case is in environments where passwords are shared (either inadvertently or directly) with other staff members. As such, knowing a Username and Password would then allow the unauthorised user to gain access to the QR code via the User Portal.
        If the process can be manually controlled - like it can be now - it regulates WHO actually gets the soft token.
        However, the manual process requires a SECRET which needs to be manually created by the Admin (as expected).
        The feature simply expose the automated generation of a secret key and allow the admin to invoke that same function from webadmin when building a manual soft token.

      • Alan ToewsAdminAlan Toews (Admin, Sophos Features & Ideas Laboratory) commented  ·   ·  Flag as inappropriate

        Hi Aaron, what's the use case you see for for manually defining the user's token? This doesn't make much sense based on the expected workflow, but if there is a use case we aren't accommodating presently, it might make sense to change the current behavior.

        The intended workflow for software tokens, is that the user, who must have the secret installed in their authenticatior application, can get this token via self-service from the user portal. This way, there is not typing, or copy/pasting to get the code from the UTM to the client. In this use case, the secret is automatically generated for them by the UTM. No need for generating it via external means.

        The expected use case for manually defining a secret for a user is when compatible hardware tokens are used. In this case, generating a token would be pointless, since these tokens already have a pre-generated secret, which the UTM must know, for the token to work with the UTM.

      Feedback and Knowledge Base