[Standards] Account Management protoXEP

Jehan Pagès jehan.marmottard at gmail.com
Wed Nov 9 13:52:06 UTC 2011


On Thu, Sep 22, 2011 at 4:03 AM, Alexander Holler <holler at ahsoftware.de> wrote:
> Am 21.09.2011 20:10, schrieb Remko Tronçon:
>> Putting account management in ad-hoc commands means that we don't
>> expect clients to have a "Change password" button, but instead go
>> through the server provided "Change account settings" dialog. It takes
>> away power from the client (it won't be able to add fancy things like
>> password strength measurers), but it gives more power to the server to
>> provide a UI (e.g. instructions) that fit it, and it saves client
>> development time :-)
> Hmm, that might add some security concerns when generalized fields (like
> text-private) are used for passwords.
> I know, it's really hard to eleminate every occurence of the password from
> memory, but at least clients would have the ability to do whatever they
> think is needed to protected the (typed in and maybe stored) password from
> getting revealed.
> Every time when password dialogs are mentioned I remember the time where it
> was possible to use a (windows-)tool e.g. to display the password in
> outlooks password dialog as clear text inbstead of * (long fixed) ;)

Re-reading a little this topic before passing to council vote, I add
my voice to this point too! That's another good reason why ad-hoc
commands are probably not adapted. The more I think about it, the less
I think ad-hoc fits password modification (or account creation).
Ad-hoc is a great feature but is too generic for being secure (in its
current state in particular, but in general too) and credentials are
typically a part of the protocol which needs special care (not showing
the password in the GUI for anyone overseeing over the user's
shoulder; specific processing and encryption before passing through
the wire from client to server; never be actually known, if possible
like for SCRAM, not even to the user's server, because users tend to
have the bad habit of using the same password everywhere, etc.).

I really think we need a specific protocol. I am ready to accept a lot
of remarks and edit the XEP, we can discuss how to improve and
simplify/secure/enhance/modify the protocol accordingly, or even
divide whole part of the XEP if really needed (for instance some
people wondered whether we should not split registration and
management part; I could make 2 XEPs for this). But let's have a
secure approach and not stay in our current "all in plain text,
without any precaution nor specific GUI" approach.

That's it. :-)


> Regards,
> Alexander

More information about the Standards mailing list