Skip to content
Viscosity not sending credentials (static-challenge)
Got a problem with Viscosity or need help? Ask here!
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
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
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:
http://www.sparklabs.com/support/kb/art ... ences-mac/
Cheers,
James
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
And if you still want to allow just the username to be saved:defaults write com.viscosityvpn.Viscosity KeyChainSupport -bool false
Code: Select all
If needed these options can be pre-set in a bundled version of Viscosity:defaults write com.viscosityvpn.Viscosity RememberUsername -bool true
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
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
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.
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.
Hi Michael,
Viscosity Windows does have corresponding options. For example:
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
Viscosity Windows does have corresponding options. For example:
Code: Select all
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."C:\Program Files\Viscosity\Viscosity.exe" SetPref PasswordStorageSupport false
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
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
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
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
Hi James,
As I didn't hear back from you, this is what a good solution would look like to us:
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
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)
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
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
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
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
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
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
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
10 posts
Page 1 of 1