[Standards] Account Management protoXEP

Jehan Pagès jehan.marmottard at gmail.com
Sat Nov 5 07:18:54 UTC 2011

Hi all,

sorry for the very delayed answer! I won't display any excuse because
I guess you don't care. ;-)
Anyway I'll try to answer the various remarks on the topic.

On Thu, Sep 22, 2011 at 12:53 AM, Dave Cridland <dave at cridland.net> wrote:
> The intent of this is good; something providing similar capabilities to
> XEP-0077, but in a  consistent manner, seems like a good and useful thing to
> be working on.
> However, I don't think this is the right approach, to the extent that I
> don't think this is fixable. Addressing the issues that have been raised in
> Council would mean a complete rewrite of the spec, so at this stage I think
> it would be easier - if there is will to replace XEP-0077 at all - to write
> a new XEP. So I'll phrase my feedback as a counter-proposal.
> The majority of account management - save for registration itself - can be
> done as inline <iq/>s to the server, or some entity which the server
> effectively delegates to. This makes sense - we might, for example, use a
> component which interfaces in some more direct manner with Active Directory,
> for example.

I would not mind about separating "existing account management" and
"new account creation" into 2 XEPs. I myself wondered what would be
the best logics for this and we discussed this a little with Peter
before I made the proposal. So I was definitely expecting remarks and
hoping for discussion on this point.
Also considering that most clients supports only the registration part
from the current XEP-0077, and that some servers already support some
account management (like changing password) through ad-hoc commands,
that could make some sense to separate registration from the rest.

In the end though, there still need (in my opinion at least) to have
some dedicated XEP to be able to send only processed encrypted data on
the wire, not plain text password, whatever this is for
registration-only or password modification in particular. Because I
don't think continuing to have registration (as well as ad-hoc
commands to change one's password) in plain text is quite an
acceptable solution (while in the same time, we publicize XMPP as so
secure). This is definitely a single point of failure in security.

That being said, I still think other parts I proposed are interesting
(maybe in a different XEP if really necessary). Having possibility for
a server to ask for users to update their password on login would be
pretty nice. With SCRAM for instance (which is after all our new
reference for auth!), unless both client and server store the password
in plain text, you cannot change the salt or the iteration count
easily without this kind of feature.
But as I said, I would find acceptable to report this kind of feature
(to a separate XEP?) in favor of at least the secure in-band
registration part of the current XEP.

> The server will always need your plaintext password, for a number of
> reasons, but most obviously enforcing password policy. Any attempt to avoid
> clients passing the password in clear to the server should not be worked on
> in this forum - we simply don't have the expertise.

I don't agree. A server does not need the plaintext password. I think
that's wrong that some implementations still keep the password (or
with a very weak bidirectional encryption), and I saw that some
servers already made the implementation so that they are able to store
only pre-computed encrypted data (clientKey, serverKey). I've read
some blog posts on Prosody about this for instance. I hope this is not
the only server doing so and would like that all servers do so (or at
least propose configuration choice for this).

Also our reference is now SCRAM, whose some of the main advantages is
that we can have a flow where neither the server nor the client ever
store plain text passwords (which is a great assets for security.
Attackers needs to do password-by-password attacks, which eliminates a
lot the efficiency of rainbow tables). That's one of its big strength.
Saying now that anyway it does not matter and the server should still
have access to the plain text password seems contrary to all what
SCRAM has been designed for!
Also another strength of SCRAM is its ability to never pass anything
easily decipherable on the wire. Transmitting the plain text password
at account creation is also like another point of failure in secure
So saying that we should transmit and store passwords in plain text
just cancel the whole point (at least the 2 main strong points) of

In today usages, of course the fact that the server can enforce some
password policy is ok, but this task can be done by the client too
(and I don't understand why you seem to think that server implementers
or administrators would have more expertise for password strength than
client developers). And in particular I think that the fact that the
server never even once got access to our real password out-weights
every other advantage to plain text password. Especially with most
users using the same password everywhere (seems unfortunately the most
common usage, educating them not to do this would be best, but let's
be realistic), it matters more to their security that this password is
well protected and unknown (even to this one service) than having an
extremely strong password that all the services you know around the
Internet share and know.

Finally recognition of "secure password" is far from being perfect. It
has been demonstrated far enough that you can have some very strong
passwords made of several common words while you can have very weak
passwords with mixing letters/numbers/other which are yet recognized
as "strong" by many service algorithms (I saw so many bad algorithms
to recognize the strength of a password that I don't trust servers for

> Registration does indeed pose a problem - I see three strategies for dealing
> with it:
> a) We avoid the issue entirely. This is probably the sensible option - it's
> conceptually distinct from other areas of account management in any case.
> b) We use stream features or pre-auth IQ. Neither are, to my mind, terribly
> palatable.
> c) We use anonymous authentication to the server (or its delegated account
> management service) and then use fairly ordinary <iq/>s. This seems to fit
> neatly into the design of XMPP.

I don't think this is a good use of anonymous authentication. For one
reason at least: some servers may want in-band registration but no
anonymous authentication for "normal use cases" (contacting someone,
chatting, etc.). Then they would allow anonymous auth but with very
restricted permissions (you could use it only for the registration).
And this would startle clients and users of these clients which detect
anonymous auth on a server and would try to use it for other usages.
They will be able to connect but not to do anything (they would get
errors when trying to send messages for instance). That would be like
a terrible user experience, especially as the user would probably not
understand why one can connect anonymously but not do anything from
here, hence would blame it on the client/server/network/whatever (it
would look like it is bugged, not like it is a design choice).

For this reason, I think that's really a bad idea to use anonymous
auth out of its original purpose. A dedicated stream feature does not
have this kind of issues.


> For both account management and registration, using the ad-hoc framework
> seems most sensible - it would allow us maximum flexibility as well as
> near-instant deployment.
> If this seems like a good starting point, then I'm perfectly happy to write
> this up, and equally happy if someone else wants to.
> Dave.
> --
> Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
>  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list