openvpn_inc wrote: ↑Fri Jan 14, 2022 6:42 pm
The PBKDF2 parameters used are 16-byte random salt, SHA256 hash, 32 length, and 10000 iterations.
And no, we don't offer customizability of this. So you can't use some parameters to influence how this is generated in sacli, sorry.
The length of the salt and the hash are both good. This is a huge improvement and thank you for doing this.
Could you *please* put in a feature request for a future version to allow changing the number of iterations?
openvpn_inc wrote: ↑Fri Jan 14, 2022 6:42 pm
If that is something you really need though you can consider using a credential management system like PAM, LDAP, or RADIUS, and configure the exact method you want the backend to store it in there.
Not all of our use cases of OpenVPN AS lend themselves to being able to use LDAP or RADIUS (the situation is outside of my control).
I considered using PAM but OpenVPN AS provides a lobotomized support for it.
Any application supporting libpam must call the function pam_start() which requires supplying a service name.
Here is the documentation for that function call:
https://man7.org/linux/man-pages/man3/pam_start.3.html
Most applications supporting libpam allow setting that service name based on the type of service authenticating. Here is an example of an Apache web server module being set to use the PAM service name of "tlwiki":
https://www.adelton.com/apache/mod_auth ... e%20tlwiki
OpenVPN AS seems to be hardwired to only call with the service name of "login" which if a company's security policy doesn't allow using renders the PAM support useless. It is a little like if LDAP or RADIUS was only supported if the authentication server was running on the hostname of "localhost" and the hostname could never be changed.
It isn't clear if OpenVPN AS plans to ever address this by allowing setting the service name of "login" to something else. If this was fixed in a future version it would greatly improve the current situation for us.
openvpn_inc wrote: ↑Fri Jan 14, 2022 6:42 pm
And no, it doesn't get updated during next login, only when you change the password.
Ok, so if an OpenVPN AS administrator is concern about rainbow table attacks possibly occurring against the unsalted hashes, what is the cleanest procedure going forward to resolve this?
As far as I can tell, there is no option for the OpenVPN AS local authentication method to expire passwords and force a password change on next login.
Are we supposed to run a sacli UserPropGet periodically, find every pvt_password_digest of 64 characters in length and then email the users reminding them to change their password in the hopes someday they will?
Some further guidance or features to address this would be helpful.
Thanks