[Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]

Ian Paterson ian.paterson at clientside.co.uk
Tue Sep 11 19:08:55 UTC 2007

Kevin Smith wrote:
> On 11 Sep 2007, at 17:20, Ian Paterson wrote:
>> Even where TLS is available, SASL PLAIN requires server operators to 
>> keep copies of all users' passwords. This is a serious (and often 
>> unnecessary) security weakness.
> I'm not sure that's true; the server could hash the password still, 
> both in storage and at the end of the wire. It doesn't help against a 
> compromised server that's still accepting connections, but the 
> passwords don't need to be stored plaintext afaics.

Yes, sorry everyone who corrected me. That was my silly error (lack of 

In real life servers will always be compromised (especially in cases 
where the attacker is the service provider). So SASL PLAIN still 
contains a serious vulnerability that is easily fixed in those cases 
where DIGEST-MD5 is a practical option.

Mridul Muralidharan wrote:
> Ian Paterson wrote:
>> Peter Saint-Andre wrote:
>>> 1. Remove DIGEST-MD5   
>> I strongly disagree. Restrained (Web) clients can't implement TLS 
>> over TCP/IP. So without DIGEST-MD5 the passwords would end up being 
>> transmitted in the clear!
> Run webcontainer in https instead of http ? The tls will come for free 
> for webclients.
> imo, it is much more easier to support TLS + PLAIN than DIGEST MD5 for 
> constrained clients - use secure transport (handled outside http 
> client), and use plain.

Yes, but I mentioned "TLS over TCP/IP" rather than simply "TLS" because 
I had Flash Web clients in mind. AFAIK, Flash clients have been 
connecting over TCP/IP not HTTPS.

Dave Cridland wrote:
> Yes, but they're not acting as fully conformant RFC3920bis 
> implementations, then. :-)

I guess that means that XEP-0124-based implementations aren't either? 
There will probably always be some runtime environments that prevent 
client applications conforming with RFC3920bis (but still allow them to 
connect to Jabber servers).

> You do have to send the password clear to the server, so there are 
> potential MITM issues - you don't want to be sending your password 
> unless you really know you're talking to the right endpoint. Hopefully 
> TLS certificate validation provides sufficient server authentication 
> that you'll avoid this, but it still unnerves me.

Me too, especially since if the server is compromised then the TLS 
certificate validation doesn't help at all.

Michal 'vorner' Vaner wrote:
> On Tue, Sep 11, 2007 at 10:00:52PM +0530, Mridul Muralidharan wrote:
>> Ian Paterson wrote:
>>> TLS + DIGEST-MD5 is stronger than TLS + SASL PLAIN
>> In what way ? On the wire there is no difference.
>> If end to end there is tls (from the client to the server), then there is 
>> not much difference between both.
> No-one knows, when TLS gets broken, like got many other encryption
> methods before. This way you get one security layer more and gives you time.

That's possible... But more importantly, we can be *sure* that some 
servers are going to be compromised. And in those cases all 
authenticating clients using SASL PLAIN will deliver the users' 
plaintext passwords to the attacker! (This matters because users 
typically employ the same password for many independent systems.)

> IMO clients (whenever possible) should be able to do both PLAIN and DIGEST-MD5.

I agree clients MUST support DIGEST-MD5. If servers MUST support 
DIGEST-MD5 too, then I agree with the requirement that clients MUST also 
support PLAIN (since clients will still always be free to choose 
DIGEST-MD5) *except* in those cases where upon account registration the 
user provided their DIGEST-MD5 inner password hash (not their password).

>  If you need server that does not store the passwords
> plain-text, then you have to choose PLAIN, probably.

Hmm, AFAIK such password protection is a designed feature of DIGEST-MD5. 
To take advantage of the feature, when registering a new account a user 
must provide their DIGEST-MD5 inner password hash instead of their password.

- Ian

More information about the Standards mailing list