[standards-jig] Re: [Foundation] Last Minute JEP 78 Concerns
matt at jivesoftware.com
Tue May 27 19:47:17 UTC 2003
> 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.
More information about the Standards