Can I Hide token information in the userportal by default

I don't think UTM can do what you ask.

However, I don't know that what you want is really necessary.  I will elaborate on some of the OTP issues that I have considered, and hope that the discussion helps.

After the OTP enrollment, the user portal requires the password followed by the PIN.   So there is minimal risk of an unauthorized person accessing the user portal once OTP is established, and there is substantial protection against password-guessing attacks as long as all remote access methods are protected by UTM and OTP.

There are these possible levels or security for OTP enrollment:

1. Completely disable OTP enrollment from the user portal:
   Management... User Portal... Advanced (tab)...  Disable Portal Items (section)... OTP Tokens [checked]
   In this mode, users must come to the system administrator so that OTP can be configured using Web Admin:
   Defintions and Users... Authentication Services... One-Time Password (tab)... OTP Tokens (section)... +(icon)
   
   
2. Only enable OTP Tokens on the user portal intermittently, in response to a user request.
   This would allow users to enroll their token remotely from User Admin, but would still require coordination with the system admin.   So it is only a little different from option 1.
   A variant of this approach is to require OTP for all UTM users, but only activate a user for UTM when they are ready and able to enroll in OTP.
   
   
3. Only enable User Portal access from internal addresses.
   Management... User Portal... Global (tab)... Allowed Networks
   This only works if you will not use User Portal for remote access functions such as HTML5 VPN, and if all of your users will work internally with some regularity.
   
   
4. Enable User Portal with OTP Token management for both internal and external IP addresses.
   This is, at least in theory, the least secure option, because if a user has not configured his OTP token, a successful password-guessing attack would allow the attacker to also possess the user's OTP.  The risk is significantly mitigated by the breakin evasion feature:
   Definitions and Users... Authentication Services... Advanced (tab)... Block Password Guessing (Section).

Re-Enrollment

Users will need access to the OTP token when they get a new cell phone.   If you have 100 users and each user buys a new cell phone every 2 years, you will have an average of one re-enrollment per week.   If you have hidden their token, they are back to options 1 or 2 -- the UTM administrator must be contacted before re-enrollment can work.   If you are not using those options for initial enrollment, I don't know that it adds any security to require it for re-enrollment.

Other considerations.

OTP Tokens have some distinct advantages over other 2-factor methods.   Chief among these is that the user, password, and OTP are validated at the same time, so when a failure occurs, a password guesser obtains no information about which value was incorrect.   A second benefit is that the Authenticator application does not require a communication channel with the server, so it can be used during foreign travel, in places where cell phone usage or text usage may be very expensive.

One possible objection to OTP comes from the second benefit -- the server has no way of knowing how many devices (or even which devices) have been activated for any particular user.  Users with both a cell phone and a tablet may wish to activate the OTP token on multiple devices.  Given that the goal of 2-factor is to check both something you know (the password) and something you have (the device), I don't know that it is a security problem for multiple devices to be activated at once.   However, I suspect that this is your motivation, and you have found the only way that I know to (attempt to) enforce a one-device policy.   Even then, you cannot prevent a user from displaying the QR code and synchronizing two devices at once during the initial setup.

DUO is a third-party product that has been formally tested with UTM, and it provides alternatives to OTP tokens.   I believe all of them are two-step verification methods, where you validate using your username and password, and then the system contacts you by another method for 2nd-factor.   This 2-factor approach is attractive in large environments where a diverse user base makes a variety of 2-factor methods essential.   However, it does allow more opportunity for password guessing attacks, since the 2nd-factor authentication check only occurs after the password has been entered correctly.

I don't think UTM can do what you ask.

However, I don't know that what you want is really necessary.  I will elaborate on some of the OTP issues that I have considered, and hope that the discussion helps.

After the OTP enrollment, the user portal requires the password followed by the PIN.   So there is minimal risk of an unauthorized person accessing the user portal once OTP is established, and there is substantial protection against password-guessing attacks as long as all remote access methods are protected by UTM and OTP.

