Atomicorp

Just had 10,000+ spam messages added to the mail queue.

I think it down to a password guess because a user had selected username123 as the password for email address username@domain.tld.

After dealing with the problem itself, I realised something wasn't right. Doesn't Plesk stop users from selecting a password containing the username?

Errr.. yes, it DID. In the past. In 8.6 there was an tick box for dictionary words and other things if I remember correctly.

But what about in 10 and 11? I can't find the option I'm looking for. There doesn't seem to be anything at all other than a drop down in Tools & Settings -> Mail Servert Settings that allows you to choose from very weak to very strong, and that seems to be some sort of algorithm thing. No mention of dictionary words or usernames in the docs.

Is this the only option now? Or is the option I'm looking for somewhere else?

ASL reports weak accounts in /var/asl/reports/password.report. I recommend monitoring that file and alerting when it's not an empty file.

Unfortunately it didn't flag those passwords. I don't know what algorithm it uses to decide what weak is. I need to look into that.

It is, however, flagging email accounts that have been deleted from the server. Possibly implying that either a database didn't get updated in Plesk or a directory didn't get removed in qmail. Both worrying. I'll have to investigate.

I have discovered that the very-weak to very-strong setting for email passwords in Plesk is actually good enough for the job. Unfortunately it isn't very flexible. And not end-user friendly. I've had to change the help text quite a bit to make it even half-way useful. The parallels strength algorithm is mysterious and undocumented as far as I can see.

Still, I don't know why on earth there's a facility that prevents usernames in passwords for FTP and Plesk accounts and a totally different method that doesn't do this for password selection for email and user accounts. Seems odd.

The code that checks the passwords is:
/var/asl/bin/psa-password-check.pl

It could certainly use improvement

right. we need to add regular expression username/password comparison, case-insensitivity, password- and maybe basic l33t character replacement, plus all this on a reversed password/common words.

I can do most of this, but it may be a bodge due to Perl being a foreign language to me.
Watch this space.

Of course we get to the point where the password isn't necessarily "simple" when we add some/all of these, but it might be useful to know.

It doesnt have to be perl, in fact we're in the process of removing all the perl dependencies already so this would eventually be re-written in C or PHP (which can be compiled into C) anyway.

ok. well, I'll do it in pseudo-code first and go from there.

Yeah dont feel constrained by languages, go with whatever you are comfortable with.