With the wide availability of passkeys on all mainstream browsers, users and administrators can conveniently access the Vodia PBX while enjoying an unprecedented level of security.

Why Passkeys

Passwords were and still are widely used to authenticate users. The mechanism is simple, but passwords are still the number one security risk in most cloud systems. Users have to use password managers, many of them of unknown origin, or recycle the same password across multiple sites. Many users just point-blank give up and use trivial passwords wherever possible. Password scoring doesn’t really help; in many cases it doesn’t work properly with password managers. And periodic enforcement of password renewals make users outright angry. 

Because of this, passkeys have been recently introduced in practically all commercial browsers. In a nutshell, passkeys store a public key on the server side and a private key on the client side; even if the server gets hacked, the private keys for the login cannot be accessed. With the need to keep systems secure, this dramatically reduces the risk of running a server in the cloud, especially when there are many users. Passkeys are available today in practically every browser, and at Vodia we believe it’s time to start using them.

The New User Login

When a new user is set up, that user receives an email with a link to the PBX login. The link contains a token that will grant the user access to the system without a password. This works well for users with email accounts, which should make up the majority of users (almost all). The link can only be used once and expires after some time. Today’s email accounts are well protected, and this method provides an easy and convenient way for the user to access the system. 

When the user visits the login page of the PBX with the aforementioned link, the PBX will automatically log the user in before redirecting into the user portal. The PBX will generate a token, however, stored in the browser, that can be used for a few days after login, so if the user visits the PBX again the login will work without any user interaction. What the browser will also do is ask users if they want to generate a passkey for the login; users will hopefully recognize this way of storing login information and gladly accept the offer. In this case, the passkey is generated and can be used permanently.

‍

‍

There are several ways to generate passkeys. Depending on the platform selected, the user might use a fingerprint reader for identification, face recognition or a FIDO-compliant USB stick for those who want enhanced security. Once a passkey has been stored on the client, other connected clients can use the same passkey - it’s the job of the operating system to make sure client keys are stored and distributed in a secure way. The login to a telephony system is low profile compared to other applications, like banking or storing sensitive research data. This is useful, for example, when using the same login on the PC as well as on mobile phones; it also makes it easy to switch PCs, such as when a user gets a new laptop. 

Usually, the first time the stored passkey is required is after the expiry of the token. This is typically 30 days, but the administrator can change it. Because browsers require a user interaction with the page, the passkey cannot be used automatically, but when the user clicks into the username field, the browser will remember there was a passkey and will prompt the user to use it. If there is a fingerprint reader, all it takes is a finger on the reader to generate another token and redirect the user to the front end. If someone doesn’t want to use passkeys, and the token expires, a password reset email, which begins the initial account setup, can be requested. 

For those who still want to use passwords, they can ask the administrator to set a password for the account and provide it to them in a (hopefully) secure manner; users can then log in with their username and password. The username can be an extension number or, if they have added an email address to the extension, their email address.

Second Factor

What about a second factor? Historically, second factors have been used to enhance the quality of the password for the account. For example, employees who wouldn’t care much about the security of their logins would use the same passwords across all their accounts. The second factor helps significantly to ensure the user is the right person.

We originally added several second factors like emails with a PIN code, SMS with PIN codes or TOTP apps. Compared with what modern browsers and operating systems are doing to verify the identity of the user, these second factors are inferior to passkeys - they are also a hassle for users, even if today most users are used to it, so we didn’t include these second factors in the 69 build.

It does not mean that second factors are a thing of the past. Browsers and operating systems will continue to use them to identify the user, for example when someone logs in, a password is still required to enable face-ID or the fingerprint reader. All the PBX web front has to do is to sit on top of this and use a passkey as the final checkpoint to permit user log in.

Administrators

Now that we have an effective way of identifying users, why not use the same mechanism for administrators? The answer is…we do! Administrators can use the same passkey and email reset mechanisms as users. 

There are two more things administrators should keep in mind. The first is we can still limit the IP address range from which a specific administrator can log in; it’s old school but, in many cases, it works well and it’s easy to use. So why should we take that out? The second thing is API access must now be enabled manually in version 69 (with API access we mean basic authentication). There are many systems out there using mechanisms like OAuth, but OAuth still comes down to the master username and password. It makes more sense to create a separate administrator account for the API access from a script and use the IP address mechanism to make sure those requests are only honored when they originate from that IP address.

Administrators can check what tokens and what passkeys have been issued for their account — this can be done when the administrator changes his or her login information (username and the password). The PBX keeps track of when the token is created, last used (including the IP address) and when it expires. If necessary, the tokens can just be deleted. We didn’t include this in the user front end, as we think it’s overkill for most users and might create unnecessary support cases.

‍

Passwords

Unfortunately, not every device can use passkeys today. VoIP phones specifically will be unable to use this new technology for the foreseeable future. The Vodia PBX has generated random passwords for those devices for many years, invisible to the user, so the risk with these passwords is limited — they can be considered “mini-certificates” provisioned into the phones. They are stored encrypted in the file system and, though it’s not impossible, it would take a lot of work to decrypt them before they could be used. If someone gets file system access, however, realistically it will be very bad, and we urge you to take every precaution to keep your system secure. 

For the apps, the Vodia PBX has been generating random passwords practically from the beginning. We believe that even though app platforms today can support passkeys, this method is still safe. We continue using these random passwords in version 69.

If you install a new PBX, by default the user won’t be allowed to set passwords for SIP and the web. In those systems, when there is a need, it must be enabled by the system administrator — administrators can always set passwords in the admin section of the web interface. We assume administrators know what they are doing and will of course choose the safest possible passwords.

‍

Admin Password Reset

In previous versions administrators had to edit the pbx.xml file to reset the password. This wasn't only inconvenient, it could cause major problems if the XML file was corrupted (because of the edit). Version 69 provides two new possibilities to reset the admin password to address this issue. 

The first is to use new start up parameters for the PBX. You can use the --admin-username and --admin-password startup parameters to provide a one time password for the administrator login. Once the administrator has logged in, a passkey or a password can be set for the account. This way, it is actually possible to have a super admin account without a password. The second possibility is to use email recovery the same way users reset their passwords. This method works only if the administrator has provided an email address and email was set up.

We have also begun using this password reset mechanism for the initial setup of the PBX. For example, when creating a virtul machine, a known, shared secret like the instance ID can be used as a one-time password for administrator log in, then the administrator can either create a password or just use a passkey.

Conclusion

Passkeys are a great way to provide a better user login experience, and they significantly enhance the security of the PBX. All browsers and operating systems are ready. It is time to start using them!

We’re interested to know what you think. Please reach out to our VP of Communications, David Porter, dp@vodia.com, if you have any comments or questions. And thanks for your support!