I was wondering if this was already done … or there was a way to do this … what if RSA key was sent as soon as one logged into the server … while login of the wildfire account … then that RSA key could be used to encrypt the transport password … which can then be decrypted by the transport … …
was wondering if this was already done …
Eg.
usera -> logins in …
wildfire returns RSA key
usera -> encrypts all its passwords with that RSA key
wildfire/transport -> decrypt it
Message was edited by: schandra
The plugin follows XEP-0100. The expectation is not that the registration process itself would be complicated with encryption, but that the entire session is done via SSL/TLS. Ideally you should be connecting to Wildfire via SSL/TLS.
hmm I agree. SSL is too heavy … I was hoping that only the passwords could be encrypted and decrypted during the registration phase and authentication through digest (which already happens).
Isnt this secure and light weight than SSL ?
Just a thought.
Why is SSL too “heavy”? SSL/TLS is the standard for connection encrypted to services, and I don’'t really see a point in double-encrypting.
hmm … SSL socket connections are not very significantly slower than normal socket connections, that is very true … but when all I need to do is secure my clients password … there isnt a need to have all communications through a secure channel … over the long run over a lot of users, this secure connection overhead will creep up …
this happens only during registration … so when I first login to the wildfire sever … So assuming this is the getRegistration for the transport stanzas.
<iq to="admin@140.252.15.110/xiff" type=“result” from=“msn.140.252.15.110” id=“reg_info_8”><query xmlns=“jabber:iq:register”><x xmlns=“jabber:x:data” type=“form”><instructions>Please enter your MSN Passport e-mail address and password.</instructions><field var=“username” type=“text-single” label=“E-Mail Address” /><field var=“password” type=“text-private” label=“Password” /></x><instructions>Please enter your MSN Passport e-mail address and password.</instructions><username /><password /><x xmlns=“jabber:iq:gateway:register” /></query></iq>
So the above doesnt tell me a mechanism on how I can encrypt … so if the stanza was changed just a little bit … like below in red …
<iq to="admin@140.252.15.110/xiff" type=“result” from=“msn.140.252.15.110” id=“reg_info_8”><query xmlns=“jabber:iq:register”><x xmlns=“jabber:x:data” type=“form”><instructions>Please enter your MSN Passport e-mail address and password.</instructions><field var=“username” type=“text-single” label=“E-Mail Address” /><field var=“password” type=“text-private” label=“Password” /><field var=“rsa_key” label=“asdasdasdadsdadasdasdad” /></x><instructions>Please enter your MSN Passport e-mail address and password.</instructions><username /><password /><x xmlns=“jabber:iq:gateway:register” /></query></iq>
when I register I can encrypt the password using this key … and this since the server will know the private key … the server will decrypt it before it goes ahead and registers the transport …
This only has to be done during the registration phase … and thats it … this makes the transaction secure … just for the password … therefore the “heavy” comment …
Now there is no need of double encrypting … just encrypting once … and that too just while registering …
Message was edited by: schandra
If you connect to your XMPP server in the first place via non-SSL/TLS, then you are passing your password effectively in clear text then. Not your MSN/whatever password, but your XMPP password itself. By that point, you’'ve already opened up your account for clear text shenanigans. Granted, there are some mechanisms to “help” that not be as clear…
If you connect to the XMPP server via SSL/TLS, in a nice secure fashion, then you are not exposing your password or any form of it in the first place, and your entire conversation with the server is secure so what you are passing to the transports is also secure.
Anyway, if you feel strongly that the stanza for the handling of passing the username and password as stated in XEP-0100 should be changed, you may want to bring it up to the XMPP council themselves. Perhaps on standards-jig or maybe jdev.