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
sleep).
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
