Summary:	ASTERISK-13598: [patch] Enforce password strengths
Reporter:	Tilghman Lesher (tilghman)	Labels:
Date Opened:	2009-02-17 16:54:30.000-0600	Date Closed:	2009-10-21 18:43:00
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 20090217__min_pwd_strength__2.diff.txt
Description:	[11:23:31] <Shaun2222> jsmith: the problem is that these newbies are going to also set weak passwords [11:24:15] <Shaun2222> that option these days should be "yes" by default. [11:24:35] <jsmith> Shaun2222: We can't protect people from themselves... at some point, they should be responsible for their own choices. [11:24:36] <Shaun2222> security is far more important than some newbie trying to figure out what he did wrong. [11:25:09] <jsmith> Shaun2222: That's not to say security isn't important... I'm just saying there's only so much we can do to prevent them from being insecure in their choices. [11:25:39] <Corydon76-dig> You mean like ALL NUMERIC PASSWORDS? [11:26:17] <Corydon76-dig> All numeric usernames aren't much better. [11:26:29] <Shaun2222> jsmith: somthing like that needs to be on by default.   if a newbie cant figure out whats wrong with there sip phone then he can enable that option. [11:27:04]  Corydon76-dig thinks we should have an option called "enablenumericpasswords" and the default should be "no" [11:27:20] <Shaun2222> so.. how can we get this option enabled by default.. do i need to submit a bug or somthing? [11:27:42] <Corydon76-dig> Shaun2222: honestly, it would only be changed in unreleased branches [11:28:02] <Corydon76-dig> Changing defaults in the middle of a release cycle is bad, mmmkay? [11:28:18] <Corydon76-dig> so maybe 1.6.1 [11:28:20] <Shaun2222> Corydon76-dig: might as well make the change now for the new installs.... [11:28:39] <Shaun2222> next release would have the change, as people upgrade, it will be enabled. [11:28:50] <Shaun2222> if they are already authing ok, it shouldnt affect them [11:29:09] <jsmith> Shaun2222: When people upgrade, they often don't start from a new config file... they typically just copy over their old config [11:29:34] <Shaun2222> jsmith: exactly why that should default to "yes" so the option is enabled automatically. [11:29:39] <jsmith> Corydon76-dig: I do like the idea of the enablenumericpasswords setting. [11:30:10] <jsmith> Corydon76-dig: Or even better, make it "enableweakpasswords" and do some more sanity checking than just "is it numeric and less than X digits long" [11:31:05] <Corydon76-dig> jsmith: at least one capital letter, one lowercase letter, a number, and a symbol... and no less than 8 characters long [11:31:22] <jsmith> WORKSFORME
Comments:	By: mbrevda (lazytt) 2009-02-18 02:47:54.000-0600 Just a though: it might be more flexible to have the password checked agents a regex (vs. hardcoding the definition of secure) - this way every system admin can decide for himself what is considered a 'strong' password By: Tilghman Lesher (tilghman) 2009-02-18 10:45:20.000-0600 lazytt:  if you would like to code such a proposal, you're welcome to.  I considered something like that, which is why the value specifying a password strength is selectable at runtime. By: mbrevda (lazytt) 2009-02-18 11:50:17.000-0600 <@jsmith> hi365: Regexs aren't ideal... just write out the rules you think we should use in plain english in comments on that bug, and we'll figure out the best way to code them hmm: 1. Min-max amount of characters (totals) 2. min amount of digits 3. min amount of alphanumeric [a-zA-Z] 4. min amount of special characters (depending on asterisk level of support for them i.e. !@#$%^&*()_+=-) By: David Brillert (aragon) 2009-02-18 13:34:58.000-0600 What are the supported special characters in Asterisk ? I'm using ! on a Polycom phone and getting all kinds of SUBSCRIPTION errors... By: Olle Johansson (oej) 2009-02-18 14:04:52.000-0600 minimumsecretstrength - it is not a password By: David Brillert (aragon) 2009-02-18 14:26:54.000-0600 oej If I am going to use a minimum complexity of passwords it would be nice to know which special characters are allowed in the password? I have found a few phones that don't like special characters. I fixed my Polycom problem but for example Hitachi WIP5000 does not like some special characters in SIP password. By: Olle Johansson (oej) 2009-02-19 05:18:24.000-0600 That's a good question, aragon. It goes all the way back to the HTTP MD5 digest RFC 2617. And possibly the MD5 algorithm by itself. http://en.wikipedia.org/wiki/MD5 As MD5 is used to create checksums on any file, I guess it's all right with just about anything. RFC 3261 section 22 outlines the usage of HTTP auth within SIP I can't find any specification of the actual secret used... Sorry. I've seen SIP phones who can only have digits in the password, as well as phones that choke on more than four characters. By: Olle Johansson (oej) 2009-02-19 05:18:52.000-0600 I would suggest that we run the algorithm on the secrets as we load accounts in build_peer - either realtime or static accounts. By: David Brillert (aragon) 2009-02-19 08:47:51.000-0600 Just my two cents here but I don't think you can enforce minimumsecretstrength=yes by default if there is some chance that the phones wont play nice with the password requirements. Also you need to make allowances for the password policy so that those nasty phones can still connect to Asterisk. I could predict that an upgrade or an attempt to enable password policy will take a lot of phones out of service. Everything needs to be optional to avoid the pending screams. And of course all the phones will probably need a reboot once the password policy is enforced and this needs to be scheduled during a maintenance window. By: Olle Johansson (oej) 2009-02-19 08:49:42.000-0600 Of course it needs to be optional. But the ability to add a good algorithm like this for channels and manager is a good thing. Especially manager! By: Jared Smith (jsmith) 2009-02-19 09:03:00.000-0600 To answer aragon's concern... what if instead of rejecting calls when the password isn't of sufficient strength, we redirect the call to a different context.  Just as an idea, you could do something like this: sip.conf -- minimumsecretstrength=5 weaksecretcontext=rejected extensions.conf -- [rejected] exten => _X.,1,Playback(your-password-is-weak,noanswer) exten => _X.,n,Goto(regular-context,${EXTEN},1) This gives the end use much more control about how to handle weak passwords, without completely blocking them. Thoughts? Concerns? By: David Brillert (aragon) 2009-02-19 09:10:38.000-0600 Redirection still means a loss of service to potentially many customers. I know you want to protect end users from fraud but in that process you don't want yourself to become liable for lost business because of a change in code. If a system administrator wants to adopt such a redirect policy then that is the customer's prerogative. IMHO everything has to be optional. By: Olle Johansson (oej) 2009-02-19 09:27:28.000-0600 If we have a strong policy, we should not load them from our database or from the config file and thus we won't ever authenticate them. Doing it per call is not a working solution, I think. It's when we build an object in memory we can enable or disable it. When we get a call, it's too late. The other issue is the realm-based auth that will need to be checked as well. We should propably add a manager message (optional) for this too, so that a manager of a large system has a chance of doing something about it. And of course, a ERROR-level log message. By: Tilghman Lesher (tilghman) 2009-02-19 10:32:10.000-0600 aragon:  The concerns you're raising are not at all on a code-level.  Rather, they are administration concerns, when turning on this protection and should be handled at that level, by a competent administrator.  While the implementation does turn this on by default and requires a strong password, the administrator will be able to turn this off completely.  And a note will be added to the UPGRADE.txt file, such that any competent administrator will notice well in advance. By: David Brillert (aragon) 2009-02-19 11:13:58.000-0600 I strongly disagree with turning it on by default. I know what you are trying to do and I agree with the principal but time will tell us that is not a good idea. A competent administrator can also enable the setting... Just my two cents, I don't plan on upgrading to trunk any time soon anyway... And I've been implementing a strong password policy on all of my sites for some time now and I speak from experience. It is overwhelming managing multiple sites if you cannot control when the policy is effected or if you are unaware the upgrade will effect the policy (for any reason, competence, illiteracy, etc...) I'll use an example: Cars needs oil changes to prevent expensive damages so the manufacturer builds a feature into each car's computer that will not allow the car to start after 5000 km because it needs an oil change. I prefer the idea of taking my car to the shop when the change oil light comes on... I wouldn't want to be the guy who re-programmed the computer :S But hey, he was just looking after my best interests... I really like oej's idea about the ERROR-level log messages. This should be enabled by default.  This is so non-invasive you could even put it into 1.4 and at least people would get used to the idea of secure password enforcement and the risks of non-compliance.  IMHO this is just like the "change engine oil' light. By: Olle Johansson (oej) 2009-02-19 11:29:33.000-0600 Nothing here will go into 1.4, so that's not an issue. By: Leif Madsen (lmadsen) 2009-07-29 12:48:44 I just tested this, although I don't think it is working as it should be. From looking at the patch, a password like: 101 Should return a score of: length: 1 upper: 0 lower: 0 punctuation: 0 digit: 1 This should return a score of 2. The default is 4, and I've uncommented the sip.conf option "minimumpasswordstrength=yes" However, the peer I have: [00085D193AB5] type=friend context=start host=dynamic password=101 Is able to register fine. Not sure why that is, but it doesn't look like this is working. By: Tilghman Lesher (tilghman) 2009-08-07 14:35:48 At this point, I have lost interest in this patch.  If anybody wants to update it, please feel free to ask a bug marshal on #asterisk-bugs to reopen it.  Closing. By: Michiel van Baak (mvanbaak) 2009-08-10 05:12:07 I'm willing to take this one. I'll have some time this week. By: Michiel van Baak (mvanbaak) 2009-08-10 10:51:56 Seems like the general view is: it's up to the admin to generate/come up with good passwords. My motivation is gone as well now ;)