Re: Jabber broken in 1.0.1 & Fire CVS?

On 10 Jun, 2004, at 07:22, Evan Jones wrote:

> On Jun 9, 2004, at 18:53, Evan Jones wrote:
>> I'm trying to log in to a private Jabber server that has been set up 
>> here recently, and it doesn't seem to let me (Unauthorized errors). 
>> However, using Nitro works just fine. I believe the Jabber server is 
>> using Twisted, and the connection is over SSL. Is this a known issue?
>
> Ah ha! I figured it out: the problem is not specifically a problem 
> with Fire. It is actually a problem with the server's configuration. 
> The server is using PAM to authenticate with user's Unix passwords. 
> However, it is advertizing that it supports Digest Authentication. 
> Unfortunately, digest authentication requires access to the plain text 
> passwords on both the server and the client. This is not possible on 
> the server side, since the passwords are safely stored in /etc/shadow 
> in a hashed form.
>
> So the server is broken: it shouldn't be advertising auth. However, to 
> successfully log in, I had to comment out the code that enabled digest 
> authentication. So, my question is, would there be any interest in a 
> patch that will retry the connection without digest, in case digest 
> authentication fails?

After warning you that digest authentication failed, of course (or a 
checkbox to use plaintext).

Of course, it's probably incorrect to say that the server is "broken". 
All *NIX account passwords are stored hashed in one way or another, and 
are probably not of the form used in the digest [1] [2]. Take qpopper, 
for example. It has digest authentication, but since MD5 is applied on 
the server tag and the plaintext password, the server has a database of 
the passwords. In this case, it's important that the password used is 
NOT one that is used for other accounts, as it's stored plaintext.

There's probably some program to stuff a password into the database 
(such as htpasswd for Apache).

-- Purr

[1] HTTP digest authentication stores hashed passwords, 
MD5(username:realm:password). These are "plaintext equivalents", 
because you only need to know the digest, not the actual password used 
(this is so you can use the same password for multiple places, and if 
someone gets the password file, the only have access to one place). 
They are, of course, better than NT passwords, which is just 
MD4(password_in_utf_16), which ends up being the same for every NT 
server.

[2] Nobody would use the hashed unix password anyway, because the point 
of a hashed password is that even if you get it, you can't get access 
to other systems that use the same plaintext password (APOP is, of 
course, stupid in this respect) [3].

[3] Random hex characters ("dd if=/dev/urandom count=1 | openssl md5" 
(or hexdump if you so prefer)) make a suitable hashed password for 
APOP, since you can change it anyway by logging in normally. 
Alternatively, with "openssl base64", which has two extra bits per 
character, making it take 4^n times longer to guess. You might want to 
strip the / and + though ("tr -d /+").

I'm being ranty.



-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Fire-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fire-talk
Have a question? Please read the Fire Frequently Asked Questions:
http://fire.sourceforge.net/faq.shtml