> 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!