Editorial

Passwords Passwords Passwords

Published on:

April 26, 2013

Passwords remain a crucial vulnerability despite the best security measures. Even with technologies like TLS, SRTP, and certificates securing phone calls, weak passwords still expose systems to attacks. Hackers use automated scanners to find open SIP ports and exploit weak passwords. To address this, snom ONE 5.0.9 now highlights accounts with weak passwords and shows what's vulnerable. While the system can generate secure passwords, administrators must avoid “No Security” settings to prevent exposure. Implementing strong password policies is a key defense against unauthorized access and potential system misuse.

For those who have a flashback when they see the title: you are right. This is not the first time I'm writing about passwords.

But passwords remain a major problem. We add fancy things like TLS, certificates, SRTP, and all kinds of things to make phone calls as secure as possible, then users use passwords like “password”. Passwords remain the Achilles' heel of securing the system.

As long as you run the PBX in a trusted environment, trivial passwords are convenient and usually nothing happens. But once you expose the system to the public internet, things can change. There are scanners out there that act like sharks smelling blood. Once they find an open SIP port, they try out accounts - once they find one, they try out passwords - everything automated and password lists like “password”, “secure”, “verysecure” and so on. Once they're able to get access, they reprogram their least cost routers and route the traffic through your system. Innocent people making calls to some expensive destinations might be using your system.

In 5.0.9 we added a feature, and then improved it, that shows which accounts have weak passwords. We don’t only show which account may be exposed, but we also show what's vulnerable. This all depends on the password policy of the system. Again, if you decide to set that to “accept anything”, there isn't much the system can do.

We also have other features that make extensions secure - for example, a dropdown in the accounts view that generates long passwords and PINs that are difficult to guess. Also, when the system starts up, it generates initial passwords that are also quite random. Entering new passwords is governed by the global system setting of the password policy. This is set to “medium”. Administrators changing this to “No Security” must know they are potentially exposing the system to scanners, just for the convenience of entering simple passwords.

Large IT companies like Google are in discussions about introducing new authentication methods (such as two-factor authentication). If you think about how many email accounts a company has and how much work it will be to change the authentication for all of them, you'll understand how serious the problem is and how serious these companies take the problem. Passwords and PINs are something the PBX user knows; when it comes to something the user has, however, things get trickier in PBX environments. Many users have a VoIP phone with a certificate, and we are already using the certificate built into the phone to authenticate the device. So when a user is using a phone provisioned using a manufacturer certificate in the phone, and the user has to enter a PIN when making an international call, then we have a two-factor authentication. This can already be the reality today with snom ONE. It doesn't solve the problem, however, of customers using soft phones or phones that don’t have a certificate built-in. Also, realistically, entering a PIN for every outbound call would make a user's life harder than it has to be.

We will have to see in the future if we, for example, allow international calls only from devices with a built-in certificate. Or at least something like international calls can be made only from phones automatically provisioned and with a security token loaded into the device.

The bottom line for me is administrators should keep their password policy at “medium”. Strong passwords are a huge step in the right direction.

Latest Articles

View All

​Services Changes

Following a critical PHP security advisory affecting installations worldwide, we temporarily restricted public access to some of our backend services while carrying out necessary upgrades. Access has now been restored, and the affected services are operating normally. The Vodia PBX itself does not use PHP and was not directly affected. We explain what happened, the changes to legacy licensing and TLS support, and why customers running older PBX versions should contact us for upgrade guidance.

October 22, 2026

How to submit a support ticket in the Vodia Help Center

Submitting a support ticket with the right information helps our team understand your issue and reduces follow-up questions. This step-by-step guide walks you through the Vodia Help Center, from describing the problem and attaching diagnostic files to setting the business impact and providing your PBX details. You’ll also learn which call details and timestamps to include, alongside practical tips to keep troubleshooting focused and help our support team investigate your issue more efficiently.

October 21, 2026

Make the Switch: The Vodia PBX Migration Tool

Switching phone systems doesn’t have to mean rebuilding everything from scratch. The Vodia PBX migration tool imports key configuration data from backups, including extensions, ring groups, queues, desk phones, and basic auto-attendant settings. Built into the Vodia Admin Portal, it guides administrators through the import process and reduces repetitive manual work, whether you’re moving 10 extensions or 1,000. Explore what transfers, what needs manual setup, and how the built-in tool reduces repetitive work when moving to Vodia.

October 15, 2026