Viscosity not sending credentials (static-challenge)

Got a problem with Viscosity or need help? Ask here!

viscogrem

Posts: 12
Joined: Tue Feb 23, 2016 9:06 pm

Post by viscogrem » Tue Jun 14, 2016 12:23 am
When password and static-challenge combined are too long (we faced this with a 48 character password and a 48 character static challenge, so 96 characters in total), Viscosity doesn't seem to send credentials at all and we get this server side error message:

TLS Error: Auth Username/Password was not provided by peer

In this case the connection attempt to Viscosity times out and the user has no clue what to do.

To give you some background, this is how we got into this situation:

We use a combination of a known static secret and a generated one-time password, which are combined 48 characters in length. Originally the user would enter their username and this combination of a well known secret and a password into the "Login/Password" dialog.

As users try to save time, they started using the "remember credentials" checkbox, so they wouldn't have to enter their username on every login. As a result, they would always produce one failed login attempt on connect, and then enter the correct password. This is clearly suboptimal, as the extra failed attempt takes time and increases the chance of locking oneself out of the system after too many failed attempts. Also, this way the static secret would always end up in the keychain, reducing its usefulness.

So to fix this problem, we started storing the username and a short irrelevant password in the keychain, and request the actual password plus OTP string through a static challenge (configuring "static-challenge" in the Advanced tab). So if a user connects, they now just get a one line dialog with a useful title (which renders fine on Mac, but has some line-height layout issues on Windows).

Unfortunately this causes another problem:
If a user mistypes the password or mishandles the token, authentication will fail and they're returned to the "Login/Password" dialog. Most users are not really aware what's going on at this point, so they remove the stored password and replace it with the static secret plus OTP (48 characters in total). Which creates two problems, on the one hand we now stored the static secret in the keychain, which is something we don't want to do. On the other hand we now have the problem described above, which means that users get stuck.

Fixing the problem is relatively easy - just enter a short static challenge, so that Viscosity actually sends credentials to the server, which then fails and makes Viscosity present the username/password dialog again, so the user can enter a short random password there. Obviously this is nothing that most users figure out on their own, so it's quite a pain to support them.

So besides addressing the primary issue this post is about (users getting stuck), it would be really helpful to have an option to support our use case, which is either allowing to store the username without storing the password (A), or allowing to have static-challenge only authentication, in which case the login dialog would only collect the username and not show/use a password field at all (B).

Both options have advantages - some users prefer to be able to change the username for testing, why most users are happy with the convenience the static challenge dialog provides.

In case of (A), having the opportunity to configure a custom message to the user would be quite useful (this is what we currently do with static-challenge, instructing the user to enter their static secret and use the OTP token).

Thanks,
Michael

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Wed Jun 15, 2016 10:45 am
Hi Michael,

If only a username and a OTP are required for authentication, then I'd recommend using just the Username and Password prompt. You can disable the option to allow credential saving from the Terminal like so:
Code: Select all
defaults write com.viscosityvpn.Viscosity KeyChainSupport -bool false
And if you still want to allow just the username to be saved:
Code: Select all
defaults write com.viscosityvpn.Viscosity RememberUsername -bool true
If needed these options can be pre-set in a bundled version of Viscosity:
http://www.sparklabs.com/support/kb/art ... ences-mac/

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

viscogrem

Posts: 12
Joined: Tue Feb 23, 2016 9:06 pm

Post by viscogrem » Fri Jun 17, 2016 6:29 am
Hi James,

Thank you for your reply, that sounds quite useful. I assume that those settings are global. Are there comparable settings for Windows (we run a mixed environment)?

- Michael

p.s. I'm not certain if the problem of Viscosity not sending credentials when both secrets combined are too long and not presenting a dialog to correct credentials also happens on Windows. I would assume so, but can test if required. I would suggest to look into this problem, it's quite confusing for the average user.

viscogrem

Posts: 12
Joined: Tue Feb 23, 2016 9:06 pm

Post by viscogrem » Fri Jun 17, 2016 7:04 am
Hi James,

One more question: We also use client certificates to authenticate the user. Won't disabling keychain support also stop saving the certificate password in the keychain (that would be a show stopper for us)?

- Michael

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Thu Jun 23, 2016 1:35 pm
Hi Michael,

Viscosity Windows does have corresponding options. For example:
Code: Select all
"C:\Program Files\Viscosity\Viscosity.exe" SetPref PasswordStorageSupport false
While Viscosity itself doesn't place any limit on passwords (or challenge responses), OpenVPN itself does. That said, we haven't actually seen anyone ever hit the limit like this, so unless your OTPs are unusually long I'd be inclined to think your server implementation may be limiting the length.

If you are using an encrypted client key or PKCS#12 file that requires a password, then yes, disabling Keychain support will mean the user will need to enter the password for this when connecting.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

viscogrem

Posts: 12
Joined: Tue Feb 23, 2016 9:06 pm

Post by viscogrem » Fri Jun 24, 2016 2:00 am
Hi James,

As we need to store the certificate passwords, this solution unfortunately won't work for us.

Our server implementation is the standard open source version of OpenVPN, so you should be able to reproduce the issue quite easily. Like I described above, the total length of OTP + password is 48 characters, which works fine, but not if it has been entered in both fields by accident, in which case the connection attempt times out and the password dialog isn't shown to users again, so they can't correct the mistake and get stuck.

- Michael

viscogrem

Posts: 12
Joined: Tue Feb 23, 2016 9:06 pm

Post by viscogrem » Mon Aug 15, 2016 10:28 pm
Hi James,

As I didn't hear back from you, this is what a good solution would look like to us:
  • Login/Password screen that stores the user name, but does not store the password in the keychain.
  • Client certificate passwords are still stored (keychain)
  • Configurable per connection
  • Works cross-platform (Mac/Win)
So ultimately, a stripped down feature request would be:
Allow per profile configuration to not store the connection password in the keychain, without affecting any existing username/password storage settings.

Is there anything we can do to sponsor such a feature (beyond the >100 licenses we purchased so far)?

Thanks,
Michael

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Thu Aug 18, 2016 2:46 pm
Hi Michael,

Thanks for the feedback - we'll take it on board. We can't commit to future features, but we do take requests on board when adding features or prioritising what to add or change next.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

viscogrem

Posts: 12
Joined: Tue Feb 23, 2016 9:06 pm

Post by viscogrem » Tue May 16, 2017 8:11 pm
Any chance this will make it to your roadmap any time soon?

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Wed May 17, 2017 7:56 pm
Hi viscogrem,

We still have an open ticket for looking into potential password length issues when combining with a static challenge response, however I'm afraid we haven't had a chance to investigate further as of yet.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
10 posts Page 1 of 1