Hi,
Mailsetup: qmail + vpopmail 5.5.27 + dovecot
Over the years, we didn't store cleatext versions of passwords. Some time
ago,
we wanted to change that setup and since that time, we used vpopmail
compiled
without option --disable-clear-passwd, but know with
option --enable-learn-passwords . step by step, we wanted to get user's
passwords (we discussed that issue here on the list about 2 years ago).
The
reason was, we wanted to change our mailsetup (postfix+dovecot). But that
did
not work, means, cleartext version of password wasn't stored.
All other was working fine and so i didn't change anything. This was a big
mistake, because since that time, all vpopmail mailboxes could be accessed
with an empty passwordstring, at least, if the clients were using cram or
digest authentication.
I know about the misconfigured vpopmail, but i think this behavor isn't as
expected. In the documentation of the option --disable-clear-passwd is
explaned, that this option causes vpopmail to store cleartext version of
passwords in _addition_ to their encrypted versions, and so i think, the
described behavior is at least a security leak.
Your words are confusing, as either you have typos or logical opposites of
what you mean. I think you're saying that you enabled the storage of
cleartext passwords after the fact, but forgot to turn on learing of
passwords, and as a result everyone had an empty cleartext password
stored, allowing access to the mailboxes with an empty password using cram
or digest authentication.
While this may look like a security leak, I would argue that this is
simply the expected result of misconfiguring your system in a manner that
causes security holes. The same can be said for just about any software
that uses logins - if you don't configure it correctly (and monitor it to
make sure it's still working properly), you're going to open yourself up
to unnecessary risks.
I've worked with someone who had to do the whole we want to capture
plaintext passwords after the fact thing, and they set up a very specific
plan in advance and followed it to the letter in order to minimize the
risk - specifically:
1) Recompile vpopmail w/ clear-text passwords and learning enabled.
2) Put it in place and test to make sure that passwords were being captured.
3) Keep it in place only as long as absolutely necessary - in this case, I
think they did it for a month, but it might have been less than that - and
monitor that passwords are being captured so it can be cut short if
everyone has one.
4) Recompile vpopmail WITHOUT learning enabled, put it in place, and force
everyone whose password was not learned to change their password - in this
case by changing it for them and having them call in when they can't
connect (since they hand't connected within the alloted time, it wasn't
likely a big deal).
It sounds like you did step 1, half of step 2, and didn't look at it again
until 2 years later. You can't fault the software for working the way you
told it to and you assuming it was doing something different. Perhaps the
documentation needs to be revised to spell out what not to do if you want
to keep your system secure, but I don't think that's the same as the
software is insecure.
And as to storing both encrypted and plaintext versions of the password, I
can see that there's no NEED to keep the encrypted version if you have the
plaintext one, but then you'd have to have 2 totally separate password
checking routines for non-cram/digest authentication, depending on which
version of the password is stored, and that seems unnecessary to me.
Besides, there's actually a little bit of extra security in the fact that
you're never comparing just a plain text password to a plain text password
- there's always some sort of encryption algorithm involved before the
comparison...
Josh
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
vpopm...@honorablemenschen.com
!DSPAM:4d12170f32711772715885!
