The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Best approach for targeting weak email pws

Discussion in 'E-mail Discussions' started by net123, Mar 25, 2013.

  1. net123

    net123 Member

    Joined:
    Oct 20, 2008
    Messages:
    9
    Likes Received:
    0
    Trophy Points:
    1
    May be too delicate for open discussion (please pm me) but we'd love to know if any of you found solutions to weak email passwords? We spend way to much time tracking down and changing pws after the fact. At the same time I really don't want to force new pws on every single box and every single user - I'm not sure that wouldn't be worse for us and our resellers, but maybe it's the only way.

    Thx - Dave
     
  2. net123

    net123 Member

    Joined:
    Oct 20, 2008
    Messages:
    9
    Likes Received:
    0
    Trophy Points:
    1
    Just curious... new here, perhaps that's why there are no responses yet? I would have thought this would be a very hot topic for every cpanel user. Perhaps I am late to the discussion or... early? I have searched these forums for clues on this topic - I started with 2 factor verification hoping we could implement that as Google has with gmail (which I use but I'm not sure that our clients would warm up to it).
    Anyway, any tips on the state of this topic or feedback, always appreciated.

    Dave
     
  3. Infopro

    Infopro cPanel Sr. Product Evangelist
    Staff Member

    Joined:
    May 20, 2003
    Messages:
    14,468
    Likes Received:
    196
    Trophy Points:
    63
    Location:
    Pennsylvania
    cPanel Access Level:
    Root Administrator
    Twitter:
    Starting off with a good plan is the best way to go, I think.
    Password Strength Configuration - cPanel Documentation

    But, thats not always possible. In those cases, force new passwords on just those you have concerns about. You don't have to select all users, AFAIK.
    Force Password Change - cPanel Documentation

    As far as Two Factor Authentication, please review this Feature Request located here:
    Two-factor Authentication - cPanel Feature Requests

    Hope that helps. :)
     
  4. net123

    net123 Member

    Joined:
    Oct 20, 2008
    Messages:
    9
    Likes Received:
    0
    Trophy Points:
    1
    Thanks, we appreciate your response - we have seen those tips btw and read the docs, and they look promising but they inspire plenty of questions as well, like:

    Would invoking stronger passwords be only for new pws - new ones created going forward? Or would it cause current weak ones to have to be updated, specifically weak email pws?

    For the amount of time we spend chasing after spammers because of users who have "bob123" as an email pw we would seriously consider mandating ALL email and cpanel access pws be changed. But we obviously want to do it in the most user friendly way possible (it's a pretty unfriendly thing to begin with but not doing it is even less friendly). So if we could mandate new passwords for email, how would that work? Would clients get a warning screen or some other "you must first update your password..." notice?
    My understanding is that when cpanel pws are mandated a user can log in to a limited cpanel and MUST then update their pw to a better one before getting access to the entire feature set. Does email work in a similar way?

    Yes! I did vote for the 2-factor auth new feature. My only change to Google's implementation would be to have it last for longer than 30 days.

    Again, appreciate your suggestions. This feels like the most urgent of all issues we face as a host, especially since it effects every client we have.
     
  5. net123

    net123 Member

    Joined:
    Oct 20, 2008
    Messages:
    9
    Likes Received:
    0
    Trophy Points:
    1
    Thanks for the reply Infopro! Yes, we have seen and reviewed those docs - we also voted for the 2 Factor Auth feature, we're definitely ready.

    A while ago we upped our password strength as recommended, but that does not address the 90% of our client base, current clients with weak passwords. When we request all users update their pws, typically it's the users with weak passwords that don't follow our suggestion!

    We spend so much time tracking hacked email accounts now because of weak pws, that we are in fact considering changing all email and cpanel pws. My question about that is: what does it look like from the client side? I know that requiring an update to a cpanel pw, the client can log in with the old one and only get a limited access to the cpanel and they are directed to update their pw first before getting complete access. IF email worked the same way we'd jump at that - if a user was somehow prompted to change their email in order to get their mail and not just getting a pw error, that would be amazing. But I don't think it works that way, correct?
     
  6. Infopro

    Infopro cPanel Sr. Product Evangelist
    Staff Member

    Joined:
    May 20, 2003
    Messages:
    14,468
    Likes Received:
    196
    Trophy Points:
    63
    Location:
    Pennsylvania
    cPanel Access Level:
    Root Administrator
    Twitter:
    If you don't have one already, create a test account for testing and force that user to update their password. Some testing on your part will go a long way in understanding the limits of what you can and cannot do, and how things work.
     
  7. net123

    net123 Member

    Joined:
    Oct 20, 2008
    Messages:
    9
    Likes Received:
    0
    Trophy Points:
    1
    Thanks for the tip, certainly, we'll do testing, just thought this was something everyone had need for so some kind of standardization was already in place.
     
  8. net123

    net123 Member

    Joined:
    Oct 20, 2008
    Messages:
    9
    Likes Received:
    0
    Trophy Points:
    1
    I also noticed that none of these options change any of the client email passwords (not talking webmail), or am I missing something? Is there an option for force changing those?
     
  9. mtindor

    mtindor Well-Known Member

    Joined:
    Sep 14, 2004
    Messages:
    1,281
    Likes Received:
    37
    Trophy Points:
    48
    Location:
    inside a catfish
    cPanel Access Level:
    Root Administrator
    Although I agree that weak passwords should not be used/tolerated, and that it is extremely difficult to get those who use weak passwords to change them, I think everyone should keep in mind that all email hijackings aren't due to weak passwords.

    I know that in the past month or so there has been some sort of client-side vulnerability being exploited that then installs a trojan/malware that either sniffs the email credentials or logs keystrokes and obtains email login credentials. I've seen this across mail platforms (cPanel / Smartermail / Mdaemon / Imail). I've seen quite a few breached accounts, and in quite a few of the cases the new secure passwords were obtained within two hours of them being changed on the server. That tells me that the passwords are being discovered on the client side. And, in many cases the original passwords were not weak to begin with. After having seen enough of these instances, I insisted that the clients run AV scans of their system using multiple scanners and some sort of malware scanner like MalwareBytes, and in every case they notified me that one or more trojans had been found on the infected systems. In particular, these were the Canadian pharma spammers.

    Typically one IP address would connect to the server to verify that the credentials were valid. That IP would never actually relay spam. Within an hour or so, IPs from all over the world would start connecting and relaying spam [at low volumes per IP usually], indicating that it was also botnet controlled.

    Granted, this is a specific type of spam I'm referring to -- Canadian pharma spam via hijacked email smtp auth credentials and using an otherwise legitimate mailserver for relay.

    So I at this point I would always suggest/insist that the customer run a full virus scan with one or more reputatable AV packages, after having turned off System Restore and booted to Safe Mode [windows, obviously] and to also run MalwareBytes or some other effective malware scanner.

    At least that has been my experience.

    Keep in mind, that a lot of server admins use something like CSF to block too many failed auth attempts. If you are restrictive [only allow a low number of failed auth attempts] before temporarily blocking POP3/smtp auth brute forcing, it is highly unlikely that somebody is going to brute force any but the weakest and most common of passwords. Granted, there are a lot of people out there using assisine weak passwords. But there are many more email accounts hijacked that aren't weak and weren't brute forced, leaving a client-side infection as the likely culprit of the email credential leakage.

    M
     
  10. net123

    net123 Member

    Joined:
    Oct 20, 2008
    Messages:
    9
    Likes Received:
    0
    Trophy Points:
    1
    mtindor - thank you so much for the reply and info. I am both encouraged and discouraged by your answer - it seems that there's nothing to it other than to keep shoveling as fast as we can. But - best not to inconvenience any/all clients with an unnecessary change to their service and hours of work on our end if it's not the fix we need.
    I wish someone would come up with a way so that only the client can send email from their boxes, like an ip verification - I suppose that could be cracked too though.

    Thanks again,
    Dave
     
  11. mtindor

    mtindor Well-Known Member

    Joined:
    Sep 14, 2004
    Messages:
    1,281
    Likes Received:
    37
    Trophy Points:
    48
    Location:
    inside a catfish
    cPanel Access Level:
    Root Administrator
    Dave,

    I'm not sure which is worse -- (a) weak password brute forced and used to auth/relay spam or (b) customer machine infected with trojan that in one way or another steals auth which is then used to relay spam.

    If it's a weak password, in my mind it's so simple to at that point change the password and make sure the customer no longer has the opportunity to use weak passwords. If it's a compromised machine, you only know that if the customer tells you. If you have a "vibe" that the customer machine is infected, it's not an easy task to convince them. In my experience, customers are very put off when I even remotely suggest that their may a virus/trojan/malware on their computer. Fortunately, recently I've had some sucess in getting them to properly scan their systems and most have them have discovered infections.

    Do keep in mind that you can impose a stronger password strength from here foreword without forcing all existing customers to change their password. Then, if they need to change their password on their own, they are suddenly forced to meet a minimum security. Or if their account gets hijacked and you change the password, you can just explain to them then that they need to use strong passwords.

    When the option to set a password strength for email (via WHM) became available, I simply set the password strength high. It didn't stop current weak passwords from logging in. It simply stops anyone from setting a new password that is weak. So your existing clients with weak [but non hijacked] passwords continue on without skipping a beat.

    So I'd suggest that you set the password strength for email to something significantly higher, and then don't even tell your customers. If they try to change their password, they'll learn quickly enough that it must meet a certain minimum strength requirement. If they currently have a weak password and their account gets breached, you can simply explain to them at that time that the system automatically enforces a requirement for a strong password.

    I wish I had an idea for some alternate method of providing additional authentication for SMTP authentication, but in general I think we're all stuck (on any mailserver) with the method we have now.

    Mike
     
  12. alphawolf50

    alphawolf50 Well-Known Member

    Joined:
    Apr 28, 2011
    Messages:
    186
    Likes Received:
    2
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    Here's some info I put together regarding finding and strengthening the passwords on your system:

    Finding Weak Passwords (The Easiest Method):

    Log in to SSH as root and run this:
    Code:
    find /home/ -type f -wholename '*pwcache/*' -exec grep -Hi strength {} \; | awk -F ':' '{print $NF,$0}' | sort -n
    That will show you the strength of many (but not necessarily all) email passwords on the system, sorted by by the strength as determined by cPanel. The output will look something like this:
    Code:
    60 /home/user1/etc/[I]example.com[/I]/@pwcache/[I]info[/I]:strength:60
    82 /home/user2/etc/[I]example.com[/I]/@pwcache/[I]postmaster[/I]:strength:82
    82 /home/user3/etc/[I]example.com[/I]/@pwcache/[I]postmaster[/I]:strength:82
    86 /home/user4/etc/[I]example.com[/I]/@pwcache/[I]orders[/I]:strength:86
    
    The first (and last) numbers are the strength of the password. Near the end, you'll find the local part of the email address (i.e. postmaster@), and somewhere near the middle you'll see the domain. Users with very weak passwords should be forced to change their password. Before you force anyone to change their passwords, make sure you've read the section at the bottom titled "Upgrade Your Hashing Algorithm".

    Testing Account Passwords:

    If you really want to find the weak passwords, round up all the shadow files and run them through "John the Ripper" with the rockyou.txt wordlist. That's Script Kiddie 101, so anything that fails here is dangerously weak. I won't go through how to use "john" (there are plenty of guides), but to collect the contents of all shadow files in one go, use:
    Code:
    find /home/ /etc/ -type f -name 'shadow' -exec grep '\$' {} \; | sort | uniq > allshadow.txt
    Everything will now be in the file "allshadow.txt". Run john on that file, and any accounts that are cracked should be asked to change their passwords. There are many password lists to test against, (rockyou.txt possibly being the most comprehensive), so try a few. It would be a good idea to cross-reference the output obtained from "The easiest method" above, and see what strength of passwords you are able to crack. Set your minimum password strength above this number. Before you force anyone to change their passwords, read the next section...

    "Upgrade" Your Hashing Algorithm:

    This section perhaps should have come first, but since it would have slowed down the password cracking in "Testing Account Passwords", I saved it for last. Slowing down password cracking is of course the reason you want to do this :)

    If you're running CentOS/RHEL 5, chances are your passwords are hashed with md5. As of cPanel 11.34, cPanel supports sha512 for password hashes. Once you've increased the minimum password strength to prevent new bad passwords, it would be a good idea to "upgrade" the password hashing algorithm to sha512. First, check which algorithm you're using by running this as root in SSH:
    Code:
    authconfig --test | grep hash
    If it says you're using md5, run the following to switch to sha512:

    Code:
    authconfig --passalgo=sha512 --update
    Now, all new passwords will be hashed with sha512. Users with weak passwords should now be asked to change their passwords.

    I hope this helps!
     
    Archmactrix and Infopro like this.
  13. net123

    net123 Member

    Joined:
    Oct 20, 2008
    Messages:
    9
    Likes Received:
    0
    Trophy Points:
    1
    Mike - Thx again. We did impose the stronger password requirements for just the scenario you described - once a client tries to update or change their current pw they will have to comply with the new restrictions. We also sent out a "Best Practices" newsletter - again - and so I'm hopeful that we are making progress.

    - - - Updated - - -


    Thanks a ton Alpha - great read. I wonder - is there any concern if we switch to sha512 that it could be over written by future cpanel upgrades?
     
  14. alphawolf50

    alphawolf50 Well-Known Member

    Joined:
    Apr 28, 2011
    Messages:
    186
    Likes Received:
    2
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
  15. bhd

    bhd Well-Known Member

    Joined:
    Sep 20, 2003
    Messages:
    149
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    JNB ZA
    cPanel Access Level:
    Root Administrator
    I got really tired of it too! so I wrote my own script:

    1. it checks* all cPanel password
    2. All mail passwords
    3. all FTP passwords
    4. (still need to add some other stuff when I figure out how :)

    * "Checks" means challenge against a password list. Presently it can do MD5 hash, SHA512 and old school "Crypt".

    For those who don't know, cPanel (Linux actually) "salts" all password these days so rainbow tables or anything like that won't work: one needs to take the salt and then attack the hash (using the salt) with a plain-text list of passwords; this is what we've done. It's slow and runs for hours (with a password list of say 10,000) and it uses 100% of one CPU core.....

    If you have a 4 core CPU with threading, it's perfectly safe to use. DO NOT attempt to run this perl script on a single or dual core machine that does not have threading!!

    I'll subscribe to this thread, and if anyone is interested, I'll give you the link to to the code. (Please note, I'll NOT give the code to a new member of cPanel forums with 3 posts as this code can be used for really bad things!).

    On our own servers, I have it in crontab on our servers and it runs starting on Saturday (and ends sometime Sunday) and sends an email summary of weak passwords it found. The first time I ran it (especially on old accounts with Crypt and MD5 hashes, I nearly passed out! Half of then were "password" or "blessing" or "Access" ... really scary!!).

    Every week, I upload a different plain-text password list, "just to see"; and every week, I'm shocked by what I find!

    It's a single perl file (so far) that you put into /etc/wpwd/wpwd + a file called passwords.DAT (which is a plain-text list of passwords)

    If there is interest, let me know :)
     
  16. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,811
    Likes Received:
    667
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    You can set a password age for cPanel, webmail, and WHM users. However, this will only force a user to change their password upon accessing those interfaces. It does not actually disable the login, so an email account would still function via an email client. There are currently no native options that will disable access until an email account user changes their password. You are welcome to submit a feature request for this at:

    Submit A Feature Request

    Thank you.
     
Loading...

Share This Page