Hi, On Thu, Sep 22, 2011 at 4:03 AM, Alexander Holler <hol...@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. :-) Jehan > Regards, > > Alexander > >
