wally
Enthusiast
Enthusiast

2-factor security broken in 2.3.0 version of client (all platforms)?

Jump to solution

We noticed what we think is a bug in the 2.3.0 version of the client. We use 2-factor authentication for view with Radius where users get sent a OTP with SMS to their mobile.

The 2.3.0 version of the client displays this OTP on the login screen (see screenshots below). We already filed a SR for this but haven't received a confirmation on this issue yet.

Curious if anyone else is having the same issue.

Screenshot 2-factor login screen 2.2.0 client

client220.jpg

And this is what the 2.3.0 client does, our users don't seem to mind because they don't have to wait for the SMS to arrive

client230.jpg

0 Kudos
1 Solution

Accepted Solutions
markbenson
VMware Employee
VMware Employee

Which RADIUS Server are you using?

I think that "OTP Challenge: 050989"  prompt is coming from your RADIUS Server when it replies with a RADIUS Access-Challenge in response to View Connection Server RADIUS Access-Request. The prompt text comes from the RADIUS Reply-Message (attribute 18) in the challenge which contains text that should be displayed to the user.

The problem with View Clients prior to 2.3 is that prompt text (RADIUS Reply-Message) for next code coming from the RADIUS server was not displayed by the client and so the client just used a generic "Enter your next xxx response ..." prompt. In some situations this generic prompt was confusing or did not contain sufficient information for the user to know what to do. This problem was certainly corrected in the 2.3 clients so that it does now display the proper Reply-Message.

The View Connection Server (or View Client) doesn't know the next code value so it must be coming from your RADIUS server, which is odd. It may be that this is configurable on your RADIUS Server so that you can specify a more appropriate Reply-Message to users. e.g. "Enter the 6 digit code from your SMS text message" instead of it sending the actual code.

There is no need for a RADIUS Server to send the actual code out in a prompt. The code should only be sent via SMS so that there is the assurance that the user with their cell phone is the person logging on.

As you say, if the Reply-Message prompt sent by the RADIUS server contains the code, it would allow someone to log on with just the initial password, which is not good. Double check your RADIUS Server config.

Mark

View solution in original post

0 Kudos
3 Replies
markbenson
VMware Employee
VMware Employee

Which RADIUS Server are you using?

I think that "OTP Challenge: 050989"  prompt is coming from your RADIUS Server when it replies with a RADIUS Access-Challenge in response to View Connection Server RADIUS Access-Request. The prompt text comes from the RADIUS Reply-Message (attribute 18) in the challenge which contains text that should be displayed to the user.

The problem with View Clients prior to 2.3 is that prompt text (RADIUS Reply-Message) for next code coming from the RADIUS server was not displayed by the client and so the client just used a generic "Enter your next xxx response ..." prompt. In some situations this generic prompt was confusing or did not contain sufficient information for the user to know what to do. This problem was certainly corrected in the 2.3 clients so that it does now display the proper Reply-Message.

The View Connection Server (or View Client) doesn't know the next code value so it must be coming from your RADIUS server, which is odd. It may be that this is configurable on your RADIUS Server so that you can specify a more appropriate Reply-Message to users. e.g. "Enter the 6 digit code from your SMS text message" instead of it sending the actual code.

There is no need for a RADIUS Server to send the actual code out in a prompt. The code should only be sent via SMS so that there is the assurance that the user with their cell phone is the person logging on.

As you say, if the Reply-Message prompt sent by the RADIUS server contains the code, it would allow someone to log on with just the initial password, which is not good. Double check your RADIUS Server config.

Mark

0 Kudos
wally
Enthusiast
Enthusiast

Awesome work Mark. We use radiator and as it turns out attribute 18 was one of the default attributes that was sent, we had to actively filter it. We now use it to inform our users to enter the code they receive by SMS.

0 Kudos
markbenson
VMware Employee
VMware Employee

Thanks for responding. Glad you've resolved it and that this is now answered.

The new 2.3 View Clients give good options now for you to configure a very clear prompt to the user for your specific RADIUS setup when access challenge is used in this way.

Mark

0 Kudos