1

I work for a small ISP that hosts e-mail for some 6,000 users, and we're in the process of upgrading to a new Debian mail server. One of the many requests we get from our users is to be able to change their e-mail passwords themselves.

In the past, we've avoided this option except for qmailadmin, which is only given to select few business customers we can trust. Generally speaking, letting users change their own e-mail passwords has been in my mind, a recipe for disaster. Not only does it mean that they are likely to use astonishingly stupid passwords, but the possibility of code errors allowing attackers to change everyone's passwords is probably pretty high.

Also, historically, we've had Webmail (Squirrelmail and Horde if you want to know) running on a separate server entirely, but many HOWTOs say to put them on the same server. Again, this is something I've avoided because I'm paranoid, but probably rightfully so. If I recall correctly, this is the biggest reason why users can't change their passwords through their own webmail.

Am I being too paranoid, or is this just the reason why noone has broken into our mail server for the past 7 years? (except the odd spammer phishing for user passwords)

2 Answers 2

2

I think you're being too paranoid. User-driven password changes allow users to select passwords they find memorable, change passwords when they suspect their boyfriend / girlfriend / mother is spying on them, etc.

There's no reason for a password-changing app to be a security hole. Separate the hell out of the UI and the back-end logic, perhaps writing a simple CLI tool to perform the database manipulation and calling it from the web app. This way your CLI tool can perform its own sanity checks on every request it receives.

Some user/password databases have well-tested, reliable password changing mechanisms already, like OpenLDAP's Password Modify extended operation.

Yeah, I recommend keeping webmail on a different host. I've managed several large email sites over the years and the only compromise I've experienced was when I failed to keep the webmail app up to date. Webmail apps are large, complex, and frequently not designed with an eye to security.

0

You could also set it up so that users are not allowed to make simple passwords. I'm assuming that in your current environment, you are changing passwords for your users? If so, are you using a random generator, then just giving the password it generates to them? I wouldn't want that situation either, by having access to their passwords at one point or another, it seems like it could be a liability for you.

4
  • Sure, then you get passwords like "Password1" that strictly satisfies the minimum "upper and lowercase letters plus digits, 8 characters or more" rule. And then I implement the "no dictionary words" rule and piss everyone off. There's no way to implement automatic password checking in a way that prevents moronic passwords while making them simple enough to remember and/or being utterly fascist about them.
    – Ernie
    Aug 19, 2009 at 19:00
  • You might want to consider worry a bit less about password strength and instead setup some kind of lockout mechanism after failed login attempts. Also consider these days it seems a user is just as likely to get a keylogger from some evil web site, and with a keylogger it doesn't really matter how good the password is.
    – Zoredache
    Aug 19, 2009 at 19:15
  • Also, security necessarily isn't made to make the end user happy, but to keep things secure.
    – DanBig
    Aug 19, 2009 at 19:40
  • The goal is to make them hard to guess but easy to remember. It's easy to reach a point of diminishing returns when adding password rules. At some point the users start going around the security because it has become too much of a burden to them (writing down passwords, using stupid patterns etc...) Find the balance or the users will find a way to tip the scales.
    – Chris Nava
    Aug 19, 2009 at 20:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .