New “feature” of autopopulating ‘secret’ field under Device Options is undesireable. Setting of requirement of strong secrets to ‘false’ in Advanced Settings as well as uninstalling Weak Password Detection module does not seem to prevent this field from being populated. Is there any way to disable this?
What is the problem with it being generated? On new extension creation you’d have to go into that box and type the password anyways? Or am I missing something?
of what this field applies to would get us to a resolution more quickly? Do devices require this parameter to register their extensions with the server?
We have never used this field previously (always left blank). If we are now going to be forced to use it, we should have the option to set the parameter globally.
The secret is what’s used to register your phone. You having it blank is an exreme security hazard. If you always left that field blank then I wonder two things:
1.) How have you never been hacked.
2.) How did you get past the multiple alert boxes to set a valid password
Wow if you never set a SIP Secret then I am amazed. All SIP and IAX extensions should have a SIP secret otherwise anyone with any phone could connect and register. That is just crazy
When combined with an endpoint manager, there is no additional hardship by using the longer passwords and it adds an additional barrier to enhance the security of your PBX. But if you are so inclined we give you the Freedom to remove this requirement, you can go into the Advanced Settings Menu of your PBX and Toggle the Require Strong Secrets option to “False” and then save to remove the “Strong Secrets” data validation when creating extensions. As noted Weak or non-existent passwords represent a huge security risk.
You will still need to blank out the password that was generated, but that’s the price you pay for wanting to be less secure.
and we have tried deleting the contents of the secret field in the device options of the extension. However, upon submitting and applying changes, the field is automatically populated again.
switch vlans, and our gateway in order to get through our firewalls.
In most businesses it’s usually those that have the keys that you have to worry about.
Yep, that does appear to be what is happening… submit a bug here : http://www.freepbx.org/trac/newticket
Not sure I agree with not allowing a SIP secret. This is just bad business.
Yes, I am sure it’s great for you that your VoIP VLAN has no Layer 3 connectivity outside the local LAN I am grateful that SIP includes a AAA mechanism for the majority of users that require authentication and I am glad FreePBX supports it.
I can’t believe that this is a burdensome requirement for you.
Looking at it again, I’m not really sure if this should be filed under a bug, but will leave that for others to decide, if you submit a ticket, as there is no password being saved, the form just populates a password when you go back in to edit because it’s empty, and that is the desired process for just about anyone with a PBX.
It’s taken about 5 years to finally get the SIP registration fiasco under control. Sorry but removing an important layer of security for one and perhaps as many as a handful of potential users while greatly increasing the potential for compromised accounts for hundreds of thousands of users just makes no sense at all.
I think virtually everybody missed the point of the OP’s complaint, probably because of the poor description. If a user wants/needs to create an extension with no secret, they can do so by deleting the field contents and ignoring the warning. If the user then later tries to edit the extension, FreePBX will again automatically populate the secret field, completely silently without notice. This is the problem, the user must delete the secret EACH AND EVERY TIME the extension is edited, which must be a curse for those who need/want this feature.
I don’t think this issue has anything to do with security, it has to do with FreePBX helpfully but incorrectly assuming that every user requires a strong secret. There are a few courses of action, one is do nothing, one is only auto-pop the field at creating, not when editing. My suggestion would be to add a button that the user can use to auto-pop the field whenever they want, and otherwise leave it blank. I am sure there are other options that haven’t occurred to me.
lgaetz, yep I saw what the OP was trying to convey last night, and I concur it would be a pain to have to wipe that field every time you edit if you chose to fly without a password, but may be something he has to live with if that feature is not added, I don’t know how much work it would be to add this functionlaity, but it probably will not be too high on the list since there only seems to be one person that wants this ability. I also don’t know if a button on the extension page would make sense as I hate to clutter that up, or a setting in the “advanced settings” module if that would be possible. We already have the option to disable strong secrets, so what he is wanting to do, in my opinion shouldn’t be submitted in a bug ticket as the password generation is working as it should, but more of a feature request. But like most it would be a feature I would never consider using. For now the apparent work around is to just continue to blank out that field before submitting changes.
When setting “Require Strong Secrets” to False for Device Setting under Advanced Settings, it should not require anything in the secret field under Device Options for Extension (especially when the Weak Password Detection module has been uninstalled). Clearing contents of secret is not possible, as field is repopulated upon “submitting” new changes. Behavior for this field in version 2.10 is preferred. All of a sudden mandating this on a free product when it wasn’t required before is not rational. I haven’t even seen discussion in any of the forums screaming for this mandate. Lack of understanding of why this mandate might not be desireable, should not be justification for enforcing it.
As stated you can open a feature request for the change that you want but I strongly disagree that users should be able to setup a extension with no secret.
Also require strong passwords has nothing to do with requiring a password so that setting wont change anything.
…for migrating extensions from systems that did not previously require this (yes, you could save an extension without this field being populated), means that we will now have to logon to 300+ device GUI’s to enter an “authentication password” for the phones to register. Furthermore, not being allowed to set this parameter globally, means we now have to edit each of those extensions within the FreePBX gui to set a “realistic” password our field techs can enter when they are logging on to the device GUI’s for the upgrade and future installs.
Just seems this “feature” wasn’t thought all the way through before implementation.
was submitted on 4/19/13