Introduction

This is an addition to the existing Zero-Knowledge authentication. With this addition it becomes possible to never have a user's password sent over the wire or stored on the server, and not require anything other than normal client connections at any point. The network and server are always insecure, both could be compromised at any time, and the server is still able to safely validate the credentials of a user. These are similiar features to using a public/private key based authentication, but much simpler in that the only required algorythms are SHA1 digesting and the client requires no local data other than the users entered password.

Registration

A client supporting this registration method must first determine if the server is capable.

<iq type="get" id="100001">
   <query xmlns="jabber:iq:register"/>
</iq>
<iq type="result" id="100001">
   <query xmlns="jabber:iq:register">
     <name/>
     <username/>
     <password/>
     <hash/>
   </query>
 </iq>

(If this exchange happens for an existing user after authentication, the result would contain existing values in the name and username fields.) The additional 'hash' element in the register namespace is a flag indicating that this server supports zero-knowledge registrations. It is possible that a server may only support this method, and indicate that by not having a password element. To take advantage of this, the client simply sends the zero-knowledge authentication data for the next authentication back to the server like below. In generating these new values, the token should be sufficiently random so that it wouldn't repeat any previously used tokens, and sequences shouldn't be so high that it would incur too much overhead in lightweight clients on lower powered hardware. The server then stores and uses this initial set of values for future authentications. The reason this is secure is due to the nature of zero-knowledge authentication itself, and that one if it's primary features is that the data the server stores can be distributed freely without compromising the next authentication.

<iq type="set" id="100002">
   <query xmlns="jabber:iq:register">
     <name>A B C</name>
     <username>abc</username>
     <hash>hash461</hash>
     <sequence>461</sequence>
     <token>newrandomtoken</token>
   </query>
 </iq>
<iq type="result" id="100002"/>

Zero-Knowledge Authentication

There are no changes to the existing zero-knowledge authentication process, it is the same as it was before.

Reset

The important situation not handled in the zero-knowledge proposal was how to handle when the hashing sequence has hit zero. The very simple answer is for the client to re-register (registration described below) after it's been authenticated and that connection is trusted. The re-registration can happen at any time before the sequence reaches zero, but must happen before or during the last sequence for any further authentications to be possible.