Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1095 Better protection of saved passwords

Unassigned
open
nobody
None
5
2014-08-14
2013-04-11
Chris Russell
No

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".

Discussion

1 2 > >> (Page 1 of 2)
  • Stefan H.
    Stefan H.
    2013-04-11

    Normal encryption wouldn't be very useful client-side as we have to decrypt it to use it. Password obfuscation in OSS software would be kinda funny ;)

    I guess we could store the passwords hashed and auth with that. That would only work with servers prepared for it (atm. they aren't) so we could only drop the plaintext password after connecting and verifying the server version yuk. Also we can't salt locally...we could get a bit creative in how we hash to defeat existing rainbow tables / brute forcers out there. This would - imho - be enough protection. It won't protect your mumble credentials but the password itself isn't easily reversed.

    Not saving the password in the first place would be a much easier client side solution ;) We should offer that anyways I guess.

    TL;DR:
    A: Not that easy with what we have. Should probably do it anyways.
    B: Yeah. Should do that.

     
  • Chris Russell
    Chris Russell
    2013-04-11

    Right... it has to be reversible to send the password to the server, but I think that's just the nature of the beast. Saved passwords in browsers and such have the same weakness. I seem to remember seeing a post somewhere which linked to an app which decrypted passwords saved by Chrome. It is a risk that people, often unknowingly, take every time they choose to save a password.

    The idea of storing a hash and then sending the hash to the server is interesting. Assuming that the server also avoids clear-text, I guess it would need ultimately end up being a hash of a hash server side. :)

    I guess one could argue that clear-text would be fine on the server at that point since the user's secret is still protected and unauthorized access to a Mumble account doesn't expose sensitive information. However, depending on the user's ACL rights, the attacker could certainly wreak havoc and cause some some social damage.

    Given the choice between putting the Mumble account at risk and a user's secret at risk, I would definitely choose the Mumble account, personally.

     
  • Chris Russell
    Chris Russell
    2013-04-11

    Sorry... Just one more thought here.

    Perhaps a phased approach is in order. Disposable code is never ideal, but maybe the first step is to implement standard, reversible encryption and the "save password" option. That should be a client-only change and at least gets rid of the clear-text. The longer-term solution could then explore solutions involving the server to harden the overall password security.

     
  • Stefan H.
    Stefan H.
    2013-04-11

    The thing is: Everyone could go into our code and C&P the section where we decode the thing ;) It would be an awfully bad kind of obfuscation (especially once there is the first tool our there that just does it for you). Not sure if its worth doing.

    Since all that password stuff is more of a fallback (except for SuperUser but that's just one user) - if you value safety use certificates - it hasn't received much focus in the 1.2.X series.

    One big problem I missed in the first post is the fact that authenticators handling authentication against say a phpbb db require the plaintext password to be sent to the server. Kind of a pita...not sure that it's possible to get rid of plaintext in the face of that :(

     
  • Chris Russell
    Chris Russell
    2013-04-11

    Hahaha... Okay. Can we just pretend that I completely overlooked the open-source-ness as a factor despite the fact that it is immortalized on the internet forever? Duh. You even pointed it out and I just missed it, entirely.

    Okay, traditional encryption is obviously out. End of story.

    The certificate approach is definitely more secure, however some would argue that it shifts the security/convenience slider beyond the comfort level of today's average user (an academic debate, to be sure).

    Because my nature as a developer forbids me to easily dismiss problems as unsolvable, I'd like to kick this around a bit more. Especially since, I think we all agree that clear text passwords are... icky. :)

    You will have to help me out with your point about authenticating against a phpbb db. Does this ultimately boil down to third party apps which use the ICE API's "confirm password" method?

     
  • Stefan H.
    Stefan H.
    2013-04-12

    Sure. The Ice interface on the server offers an API to other applications to control the server. It also offers callbacks for various stuff. Authenticators implement such a callback in the form of an authenticate method the server calls if a user connects to it
    (you can see the declaration here https://github.com/mumble-voip/mumble/blob/master/src/murmur/Murmur.ice#L357 ). It gets passed username, password and other things and returns display-name, group memberships and ofc whether the authentication succeeded.

    As the other end might check those credentials against who-knows-what we have to pass it the plaintext password to ensure compatibility. phpbb3 uses it's own hash function, other methods might themselves expect plaintext and so on.

     
  • Chris Russell
    Chris Russell
    2013-04-12

    I've been mulling this over.. I don't think I really need to understand the details behind the "authenticators" to accept the fact that server needs to be able to receive a clear-text password.

    However, I don't think that this necessarily prevents it from also being able to receive a hashed password. It simply requires two authentication paths. Consider this over simplified pseudo...

        // Murmur
    
        authenticateHash( hash ) {
          return ( hash == correct );
        }
    
        authenticateClear( clearText ) {
          return authenticateHash( doHash( clearText ) );
        }
    

    -

        // Mumble
    
        savePW( clearText ) {
          save( doHash( clearText ) );
        }
    
        logIn( hash ) {
          Murmur.authenticateHash( hash );
        }
    

    -

        // MyAuthenticator
    
        logIn ( clearText ) {
          Murmur.authenticateClear( clearText )
        }
    

    Of course, this does not solve the challenge of server-readiness that you raised in your first response. :-/

     
  • Stefan H.
    Stefan H.
    2013-04-12

    If you have a clear text authentication path for the client you need to store the clear text on the client. The server never stores clear-text itself so the client has to send it.

    I think we simply should add a warning on first save with the possibility to disable password saving. That way users will be aware of the implications and have a way to protect themselves (trading a little convenience, I see a pattern there ;) ).

     
  • Chris Russell
    Chris Russell
    2013-04-12

    But the concept here is that the actual Mumble client would always follow the hashed authentication path. Ultimately, all existing (and future) clear-text paths would act as a wrapper to the hashed authentication path. The wrapper would simply apply the same hash routine that the client uses during storage, thus normalizing the value used to authenticate.

    That said, I agree that the critical path for this is definitely the save option + warning, as you suggested. Giving the user the ability to make an informed decision would go a long way and would be a client-only change.

    Any other solution would clearly take a lot more consideration to hash out. ( See what I did there? :P )

     
    • Chris Russell
      Chris Russell
      2013-04-12

      I now fully understand the challenge. I misinterpreted the explanation of the authentication callback.

      It is not a method to be called when "MyServerApp" performs a login -- rather, "MyServerApp" effectively registers the callback and the callback is executed when a user authenticates via the Mumble client.

      Because the callback must receive clear-text, the mumble client must send clear-text. I agree that this makes avoidance of clear-text PW on the client impossible.

       
  • Stefan H.
    Stefan H.
    2013-04-12

    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
    Jelan
    2013-04-28

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

    https://sourceforge.net/apps/phpbb/mumble/viewtopic.php?f=7&t=1079&p=3898#p3898

    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.
    2013-04-29

    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
    Jelan
    2013-04-30

    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
      2013-05-08

      @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
    Jelan
    2013-05-08

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

     
  • Stefan H.
    Stefan H.
    2013-05-11

    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
    Jelan
    2013-05-12

    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
    Jelan
    2013-05-15

    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" :)

     
  • Stefan H.
    Stefan H.
    2013-05-15

    I've seen the pull request. I doubt I'll have time to take a look before the weekend though. Thanks a lot for the contribution.

     
  • Jelan
    Jelan
    2013-05-24

    Friendly reminder when you get the chance to look at the pull request :)
    Thanks in advance and have a nice day !

     
  • Jelan
    Jelan
    2013-06-03

    Hi Stefan, any luck reviewing the PR ? Thx !

     
  • Jelan
    Jelan
    2013-06-16

    Any news ? It's been a month now that I submitted the PR....

     
  • Jelan
    Jelan
    2013-06-16

    And it looks like we have now missed the 1.2.4 stable.... Geez

     
1 2 > >> (Page 1 of 2)