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 which part is 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 am writing about passwords.

But passwords remain to be a major problem. We add such fancy things like TLS, certificates, SRTP and all kinds of things to make phone calls as secure as possible and then users are using 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 that you start to expose the system to the public internet, things can change. There are scanners out there that act like sharks smelling blood. Once they found an open SIP port, they start trying out accounts and once they find one, they try out passwords. Everything automated, and including passwords lists like “password”, “secure”, “verysecure” and so on. Then once they were 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 back and improved it that shows which accounts have weak passwords. We don’t only show which account may be exposed, but we also show which part is weak. This all depends on the password policy of the system. Again, if you decide to put that to “accept anything” there is not 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 PIN 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 that they are potentially exposing the system to scanners, just for the convenience of entering simple passwords.

Large IT companies like Google are discussion about introducing new authentication methods such as two-factor authentication. If you think how many email accounts has and how much work it will be to change the authentication for them, you will understand how serious the problem is and how serious those companies take the problem. Passwords and PIN are something that the PBX user knows; however when it comes to something that the user has things get trickier in the 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 with that. So when a user is using a phone that was 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 be the reality today with snom ONE already. However it does not solve the problem of customers using soft phones or phones that don’t have a certificate built-in. Also, realistically, entering a PIN for every outbound call is making users 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 that have a certificate built-in. Or at least something like international calls can be made only from phones that were automatically provisioned and a security token was loaded into the device.

For today, the bottom line for me is that administrators should keep their password policy at “medium”. Having good password would be already huge step in the right direction.

Derniers articles

Voir tous

Integrating OpenAI's Realtime API with Vodia PBX: Webinar Recording Now Available

In our recent webinar, "Integrate OpenAI’s Realtime API with Vodia PBX," we explored how integrating AI with your communication systems can revolutionize the way your business operates. From automating repetitive tasks to improving workflow efficiency, the webinar covered how the collaboration between Vodia PBX and OpenAI’s Realtime API can streamline operations, enhance collaboration - especially for Microsoft Teams users - and provide intelligent automation to stay ahead in a competitive landscape. If you missed the live session or want to revisit the insights, the recording is now available for you to access.

December 18, 2024

Unlock the Power of OpenAI’s Realtime API with Vodia PBX: Join Our Exclusive Webinar!

Join our exclusive webinar to explore how Vodia PBX seamlessly integrates with OpenAI’s Realtime API, unlocking powerful new capabilities for your communication systems. This session will showcase how AI-driven features can streamline workflows, improve operational efficiency and elevate the PBX experience for both general users and those on Microsoft Teams. Whether you’re looking to stay ahead of the competition or leverage the latest AI trends, this webinar offers practical knowledge and actionable strategies. Register now to secure your spot and take the first step toward transforming your telecom infrastructure with AI innovation!

December 4, 2024

Connecting to OpenAI Realtime API

This document details the beta version of the Vodia PBX that connects to the OpenAI realtime API, enabling users to interact with a chatbot via telephone. The backend JavaScript code facilitates the connection, handling audio input and output, and the WebSocket connection to the OpenAI API. The setup requires a Vodia PBX version 69.5.3 or higher, an API key, and a license with an IVR node. The demo can be accessed by editing the ivrnode.js template and creating an IVR node in the tenant. The system supports various VoIP devices and offers good voice quality. Future improvements include voice activity detection and the ability to take actions based on OpenAI responses.

November 26, 2024