This is a read-only archive of the Mumble forums.

This website archives and makes accessible historical state. It receives no updates or corrections. It is provided only to keep the information accessible as-is, under their old address.

For up-to-date information please refer to the Mumble website and its linked documentation and other resources. For support please refer to one of our other community/support channels.

Jump to content

Security issue with external auth


Recommended Posts


I am using Ice to interface with mumur and all is working just fine.

I am using a ServerAuthenticator callback in order to authenticate users against on own user system and it works just fine.

Now comes the "issue" i have, the password is stored in the mumble client in clear... Which I don't like at all.

I don't understand why this is needed at all. Shouldn't murmur once the auth complete successfully, register the user with his certificate ? Then, if the user try to login again, if the cert matches, the user should be logged in automatically without any need of password whatsoever.

According to the wiki regarding authentication methods , this is how it should work:


Password Set, Certificate in Client

If your client has a certificate in it, and you log into an account that has a password on it for the first time, then you will be prompted for a password. Once the correct password is entered, the certificate is attached to that account on the server - any user connecting from that same client certificate will not need a password from that point on.


So why Mumble is storing the password and why every time an already registered user try to login, murmur invokes the auth callback ?

Thanks in advance for your help, hopefully I am just doing something wrong here.

using last snapshot of mumble/murmur 1.2.4 (1.2.4-rc1-12-gdab8157)



Link to comment
Share on other sites

  • Administrators

When you register an authenticator it takes priority over the Mumble servers authentication mechanism.

After all, when you use an authenticator for example against a forum database, when you delete a user on the forum he should not be able to log into Mumble with that account any more.

Hence the authenticator is still the primary source for authentication, even if some user account data is saved in the Mumble servers database.

In said database, the users password nor the certificate is stored at all, because after all the authenticator is the one with the user data and executing the authentication.

And as the authenticator still requires the password for you, the Mumble client will always have to provide the account login data (for the authenticator), hence saves the password.

Link to comment
Share on other sites

Hi Kisaki,

Thanks for the reply. I understand your point of view and for sure the current way of how Authenticator works make it simple but at the same time who wants to keep their password in clear on their computer... Mumble goes a long way with their cert logic to make it simpler and safer for users and admin which is great but at the same time, as soon as you want to plugin your own auth, it seems to do 2 step back...

I have no issue of un registering myself any given user that would delete his account on our system, therefore avoiding him to be able to log back in into the mumble server. This method force you to keep things in sync but at the same time, it could treat the login/password challenge as a one time challenge to register the user with the mumble server so the client does not have to keep the password anymore.

Even if it means more work to keep everything in sync, I would choose this method over the current simpler one any day for the obvious added security benefits.

Is there any chance to maybe have another auth callback that would allow this kind of behaviour ?

Link to comment
Share on other sites

  • Administrators


we plan to offer the user the option to not save passwords in the client in the future ( . We should have done so earlier but we were more focused on the certificate side of things.

In such a case the authenticator could simply save the certificate hash itself. First connect would hit the authenticator with the password and a cert hash. If validation succeeds the authenticator can save the cert hash for the given user. Successive attempts then won't need to transmit the password. As Kissaki said: We have to leave it up to the authenticator what to do.



Link to comment
Share on other sites

Hi ddot, thanks for joining this topic !

I am perfectly fine with storing the user cert so once a user has authenticated with his login/pass the first time, i can store his cert and use this afterward. So basically how mumur is doing it internally ;)

In my opinion, it shouldn't be the user responsibility to decide to store his password or not, the authenticator should be able to dictate or more specifically to mandate the security it wants for its userbase given that it's very likely a lot of people will choose to store the password without really understanding the implication.

Right now that means that I will generate a separate mumble pin code that I will associate with the user cert to further secure it. So if someone steal the pincode, they cant use it to login on mumble without the cert as well and they cant use the pincode to log on our system either. But I will have to educate our userbase about this additional mumble pincode which is not as ideal as if they were using their own password...

Is there any chance we can add just a server config option that would tell the mumble client if he is allowed to store the user password ? I believe that simple thing would allow us to do exactly what we need and it seems to be a very tinny patch to do that wouldn't warrant to worry too much over breaking anything...

Link to comment
Share on other sites

  • 2 weeks later...

  • Create New...