It's been quite a while since I looked into the details, but I do know that the SyncML (or OMA DM as it is known now) protocol provide authentication with HTTP as one of the available transport protocols. I think it uses a shared secret. Might be worth looking into. See http://member.openmobilealliance.org/ftp/public_documents/dm/Permanent_documents/OMA-DM-Security-V1_2_0-20050120-D.zip for the general architecture and details.
Regards, Mark On Mon, Jan 11, 2010 at 12:48 PM, Twylite <twyl...@crypt.co.za> wrote: > Hi, >> CHAP: (originally from PPP) >> >> send a challenge string from server to client. The client sends back >> H(challenge || password). Someone now has to brute-force the password >> if the communication is intercepted. The downside is that the password >> is stored in plaintext on the server. > Another downside: when using HTTP as your transport, you always require > an initial HTTP request the get the challenge. In addition the server > must track the tuple (username, challenge, clientIp, timeIssued), or > more generally implement sessions using cookies. > > You _can_ turn this into a stateless protocol (ISO 9798-2 protocol 1) by > deriving a shared secret K = KDF(password) for some Key Derivation > Function KDF, and sending something like E[K]( T || S || username ) or > username || T || HMAC(k, T || S || username ), where T is a timestamp > and S is the distinguished identity of the server. The server must > store T on every transaction, and reject an authentication attempt if T > is older than or equal to the stored T. > > Note that you must store KDF(password) on the server, and it cannot be > salted as the client must compute KDF(password) on demand. > > To ensure that you can still support a web interface, it must be > possible for the server to accept a plaintext password (via a form POST > over HTTP or HTTPS) and compare it against a stored value. KDF() will > allow this, but because it cannot be salted it may susceptible to > rainbow table attacks (depending on the function used). >> There are methods that solve both problems (not storing the password >> on the server, and not sending the password over the wire), but you >> enter a major patent mine field if you try to use them. > Moreover, many are not compatible with submitting a plaintext password > in a form. > > Regards, > Twylite > > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
