Add More Logic to Password Compliance
Idea shared by Shaun Peet - September 3, 2014 at 6:26 AM
Proposed
The current password policy compliance mechanism isn't really all that 'smart' about how strong a password actually is, and it makes it difficult for system administrators to monitor / correct those who are not in compliance.
 
For example, if we would like people to have really strong passwords then the only thing we can do right now is set a decent length to the password (anything longer than 8 characters would really annoy people), and check off everything available (require uppercase, lowercase, number, and symbol).
 
But that means a password like "Pa55word!" qualifies as being strong, but something like "At lunch I like to eat 5 donuts" doesn't.
 
So is there any way to build in some logic to the password requirements that gives some sort of "weight" to each of those parameters, and then coming up with a total score for the password?  Then as a system administrator, we just need to set the minimum threshold score.  This is similar to how SPAM weights are assigned.  For example:
 
Each character of the password = 2 points
If the character is an uppercase letter = 3 points
If the character is a number = 4 points
If the character is a symbol = 6 points
At least one uppercase and lowercase letter = 5 points
At least one letter and number = 5 points
At least one letter and symbol = 5 points
 
In that case
 
"Pa55word!" = 42 points
"At lunch I like to eat 5 donuts" = 93 points
 
So we'd just set the minimum threshold around 40 points.   I don't think it would be possible to create a weak password with a minimum of 40 points using the parameters above - even if it were all lowercase letters it would be 20 characters long.
 
Thoughts?
 
 
 

12 Replies

Reply to Thread
0
Wow that would really be hard for clients to figure out.

This is kinda pointless as most password are grabbed via keyloggers or spyware on the clients pc.
0
The current recommendation from U S CERT is 16 characters. We endorce 12, and require uppercase, lowercase, numbers, and special characters. See the notification we push by selecting "forgot password" at https://securemail.chicagonettech.com.
 
Bruce Barnes
Bruce Barnes
ChicagoNetTech Inc
brucecnt@comcast.net

Phonr: (773) 491-9019
Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
While I appreciate the reply, this thread isn't really about what recommendations are currently out there. This is a feature proposal to change the underlying mechanism of what SmarterMail considers to be "strong" vs "weak" by applying weighted metrics to each of the parameters of a password.

I also wouldn't presume to know anything about anybody else's user base - I know my own. They're 95% volunteers and very light users of the email system - while I'd love to enforce 12+ characters on a password it's not going to be met with any degree of popularity. Perhaps we'll get there someday, but not today :)
0
It's not really something that a client would have to "figure out". When they type their desired password - it would either pass or fail to meet the requirements set. If it failed, then all it takes to offer a tip for them to make it longer, include numbers and symbols, etc.

And while "most" passwords might be compromised via malware / spyware does that automatically mean that any suggestions to improve the current system are pointless? Most people speed - does that mean speed limits are pointless?
0
Ask the Germans that last part.
2
Given the number of recent network and storage hacks, IE:  Home Depot, Target, Apple's iCloud, the time is now, not in the future.
 
Remember, as an MX server operator, you are 100% responsible for everything that goes through that server.  If it's hacked, the liability falls on you - and that's a pretty darned good reason to make an MX, or any other server, as secure as possible.
 
The addition of two-factor authentication to SmarterTools products would be a nice touch, too.
 
Bruce Barnes
Bruce Barnes
ChicagoNetTech Inc
brucecnt@comcast.net

Phonr: (773) 491-9019
Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
You go ahead. I'm going to get back to the topic of SmarterMail Password Compliance.
0
I can appreciate your opinion that all mail server operators are 100% responsible for everything that goes through the server. We respectfully disagree.

In any case, this is not supposed to be a debate about the philosophy of passwords. It's (what I thought was) a simple suggestion to perhaps re-work some of the inner mechanics used for password compliance.
0
You propose adding extreme complication to an area were there is no real need. There are many other things in Smartermail that should get attention that are a lot more important than this.

All I see it as is a waste of development.
0
To stop the damage from compromised accounts you can also setup Declude and use the hijack plugin. This will stop mass emails from leaving your server after a password is hacked.
1
Now that SmarterMail 13 is out I wanted to bump up this topic.  It seems one of the target audiences for the new features is the semi-pro mail administrators like me.  Not people like Bruce who have probably forgotten more about mail servers and email delivery than I will ever know.  We provide a service to our customers - we charge almost nothing for it so we can't invest tons of time into it - and SmarterMail 13 helps us to do this without breaking the whole internet.  So I apologize to people like Bruce for not being as hard-core about mail server administration but this is the reality we live in.
 
So with all that said, we're still hoping to have the definition of a "strong" vs "weak" password in SmarterMail slightly redefined.  Keeping in mind that most of the end-users (the general layperson, not mail system administrators) do not understand / are not motivated / etc to ensure that their own passwords are crucially important, let's help them out a bit by allowing for pass phrases in addition to the current options for numbers, uppercase / lowercase, symbols, etc.  The only way to do that is by assigning a password weight based on various factors as mentioned above.
 
My original example holds true.  Currently in SmarterMail 13 with all those password strength options checked, this is legit:
 
Pa55word!
 
And this is not:
 
At lunch I like to eat 5 donuts
 
SmarterMail 13 is great that we now have a mechanism to help get stronger passwords out there - now all we need to do is define "strong" in a way that is actually strong and will actually be accepted by the general end-users.  A really long pass phrase with no numbers in it is still a pretty good password.
 
1
This idea was originally presented back when SM12 was out, and I'm still hoping we can get some consideration for it.  To review, the idea here is to add logic in the determination of what a strong password is.
 
There have been a number of heated debates about showing passwords in plain text - both in version 15 and a new one that's started in version 16.  Part of the reason those threads exist is because:
 
1) People tend to forget their password,
2) Increasing complexity requirements for passwords they're even more likely to forget it, and
3) In a multi-device world it's much easier to recover the existing password than to change it
 
I believe strongly that if people were able to use pass phrases that we'd see a reduction in people forgetting their passwords.  A pass phrase would be much longer in terms of character limit but may not adhere to other requirements such as capitalization, numbers, special characters, etc.
 
I'm not alone in this thinking.  There is a great discussion of this on StackExchange here:
 
And in that thread there's a great quote:
 
Security at the expense of usability comes at the expense of security.

Reply to Thread