There are these possible levels or security for OTP enrollment:

1. Completely disable OTP enrollment from the user portal:
   Management... User Portal... Advanced (tab)...  Disable Portal Items (section)... OTP Tokens [checked]
   In this mode, users must come to the system administrator so that OTP can be configured using Web Admin:
   Defintions and Users... Authentication Services... One-Time Password (tab)... OTP Tokens (section)... +(icon)
   
   
2. Only enable OTP Tokens on the user portal intermittently, in response to a user request.
   This would allow users to enroll their token remotely from User Admin, but would still require coordination with the system admin.   So it is only a little different from option 1.
   A variant of this approach is to require OTP for all UTM users, but only activate a user for UTM when they are ready and able to enroll in OTP.
   
   
3. Only enable User Portal access from internal addresses.
   Management... User Portal... Global (tab)... Allowed Networks
   This only works if you will not use User Portal for remote access functions such as HTML5 VPN, and if all of your users will work internally with some regularity.
   
   
4. Enable User Portal with OTP Token management for both internal and external IP addresses.
   This is, at least in theory, the least secure option, because if a user has not configured his OTP token, a successful password-guessing attack would allow the attacker to also possess the user's OTP.  The risk is significantly mitigated by the breakin evasion feature:
   Definitions and Users... Authentication Services... Advanced (tab)... Block Password Guessing (Section).

Re-Enrollment

Users will need access to the OTP token when they get a new cell phone.   If you have 100 users and each user buys a new cell phone every 2 years, you will have an average of one re-enrollment per week.   If you have hidden their token, they are back to options 1 or 2 -- the UTM administrator must be contacted before re-enrollment can work.   If you are not using those options for initial enrollment, I don't know that it adds any security to require it for re-enrollment.

Other considerations.

OTP Tokens have some distinct advantages over other 2-factor methods.   Chief among these is that the user, password, and OTP are validated at the same time, so when a failure occurs, a password guesser obtains no information about which value was incorrect.   A second benefit is that the Authenticator application does not require a communication channel with the server, so it can be used during foreign travel, in places where cell phone usage or text usage may be very expensive.

One possible objection to OTP comes from the second benefit -- the server has no way of knowing how many devices (or even which devices) have been activated for any particular user.  Users with both a cell phone and a tablet may wish to activate the OTP token on multiple devices.  Given that the goal of 2-factor is to check both something you know (the password) and something you have (the device), I don't know that it is a security problem for multiple devices to be activated at once.   However, I suspect that this is your motivation, and you have found the only way that I know to (attempt to) enforce a one-device policy.   Even then, you cannot prevent a user from displaying the QR code and synchronizing two devices at once during the initial setup.

DUO is a third-party product that has been formally tested with UTM, and it provides alternatives to OTP tokens.   I believe all of them are two-step verification methods, where you validate using your username and password, and then the system contacts you by another method for 2nd-factor.   This 2-factor approach is attractive in large environments where a diverse user base makes a variety of 2-factor methods essential.   However, it does allow more opportunity for password guessing attacks, since the 2nd-factor authentication check only occurs after the password has been entered correctly.

Thank you for your comprehensive answer.
I understand the considerations that have been made to Functionality like it is.

We probably have the unique situation in which external contacts must be able to connect.
They get their OTP code from an internal engineer who guides them with making the connection, and have the OTP generator.
These external contacts may therefore not see the OTP data, otherwise they can make a not guided connection later.

We have more connections to this kind of connections than people who do need to be able to access the OTP data.

In our situation we would therefore like to hide the OTP data for all users, to prevent security errors being made ans set the OTP data open for those who need it.

Once again I understand the considerations for how it is now built, but from mine point view it is one extra choice.
Now the OPT data is open as standard.

An option to close this standard should not be very drastic in my opinion.

Opening and / or closing OTP data individually would then remain the same.

For now I close this call but I still hope sophos will handle this message as a feature request.

Best Regards

Peter

Change requests need to be submitted on the ideas.sophos.com website.