I'm in no way stating that that webmaster21312 password is secure, however I'd say that length issues are important here as often the complex parts of a password are near the end [ie: dogguy45b]. If this was me, I'd completely agree and never have a password like that. However it seems that my users on the other hand do like this sort of thing, which is a security consideration in its own respect. Yes those numbers are a bigger difference, but has the same effect in my case- webmaste is identical to webmastejashfdajsfhasfjashfasj - which is the furthest thing from the truth.

I believe what you say (that if I enable MD5 passwords, then it will work for both), but I think that might be a documentation issue.
" --enable-md5-passwords=y|n Turn on (y default ) or off (n) to store encrypted passwords as md5."
There should really be a note that it will accept existing crypt passwords but store new ones in MD5. This would ensure that users looking to migrate know what's going on. I just didn't want it to stop working when migrated users.


From: "Paul L. Allen" <[EMAIL PROTECTED]>
Subject: [vchkpw] Re: SMTP-Auth bug in passwords?
Date: Wed, 10 Sep 2003 13:44:03 GMT

Mike Miller writes:

> Okay, but should it be _allowing_ this as a password or don't you think
> that it should reject it?

I think that it is behaving at it is documented to behave and that your
expectations are wrong.

> There is a very big difference between 'webmaste' and 'webmaster23445'
> in terms of security, as I just found out.

Not a big difference, but more than the difference between webmaste
and webmaster00 which is what you said was being used.  Password cracker
programs try using the username as a password in combination with one
or two digits at the end as the FIRST thing they do.  Mail authentication
is not tarpitted like user logins so a cracker can happily try all
combinations very quickly.  If that mail login also happens to be
the username and password for a user login you start to have serious
problems.  If you think webmaster23445 is secure you need to think

> The reasoning for my use of CRYPT is that most of my users are still from
> when VPOPMAIL didn't support MD5.

Crypt is capable of supporting both styles of password in the system
passwd file so if vpopmail has been coded correctly then it ought also
to support both types of password.  It is a simple matter of using the
crypted password itself as salt when doing a trial crypt of the plain

> But in terms of this situation, the base64 password that the user sends
> would likely be better decode_base64()'d  and then compared against the
> clear-text password.

Comparing against the plain text password would allow longer passwords.
Having plain text passwords is, itself, a security problem.  Think about
users who use the same username and password everywhere, including their
on-line banking.  Think about being the only one of the systems that user
uses  which holds the password in plain text.  Think about what happens
if that user claims there was an unauthorized on-line withdrawal.  Your
system being the only one to have the password in plain text is not
proof of guilt and the others having the password crypted is not proof
of innocence, but you try convincing a jury of that...

Paul Allen
Softflare Support

MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus

Reply via email to