[standards-jig] Re: [Foundation] Last Minute JEP 78 Concerns

Matt Tucker matt at jivesoftware.com
Tue May 27 19:47:17 UTC 2003


Dave,

> At any rate, while SASL would be a good way to go, the idea is that our 
> digest based scheme will always be available as a super simple fallback 
> authentication method, should a server choose to deploy it.  This tweak 
> to the digest mechanism was done to ensure, as Iain said, some amount of 
> security  outside the context of Jabber.

What if we added a note to the auth JEP that clients may choose to SHA1 
the password before sending it to the server if they wish to have added 
obscurity? This would accomplish the same thing as edigest while keeping 
our current protocol intact.

> Actually, Matt, this does break backwards compatibility. Let's say I use 
> a new client to login/register and it SHA-hashes my password before 
> registration, like you suggest. Then I switch to another, older client 
> and attempt to login -- that older client will be able to log me in, 
> because it simply won't know to SHA-hash the plaintext password before 
> SHA-hashing w/ the Stream ID. So we do need a new element for this to work.
> 
> I'd recommend that we go ahead an use <edigest> and deprecate usage of 
> <digest>. This path ensure backwards compatibility.

I think this is a somewhat silly use case. The important aspect of 
backwards compatability is on the protocol level, not on the "user using 
two different clients level", especially since it's very rare that a 
user actually uses two clients (yes, besides us developer geeks). It 
just doesn't seem worthwhile to create a new digest mechanism that:

  1) Is the exact same thing that we're using now, just with different 
wording saying "don't send a plain text password".
  2) Doesn't provide any real security enhancements, just obscurity.
  3) Will break all old clients, libraries, and servers.

Instead, let's encourage people to either use SASL, or solve security 
problems in a real by either using SSL or by implementing encryption at 
the database level. It seems worse to give a false sense of security 
than to do nothing at all given all the other considerations.

Regards,
Matt




More information about the Standards mailing list