IRC chat protocol does not send password

RESOLVED WORKSFORME

Status

Thunderbird
Instant Messaging
RESOLVED WORKSFORME
5 years ago
5 years ago

People

(Reporter: nandhp, Unassigned)

Tracking

24 Branch
x86_64
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

After upgrading Thunderbird yesterday (from 17, I believe), I can no longer connect to IRC; it does not send the account password.

1. Create a TCP listener
    socat - tcp-listen:6667
2. Create a IRC account to localhost and specify a password in the account settings
3. Password is not sent to the server


Actual results:

CAP LS
NICK foo
USER Thunderbird 0 * foo

Thunderbird error log data from attempt to connect with an actual server:

Timestamp: 09/21/2013 10:24:24 AM
Error: Received unexpected ERROR response:
Bad password
Source File: resource://gre/modules/ircBase.jsm
Line: 169
Source Code:
prpl-irc

The server I use is a private server based on ngircd 14.1. It uses a server password to control access. When I send these messages to the server manually, I get "ERROR :Bad password" and the connection is closed. Adding an appropriate PASS command causes the connection to succeed.


Expected results:

PASS password
NICK foo
USER Thunderbird 0 * foo

Comment 1

5 years ago
As a workaround, try setting the about:config pref messenger.account.accountN.serverPassword (where N is the number of the account) to your password. This should make TB send PASS.
(Reporter)

Comment 2

5 years ago
That didn't work, but messenger.account.accountN.options.serverPassword does work instead.
Thanks for the workaround.
(In reply to nandhp from comment #2)
> That didn't work, but messenger.account.accountN.options.serverPassword does
> work instead.
> Thanks for the workaround.

This is the expected result and the proper solution.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 4

5 years ago
If you do not wish to support server passwords (why not?), I believe there is still a bug since the password field does not behave as expected. Upon further testing, I find that this password field is for NickServ. Most experienced IRC users would expect this to be a server password, not a NickServ password, especially since many public servers forward the server password to NickServ. You should clarify the kind of password in the account settings: Server password? NickServ password? OPER password? Channel key?

Additionally, I am not entirely comfortable storing my password in prefs.js, as one of the computers I use Thunderbird on has an NFS home directory. One of Thunderbird's features is a password manager with a master password. Passwords should be stored there so they can be encrypted; I consider this insecure password storage to also be a bug.
(In reply to nandhp from comment #4)

> Most
> experienced IRC users would expect this to be a server password, not a
> NickServ password, especially since many public servers forward the server
> password to NickServ.

The target user for IRC in Thunderbird doesn't know more than one password can exist, and doesn't want to know.

> You should clarify the kind of password in the account
> settings: Server password? NickServ password? OPER password? Channel key?

It's the account password, and we do whatever is the most likely to cause the user to successfully be identified. Any 'clarification' here would actually cause confusion.

I think this is the first time I hear someone needing the server password specifically. We created the serverPassword preference just in case it was ever needed; to be on the safe side when we implemented SASL auth. It looks like we were right to keep a pref for it (even though you may be the only one actually using it).

> Additionally, I am not entirely comfortable storing my password in prefs.js,
> as one of the computers I use Thunderbird on has an NFS home directory. One
> of Thunderbird's features is a password manager with a master password.

The account passwords are stored in the password manager. If you want to store the server password there too, clokep would likely accept a patch for it (we just discussed this on IRC).
(In reply to nandhp from comment #4)
> If you do not wish to support server passwords (why not?),
We do explicitly support them, changing that pref sends a server password.

> I believe there
> is still a bug since the password field does not behave as expected. Upon
> further testing, I find that this password field is for NickServ.
I disagree, it's working for what most users would expect it to be -- the password tied to their nick, which is all that most users care about. The majority of servers I've come across don't have a server password set.

> Most
> experienced IRC users would expect this to be a server password, not a
> NickServ password,

> especially since many public servers forward the server
> password to NickServ.
In an insecure fashion, it's sent in plaintext...which is certainly bad if you're not using SSL, and still kind of bad otherwise. We prefer to use SASL to send this password when available.

> You should clarify the kind of password in the account
> settings: Server password? NickServ password? OPER password? Channel key?
I don't think it needs to be clarified, most users just want to log into the server...to them that means connect and identify their nick. Most servers I've seen don't have a server password. The channel key suggestion is egregious, it's obviously not for a channel key. Most users don't care about an OPER password either.

> Passwords should be stored there so they can be encrypted; I consider this
> insecure password storage to also be a bug.
Yes, this is a bug. Please file a bug report for it. I'd love to get this fixed, but don't have the time to do it...and it requires a bit of infrastructure in how we store our prefs to be fixed first. I'm willing to help someone work through this if they're interested.

If these issues were fixed, we'd then include the server password in the advanced options UI, by the way.
Duplicate of this bug: 920480
You need to log in before you can comment on or make changes to this bug.