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
