Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


#1095 Better protection of saved passwords

Chris Russell

The fact that Mumble supports passwords is fantastic. It provides a means for users to log on from different clients without the need for exporting/importing their certificate file.

However, I noticed that the passwords are stored in clear text on the client. Coupled with the fact that the client always saves the password, this creates a situation where user passwords are readily available to anybody who has access to the client computer or data. Whereas access to a Mumble account does not expose any sensitive information, password re-use is a common occurrence.

Feature request:

A. Encrypted storage of passwords

B. A "save password" option which defaults to "no".


<< < 1 2 3 > >> (Page 2 of 3)
  • Stefan H.
    Stefan H.

    Unfortunately yeah. But I think with a proper warning and option to turn saving passwords off it of this should be acceptable. If there was a cross-platform password wallet we could use that. Ah well.

  • Jelan

    Hi, i recently opened a topic on this subject that related very closely to want is discussed here

    I wouldnt say it's impossible but I would break down this issue in 2 parts.

    1) Mumble client shouldnt store user password if the server has as specific flag for it.

    As I said in the topic, the server should be able to enforce this, which means either the users have to enter their password every time they want to login on mumble or the external Authenticator need to save user certs and use them once a given user has been authenticated the first time with his login/password. The later is exactly how mumur is working internally when no external authenticator is involved.

    So we would need a single server config option (boolean) that would be passed down to mumble among the other server params.

    Seems like a simple patch to do.

    2) Passwords should ideally not transit in clear over the wire

    There is always the choice to use something like SASL but it would be very cumbersome to implement... I believe a simple pragmatic and yet as effective solution would be to use another server config option which would tell the client (mumble) which hash function to use.

    The admin would have to choose between:

    • identity (no hash function, could be used for existing authenticator which rely of receiving the password in clear or if they are using an hash function which is not supported)
    • sha256
    • bcrypt
    • etc...

    The idea is that most sytems use a common hash function to store their user passwords, if mumble could be configured to use the same hash function, the external authenticator would only have to compare hashed passwords.

  • Stefan H.
    Stefan H.

    Hi. About 1): imho the server deciding how the client behaves isn't the right approach. If we give the user the option to not store his passwords the implications should be clear enough to make a decision. Unless we want to wander into cooperate-we-decide-what-you-may-do land there's no reason not to allow the user to store the password if he decides to (not saving it would be the sensible default imho).

    about 2): Mumble is always encrypted with TLS. The password is never clear-text on the wire. As such protecting the account in mumble doesn't benefit from additional hashing. You'd ofc still do it to protect the user credentials against malicious servers (ppl. still reuse pwd's a lot...) but as explained above that is not viable in Mumble. As the additional hashing would be to protect against malicious servers it can't be a server decision on whether to use it or not.

    I really think giving the user the decision is both a straight-forward and sensible solution.

  • Jelan

    Hi Stefan,

    1) I understand what you are saying but from an integration/developer/security point of view, why on earth would I let my users store the password of my system in clear on their computer when that password will never be used anymore at all ?

    -- First time connect --
    a) Prompt user for password
    b) Authenticator verify login/password
    c) Then the user cert is stored as a fingerprint of the user for next times

    -- Future connects --
    a) Compare the given cert with the stored cert for the given user to assess its identity, no password is needed anymore at this point. If my user change his password, cancel his account or do any other action that would mean he should be fully authenticated again, it'simple, we just delete his stored cert...

    In that scenario, the password is needed a single time only and can be discarded afterward, so the password is really transient and should be treated as such.

    This is exactly according to the wiki how murmur deals with password protected server. We should be able to replicate this model when we integrate with an external authentificator.

    My biggest grip with mumble storing the user password in clear is how easy and quick it is to view a password of a given protected server in the UI. I dont think the UI should expose the password at all to begin with, should be masked all the time.

    As for the "Let the users choose what to do, the server has no say in that matter" argument, it really depends...

    Look at how you usually login on a bank website, do you see a 'remember me' option anywhere ? No and it's not because they forgot to put one, it is because they choose not to for security reason, they decided (the server) that their users should authenticate themselves in full every single time.

    Is it a smart decision in their case ? Yes absolutely, makes total sense. Would you do the same for a simple phpbb forum ? Probably not.. It's always a tradeoff between convenience and security but it's always the service provider which chooses where they want to put the cursor between the 2. They don't let the users decide thinking they will make the right decision...

    We are trying to couple a pretty complex system with hundreds of thousands of users with mumble/murmur in order to provide a pretty slick integrated smart voice solution to our communities. So in our case, we are not a simple phpbb forum and we cant take the chance of compromising our system be letting clear passwords of our userbase running in the wild.

    2) I didn't know that mumble is using TLS already, so indeed, no need to worry about that... Thanks for the clarification Stefan.

    • Chris Russell
      Chris Russell

      @Jelan Forgive my verbosity in this reply, but you touch on some important points that deserve a complete response. :-)

      I don't know of any website that saves your password for you. A website may drop a cookie on your machine which contains some means of authentication. However, save for a site following very bad practices, this tends to be some sort of authentication token and thus useless to other services. The extent of the risk is somebody else accessing your account on that particular site. One could argue that gaining access to somebody's gmail (for example) would be catastrophic due to the likelyhood of sensitive data and ability for the attacker to perform password recoveries/resets on the victim's behalf. But then again, that's why it is an option and why I, personally, never use it.

      In your banking site example, they don't provide any means by which to stay logged in across sessions and with good reason. However, a closer analogue would be for Murmur to not allow the user to use saved certificates and always require their password.

      We could, however, draw a parallel between the Mumble client saving passwords and the Browser saving passwords. In this case, the banking website has no control over the client behavior. The Browser detects a (likely) username/password combination and offers to save it. Of course the user has the option to configure their browser to never save passwords.

      The approach that Stefan proposed (a checkbox with a detailed risk notification) is very similar in design to the browser/website example. The responsibility and control remains with the client and the user.

      At the end of the day, the server can't STOP the users from saving their password in clear text. (Anecdotal) A user who throws reads the proposed warning and decides to throw caution to the wind is just as likely to use the proverbial sticky note or a text file as they are to check off the little "save" box. One could argue that the absence of the checkbox may actually encourage the "sticky note" practice. ;)

      The point is, educating and discouraging your users from saving a password is a better solution than trying to modify behavior via a futile server setting. Chances are it would be simply be perceived by the security-ignorant as a feature oversight. (Moreover, it is likely to cause support questions since their friend who uses another Mumble server has the option!) The proposed solution of a warning message before saving, at least, has the benefit of educating the user.

      My site syncs users' site passwords with the mumble servers so if the Mumble username is compromised, so are the site passwords. I could mitigate this by requiring different passwords (which would be enforceable), but I have chosen more convenience since the site does not expose any sensitive data. If your users' mumble passwords have a risk of exposing sensitive data on your website then you may want to start looking at solutions other than using the same password for both systems. After all, that password is only as secure as your users. :-/

  • Jelan

    Stefan, any feedback on the above ? Would you accept a patch to implement 1) ?

  • Stefan H.
    Stefan H.

    Sorry for the delay. Missed your first reply. The first connect procedure is exactly what you can do with an authenticator today. You are handed a cert hash you can easily associate to the user inside of the authenticator. No password transmission required in the future (the authenticator would store the hash). This gives maximum flexibility in terms of expiration etc. too. No work on murmurs side required for that.

    I guess we would accept patches for the second part if they don't have to big of an impact. From our POV this is a use-case only a very small minority of hosters will care about. While we definitely like to see Mumble used for as many applications as possible we mustn't loose focus and overburden ourselves in terms of maintenance. If you want to

    If you want server signaling there would be a protocol change involved. Old clients wouldn't obey it. If you control deployment I guess another way would be to not make it a per server choice but add a configuration variable to deny it via a configuration variable (on windows that would be a registry key).

    The gist of it: We will implement making it optional for the user to store it. Everything beyond that (well we might be able to squeeze in the config "hack" without overworking ourselves ;) ) is out of scope for us but we will accept patches if they are low impact and the use-case is clear.

    I hope that helps.

  • Jelan

    Hi Chris,

    My banking example was to illustrate that sometimes the service provider choose for you by not letting you have the option to remember you. That's my only point of this example and it wasn't mean to be taken to the letter or to draw an analogy with mumur. What you are saying about the checkbox to let user choose is perfectly fine if we are talking about murmur server in standalone mode but as soon as you try to plugin another system in, it's not right anymore.

    Think about a web service that ask your FB/google credential to login, do they get your FB/Google login/password ? No, Do they store it, No... They all use oauth or openid to integrate the authentifaction worflow when dealing with third party in a way that dont and cant compromise the third party account.

    Obviously, in a client app, it's not really doable to implement oauth but that's ok, the client is open source and we can check that nothing funny is happening when credentials are inputed so I dont mind if my user credential go through mumble as far as it treats it as a transient value and dont store it anywhere.

    Of course, like I said before and like you said yourself, you can always revert to have mumble password in addition to your regular password for all your users so that mumble cant really compromise your system but that's not very friendly and I believe something trivial and simple can be done to make it a lot better and easier for everyone.

    Stefan, thanks for your feedback !

    Yes the first connect procedure, is exactly what we are doing, the issue is the client is still storing our user password and keep passing it to our callback even if we dont need it at all anymore.

    That's my whole issue. As soon as you implement this procedure, the user password is like a one time password, only needed the first time. Consequently, it shouldn't be stored by the client since it is not needed at all afterwards. It's not a matter of convenience vs security anymore, we dont even ask the user for his password after the first login...

    I believe we can easily fix this without reverting to a new auth callback or anything like that in 3 simple trivial steps:

    1) Add a new boolean config value "AllowSavingPassword" default to true
    2) Add this config value to the list of server params which are passed down the client when it connects
    3) In the savePassword function in the client add the following (pseudo code)

    if(!AllowSavingPassword) return;

    That's it !

    My only assumption is that some server config values are passed down to the client when it connects which I believe to be true.

    If the client can store user password, then I agree, it should ask the user if he wants to do it or not.

    I also believe, that the UI shouldnt reveal the existing password, but show only a masked value so it's not so easy to peak at the real password.

    Ideally the documentation should favor auth callback implementation to use the user cert or an hashed version of it in order to improve the security of their system, so they can turn the "AllowSavingPassword" off and instantly the whole thing is a lot more secure.

    Arguably it could even be turned off by default with a note for legacy auth callback to turn it on if they dont want to adapt their code. At least that would mean Mumble is pretty secure and sensitive about user credentials out of the box by getting rid of storing password in clear for good by default even in the case of third party authentication which is a great thing and I applaud mumble for pushing user cert in the first place !

    Last edit: Jelan 2013-05-12
  • Jelan

    Stefan, did you have a chance to look at the pull request ? Any comment ?

    And i found a profound phrase to summarize this issue: "The most secure way to store a password is to not store it at all" :)

<< < 1 2 3 > >> (Page 2 of 3)