• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Webmail password policies

JaapHoetmer

New Pleskian
Hello,

I am looking for answers to know whether password policies are adjustable in the Horde webmail module. I noticed that the server options available via the web interface do not include a lot, I wanted to know if a maximum amount of password retries could be configured, as well as a timeout period before new password attempts could be tried, or an automatic login disablement at an x amount of password attempts.

If I have accidentally placed this message in the incorrect forum, my apologies.

Thanks for your help.
 
Webmail simply connects to the same imap program that a remote client using an email client such as Outlook connects to. Effectively Webmail IS just an email client - but one that happens to run on the same server as all the other bits.

So this means that none of the things you want are available as they are not features available in psa-courier-imap.

Worse still, because the connection is usually via 127.0.0.1, using a third party product such as fail2ban or ASL will not be an effective option as you can't block 127.0.0.1 without causing severe problems.

This sort of thing is certainly a feature that we need in Plesk, but it needs to be global - not just IMAP but also POP3 (and SMTP).
 
Thanks, Faris, for the explanation.

That means that webmail is basically a very insecure option. Anyone can script into an account because there's no limit on the number of retries; it's just a matter of time (and of choice of strong or weak passwords).

Is this something that is being worked on to improve?
 
Hmmm....I'm not sure if Dovecote would help here or not. There have been requests for it to be used instead of or as an alternative to courier-imap.

The security mechanism would have to be quite complex and probably double-pronged:

Login failures via remote IMAP/POP3 connections can be dealt with using various mechanisms as I mentioned before.
But having thought about it more, I now think you'd need a security mechanism within the webmail client, not the IMAP client. (i.e. I was wrong).

For example, imagine you have a secueity mechanism within the IMAP client that says "ooh! [email protected] has used the wrong password 10 times in a row. I'd better block that username for 10 minutes". That's great, but what if the bad guys are doing this over and over again? The actual legitimate mailbox user will be locked out of their account for as long as the bad guys are trying to get into it. That would be bad.

So it would, in fact, have to be the webmail client that tracks failed logins, then blocks the connecting IP if there are more than X failed logins within a particular timeframe. In this way, the legitimate mailbox user will not be blocked. And if the webmail client can communicate with the firewall, the bad IPs can be totally blocked, not just from webmail but from the server as a whole.

However, we are seeing more and more botnets being used to try to gain access to accounts. And with 1000s or 10,000 or 100,000 different IPs each trying a login one at a time, slowly, each individual IP keeps under the radar for blocking.

Now, going back to what I just said, a product like ASL (www.atomicorp.com) might actually solve the problem, though not necessarily all by itself.

What we would need would be for the webmail client to simply log failed logins, along with the connecting IP. ASL (and other products) could then use this log data to decide to block the connecting IP on a firewall level.

Some very simple code could be added to horde to achieve this, I think. There may even be something already in place and I just don't know about it. I will post on the atomic forum to ask this very question.
 
Thanks again for the reply, Faris.

Your first reply stirred some further thought. If webmail is just another piece of IMAP client software, then the insecurity lies within IMAP, not the webmail client. IMAP accounts can thus also be tried over and over again without any lockout or retry delays. So it doesn't make the use of a webmail component inherently less secure than the IMAP server.

Only the fact that it is browser-based makes it in that sense more accessible to casual attempts in order to gain access to accounts, but fundamentally they both use the same level of account credentials validation.

If IMAP (and POP and SMTP) would have this level of account validation management, then any webmail or IMAP connection would automatically make use of this. So in my view that is where the extra security steps should be taken.

In any case, the use of IMAP or Webmail in this current scenario does not make much difference security-wise, correct?

Thanks, cheers,
Jaap
 
First of all if I have accidentally placed this message in the incorrect forum, my apologies.

I want to know is there anyway for the admin to lock the change of password for the users in Paralles Helm?

The thing is I have been given an account in SmarterMail in the new company I have joined in recently and I was wondering does the admin whom I have seen logs in through Paralles Helm has option to see my new password there or making it limited in the future for the sake of access control on my account in SmarterMail?

Thank you,
Lillian
 
Back
Top