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

wrong password for user


sogiya
 Share

Recommended Posts

ok, after weeks of having no issues we suddenly got hit by the "wrong password" issue, I never changed the password and no one was fiddling with any permissions or anything so this is all kinda out of the blue.


what is going on with this? I know this isn't the first time this issue has popped up ....

Link to comment
Share on other sites

  • Administrators

The 'Wrong Password' error is a little ambiguous, because it doesn't only refer to passwords, but also certificates. I'm also not sure how much you know about the Mumble user registration process, so I'll try to describe that as well.


The suggested method of authentication in Mumble is by using certificates. On first launch, Mumble will ask you to either import, auto-generate or manually generate a certificate for use with Mumble.


When you register your user with a Mumble server, the hash of the certificate is stored in the server's database. Once it's stored there, Mumble will effectively use the hash of your certificate as your user's password. That is, if you attempt to connect using the username, but *without* using a certificate, OR using *another* certificate, you'll get the 'Wrong Password' error.


Is there a certificate configured in your Mumble client?


Do you still have our usual certificate configured in the Mumble client? (No, I'm not expecting you to remember the details of your certificate if it was auto-generated by Mumble).


If it is auto-generated, and thus hard to distinguish, one way to check whether your certificate changed is to connect to a random server, right-click on your user and chose 'Information'. Then, in the User Info dialog, click the 'Details' button for your certificate. Then, check the 'Valid Before' date.


If it's old, it's probably your usual certificate, and something's weird on the server-side of the server you're connecting to. If it's recent, you might have accidentally overwritten your old certificate by running the Certificate Wizard...


Anyway, a "fix" for this issue is to get an administrator to delete the registration for your user on the server using the Server -> Registered Users tool. Once your user is removed, the server will not try to enforce anyone connecting with that username to have the certificate you initially registered with.


Hope it helps.

Link to comment
Share on other sites

Perhaps I am interpreting this wrong, but if it is the case that the server reads the certificate from its database, does it not matter which computer one logs onto a server with? Occasionally I connect to my server with another computer at another location and have to get a fellow admin to remove my certificate or use a different name altogether.

Link to comment
Share on other sites

  • Administrators

Only the hash of your certificate (your public key is part of the certificate) is stored in the server's database.


To log into a Mumble server with a client certificate, you have to complete a TLS handshake. The TLS handshake when using client certificates includes a verification step. The client signs a blob of data in order to prove to the server that it is in

possession of the private key of the certificate.


The hash that is stored in the server's database is only a hash of the certificate (not the private key -- the server never sees it). What this boils down to is that in order to successfully authenticate to a Mumble server you have to be possession of both the private key and the certificate (public key).


However, if you're using an auto-generated (self-signed) certificate you can export it and import it on other machines of yours. Or if you're using a certificate from a CA you can import it into as many of your Mumble installations that you wish.

Link to comment
Share on other sites

everyone on the server was using certs with no problem, I contacted the host about this and they said that:

 

Hi,

This is a problem we have been experiencing since updating the servers last night. Unfortunately the only way around it is for all users to create a new certificate. They can do this by going to Mumble -> Configuration -> Certificate Wizard.

My apologies for the inconvenience.

--

Regards,

Jonny 'Slanty' Hughes

Support: http://support.multiplay.co.uk

Live Support: http://www.multiplaygameservers.com/support/irc/

IRC Support: #mpukhosting"

 

from what all you guys have said it sounds like the problem with this is the server's cert hash is getting invalidated somehow (invalidation by deletion being the most likely), however there seems to be no easy way to make the server to re-establish the certs hash once it is established.


making a new cert (from my limited understanding) is essentially force re-setting the cert hash with a new cert, but that seems kinda wasteful to me 'cause we are having to reestablish registered users and generating multiple certs when the old one is still valid: isn't there some way to make the server dump it's hash and reestablish the handshake settings off of an existing cert? (or something like that ... I think I said what I am trying to say)


look, I understand what you are trying to do with these certs being hyper secure, but it kinda seems that they are too secure! there has got to be a way for us to override what the server THINKS is a bad handshake without having to do what amounts to starting a new user account.

Link to comment
Share on other sites

  • Administrators

sogiya,


Using certificates as opposed to passwords has some benefits. They're unique per-user, not per-server. This means that you can use the same identity on multiple servers, which allows for things like the friends feature in Mumble. If you've friended someone on one server, and you see them on another server, they're still your friend. This allows us to have some form of trans-server identity without having a central login for all Mumble users.


As with passwords, server administrators still have the ability to change the certificate hash that's associated with your user. However, the 'Registered Users' panel in the Mumble client only allows you to delete old users, not change the contents of their registration. (Basically, it's easier for the user to simply log on again and register himself, rather than having an admin do it manually.)


Also, just to make things clear, each of your users do *not* need to generate new certificate to get re-registered to the server. If something weird happened to the database, and the stored cert-hashes are no longer valid, you can simply delete all users, and start from fresh. Unfortunately, this also means that you'll have to re-establish your groups, since the old members have been deleted.


More on the actual issue:

If you get the 'Wrong password for user' error, it means that there IS a certificate hash, or a password in the database for the username you're connecting with.

It seems like Multiplay.co.uk were having some issues after a server upgrade. (I guess they updated their Murmur installs to 1.2.3?)

To my knowledge, there have been no similar issues reported to us, so I'm not sure whether it's an issue with Murmur, or perhaps that something went wrong during Multiplay's update...

Link to comment
Share on other sites

 Share

×
×
  • Create New...