How can I disable weakSecret()?

General Help
1

While it’s clearly not a show-stopper for me to change the 100 or so secrets it would be nice to waive the check while I migrate from 2.4 to 2.6. (migrate = build fresh system/config matching old config)

I’d presume that I can just “fix” admin/common/script.js.php to skip the check, my passwords are built from numeric, non-alpha, and alpha characters (both cap and lower case) but many have a single numeric.

I’d even settle for a change like:

— /var/www/html/admin/common/script.js.php 2009-09-10 22:58:15.000000000 -0500
+++ /tmp/script.js.php 2009-09-16 09:37:53.000000000 -0500
@@ -73,7 +73,7 @@
return true;
}

  • if (password.match(/[a-z].[a-z]/i) == null || password.match(/\d\D\d/) == null)
  • if (password.match(/[a-z].*[a-z]/i) == null || password.match(/\d\D?\d/) == null)
    {
    alert(’<?php echo _("The secret must contain at least two numbers and two letters."); ?>’);
    return true;

Is there a different/better way to attack this?

Thanks,

2

the best would be to file a bug if you feel it is acting un-reasonably. I had thought it was not suppose to force the issue for existing extensions, just warn (maybe that is your issue?)

But filing a bug will have it looked at and evaluated, especially if you think your secrets would be considered reasonable. I can’t recall what it requires, if it require more than one numeric, vs. at least one numeric and one non-numeric along with other constraints like min length, that would be a reasonable overt strict requirement we could evaluate changing.

3

I’m manually porting the configuration of the 2.4 into a 2.6rc system so all the extensions are “new” to this installation. The first secret (the third one I’m entering) is: 5$couples The current requires two numerals and two alpha, I think. I’d consider this a non-weak password while it may not be considered strong.

I’ll try to revisit with a cogent patch and description as a bug.

4

I’ve submitted a patch that keeps the spirit of weakSecret(), if not raising the ante a little.

Thank you for consideration of adding it to the 2.6 release.

peter

5

This password complexity is making configuration of some phones, especially when in device/user mode frustrating. I think that a complexity module should replace the forced implementation, allowing a user to select the elements required to consider “complex”, such as length, numeric, alpha, symbols, mixed case. This would allow configuring the complexity to meet the needs of almost all existing installations. Similar to the Roboform password generator.

Additionally, selecting what areas the complexity applies to would be nice. Whether this applies to trunks (which by default it should), extensions, voicemail, etc.

In our case, we’re using the Aastra scripts to configure devices quickly out in the field, and entering special symbols from the keypad is going to be almost impossible, as all of the characters are masked. I think aastra is working on the alphanumeric, but again, masking of the password on the phone is making this complex. Granted, this needs to be done once per device, typically, but in some larger scale deployments, it may be a pain.