Re: [vchkpw] [SPAM] Password strength bug

2015-09-21 Thread Tonix - Antonio Nati

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@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it




!DSPAM:5600059741551931516382!


Re: [vchkpw] [SPAM] Password strength bug

2015-09-21 Thread Drew Wells

On 09/21/2015 02:26 PM, Tonix - Antonio Nati wrote:

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 ?


Wouldn't it actually be easier to remove the password parameter from 
vadduser() and then vadduser.c can add a user (without a password) and 
then optionally set a password using vauth_setpw() ?  This is exactly 
what it should do at the moment for adding a user with a crypted 
password, the user is added, then the crypted password is set using 
vauth_setpw().



!DSPAM:56000c6d41552022747047!


Re: [vchkpw] [SPAM] Password strength bug

2015-09-21 Thread Matt Brookings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/21/2015 08:55 AM, Drew Wells wrote:
>> 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 ?
>> 
> Wouldn't it actually be easier to remove the password parameter from 
> vadduser() and then
> vadduser.c can add a user (without a password) and then optionally set a 
> password using
> vauth_setpw() ?  This is exactly what it should do at the moment for adding a 
> user with a crypted
> password, the user is added, then the crypted password is set using 
> vauth_setpw().

Because vadduser() previously supported an empty password ("\0"), the change to 
check for this and
skip the password strength testing won't be changing its functionality.  The 
password strength check
was not meant to prevent blank passwords, so the fact that it broke the ability 
to set one would be
a bug, and skipping the call to the password strength checker would be a bug 
fix.  vadduser should
not, however, be called with a NULL password.
- -- 
/*
Matt Brookings    GnuPG Key 62817373
Software developer Systems technician
Inter7 Internet Technologies, Inc. (815)776-9465
*/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWAA4BAAoJEOjQVexigXNzO1EH/iZtAFYiimKNefgU2mgzAwDf
N639Vq/zN6yDtImnBa9lVW37YZQ9IQ1jCNuQZCk91oUQbagMTP37Q3L+HRsGxcHt
tYEmKjvJXFiqNSuBZfmdFdbr8ENz4mvS0GI3VsE02fXUpMLSXAnIUfv+cnN5bCxD
cEs9aEcNQTntcZzKiUWYW+62MpX3BDbZarOpnHmQznihzorn5wcT12gSQo3QGjxp
ZM5LF9UBXOSuus5hFZHxLPQKhcZCvYSS0SpM+hyjLE4JB2nKEiDAVzZ7kqNi6ZV2
K2ocqLDRg1qpXIFGeB2yqobdXSVLEcb9takRE1xAe+v2Ya3YBK09fyBqewfo2qU=
=B/v4
-END PGP SIGNATURE-


Re: [vchkpw] [SPAM] Password strength bug

2015-09-21 Thread Drew Wells

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.


This is going to be the patch I use here, does anyone want this patch ?


!DSPAM:552d41551245420391!


Re: [vchkpw] [SPAM] Password strength bug

2015-09-21 Thread Drew Wells

On 09/21/2015 03:02 PM, Matt Brookings wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/21/2015 08:55 AM, Drew Wells wrote:

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 ?

Wouldn't it actually be easier to remove the password parameter from vadduser() 
and then
vadduser.c can add a user (without a password) and then optionally set a 
password using
vauth_setpw() ?  This is exactly what it should do at the moment for adding a 
user with a crypted
password, the user is added, then the crypted password is set using 
vauth_setpw().

Because vadduser() previously supported an empty password ("\0"), the change to 
check for this and
skip the password strength testing won't be changing its functionality.  The 
password strength check
was not meant to prevent blank passwords, so the fact that it broke the ability 
to set one would be
a bug, and skipping the call to the password strength checker would be a bug 
fix.  vadduser should
not, however, be called with a NULL password.

That was exactly what my original patch on the 15th Sept. did and the 
patch is attached to my original message.  I have not attached my NULL 
password changes patch.  I'll revert the patch I use here to my original 
one.


While looking at all this I have noticed that vmoduser.c allows the 
setting of a "clear_text_password" (-C) but does not do any 
password_strength() testing, is this also a bug ?  Lastly, there does 
not seem to be a way of setting "no password" on an account once it has 
been created, is this correct ?


Do you have any idea what needs to be done with regard to some of the 
backends being able to accept a NULL gecos ?


!DSPAM:5600119641556874115760!



Re: [vchkpw] [SPAM] Password strength bug

2015-09-17 Thread Drew Wells

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.



!DSPAM:55faa1a741551399290072!


Re: [vchkpw] [SPAM] Password strength bug

2015-09-17 Thread Tonix - Antonio Nati

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


 



--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it




!DSPAM:55faa3e241551872413518!


[vchkpw] Auto-Re: [vchkpw] [SPAM] Password strength bug

2015-09-15 Thread zhaopin
尊敬的同学:您好!

您的求职简历已经收到,我们会尽快进行阅评,之后再决定是否与您面谈!


  中信泰富(中国)投资有限公司
 人力资源部

!DSPAM:55f7e0eb41551555158803!



Re: [vchkpw] [SPAM] Password strength bug

2015-09-15 Thread Tonix - Antonio Nati

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

--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it




!DSPAM:55f7ec4641551939410840!


Re: [vchkpw] [SPAM] Password strength bug

2015-09-15 Thread Tonix - Antonio Nati

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


 



--

Inter@zioniInterazioni di Antonio Nati
   http://www.interazioni.it  to...@interazioni.it




!DSPAM:55f82abc41552085678254!


Re: [vchkpw] [SPAM] Password strength bug

2015-09-15 Thread Drew Wells

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.




!DSPAM:55f8173d41558919512318!