Il 21/09/2015 14:59, Drew Wells ha scritto:
On 09/17/2015 12:28 PM, Tonix - Antonio Nati wrote:
Il 17/09/2015 13:18, Drew Wells ha scritto:
On 09/15/2015 03:27 PM, Tonix - Antonio Nati wrote:
Il 15/09/2015 15:03, Drew Wells ha scritto:
On 09/15/2015 11:00 AM, Tonix - Antonio Nati wrote:
Il 15/09/2015 11:03, Drew Wells ha scritto:
In vpopmail-5.5.0 there seems to be a bug in vpopmail.c where
the password strength is checked even if a password isn't used
(such as when -e is used to add the encrypted password). Patch
attached.
I do not understand the problem.
Of course password strenght is checked every time, and if it
founds a null/empty password it gives error back if password must
have a minimum lenght.
Your patch instead permit to have null password even if strenght
policy would not allow it.
Regards,
Tonino
The problem is is that vadduser.c can call vadduser() (in
vpopmail.c) without a password. It does this in the situation
where vadduser.c has had the options "-e" or "-n" passed to it, so
if this is the case the password can't be checked againts the
password strength rules. The underlying function vadduser() needs
to be able to add a user with no password.
I realize additional controls are done before calling vadduser();
but I personally would prefer an explicit parameter added to
vadduser for avoiding password check (it may be a further parameter
having default = "check").
It would make developers more protected against unwanted security bugs.
Regards,
Tonino
I agree that it would be better to explicitly indicate to vadduser()
that no password is wanted. I even looked quicky at setting the
password to NULL to indicate no password, but both this and an
explicit parameter would need changes to all the backends, so have
left it as is for now.
It could be done in two ways:
* considering most od c compilers are c++ compilers, and that means
we can add an implicit parameter (, nocheck_pwd = 0)
* duplicate the function for this usage, and call the duplicated
function from avdduser when needed.
Regards,
Tonino
I have looked at the backends and it turns out that some of the
backends can handle a NULL gecos, so expanding on this I have changed
all the backends to be able to handle a NULL gecos (in which case they
now all use the user as a gecos) and also handle a NULL password. So
vadduser.c can pass a NULL password to vadduser(), vadduser() can then
check the password_strength() when the password is not NULL.
I think that permitting a null password, if policy does not admit it, is
a security hole.
Prefer you you add another explicit call to be called for no password
checking (at all).
Regards,
Tonino
This is going to be the patch I use here, does anyone want this patch ?
--
------------------------------------------------------------
Inter@zioni Interazioni di Antonio Nati
http://www.interazioni.it to...@interazioni.it
------------------------------------------------------------
!DSPAM:5600059741551931516382!