WWW User authentication
I just finished writing a cgi script to allow users to change their login passwords via a webpage. I currently have the webpage being authenticated with the basic option (uuencoded plaintext). MD5 would be nicer, but how many browsers actually support it? When the user changes their password, the form sends their name, old password, and new password with it, in the clear. This is no worse than changing your password across a telnet connection, but I'd like it to be more secure, but useable by a large number of browsers. Any advice? Brian ------- <blane@aa.net> -------------------- <http://www.aa.net/~blane> ------- Embedded Systems Programmer, EET Student, Interactive Fiction author (RSN!) ============== 11 99 3D DB 63 4D 0B 22 15 DC 5A 12 71 DE EE 36 ============
Brian C. Lane writes:
I just finished writing a cgi script to allow users to change their login passwords via a webpage. I currently have the webpage being authenticated with the basic option (uuencoded plaintext). MD5 would be nicer, but how many browsers actually support it?
AFAIK, none. I don't see how this would be helpful anyway. If you MD5 the password, I won't be able to snoop the password off the wire, but I can simply snoop the MD5 hash off the wire instead and since that's what your authentication check must now be against, what does this buy you?
When the user changes their password, the form sends their name, old password, and new password with it, in the clear. This is no worse than changing your password across a telnet connection, but I'd like it to be more secure, but useable by a large number of browsers.
Any advice?
Well, if you use SSL, it's useable by a "large number of browsers" since Netscape has such a large share of the browser market. And then all of the things you're doing w.r.t. authentication are hidden, at least from casual eavesdroppers and others too if you use more than the 40-bit option. There's really no other choice to reach a large number of browsers. -- Jeff
AFAIK, none. I don't see how this would be helpful anyway. If you MD5 the password, I won't be able to snoop the password off the wire, but I can simply snoop the MD5 hash off the wire instead and since that's what your authentication check must now be against, what does this buy you?
It would require a previous shared secret, but wouldn't the following protocol work (pardon my ASCII diagram): Q - Shared secret; Both server and client know this R - Random challenge; Server sends in clear to client wanting to be authenticated. Server Client 1) Request auth 2) Send R 3) Send back MD5( R, Q ) 4) Compare recieved value to computed value Granted this straight off the cuff, and you can't securely change Q via this protocol (unless you store previous MD5(R,Q)'s and use that as the next Q (i.e. Q_n+1 = MD5(R,Q_n))). Once someone gets MD5 in Java done, you could send an applet that would handle the protocol client side. --- Fletch __`'/| fletch@ain.bls.com "Lisa, in this house we obey the \ o.O' ______ 404 713-0414(w) Laws of Thermodynamics!" H. Simpson =(___)= -| Ack. | 404 315-7264(h) PGP Print: 8D8736A8FC59B2E6 8E675B341E378E43 U ------
On Tue, 9 Apr 1996 11:58:34 -0400 (EDT), you wrote:
AFAIK, none. I don't see how this would be helpful anyway. If you MD5 the password, I won't be able to snoop the password off the wire, but I can simply snoop the MD5 hash off the wire instead and since that's what your authentication check must now be against, what does this buy you?
It could be implemented thus: Server and client have a shared secret. The server sends the time, or some random # to the client which MD5's this number and the secret, and sends the result back to the server which then checks is. Similar to the APOP command for POP3 that I've never seen implemented. Brian ------- <blane@aa.net> -------------------- <http://www.aa.net/~blane> ------- Embedded Systems Programmer, EET Student, Interactive Fiction author (RSN!) ============== 11 99 3D DB 63 4D 0B 22 15 DC 5A 12 71 DE EE 36 ============
Right now, the only solution I know of is to use cookies for browsers that support them, and do all the MD5-ing yourself. That excludes some browsers, but you can support those in the totally insecure manner. On Tue, 9 Apr 1996, Brian C. Lane wrote:
I just finished writing a cgi script to allow users to change their login passwords via a webpage. I currently have the webpage being authenticated with the basic option (uuencoded plaintext). MD5 would be nicer, but how many browsers actually support it?
When the user changes their password, the form sends their name, old password, and new password with it, in the clear. This is no worse than changing your password across a telnet connection, but I'd like it to be more secure, but useable by a large number of browsers.
Any advice?
Brian
------- <blane@aa.net> -------------------- <http://www.aa.net/~blane> ------- Embedded Systems Programmer, EET Student, Interactive Fiction author (RSN!) ============== 11 99 3D DB 63 4D 0B 22 15 DC 5A 12 71 DE EE 36 ============
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jeremey Barrett Senior Software Engineer jeremey@forequest.com The ForeQuest Company http://www.forequest.com/ "less is more." -- Mies van de Rohe. Ken Thompson has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gage, nor any of the numerous idiot lights which plague the modern driver. Rather, if the driver makes any mistake, a giant "?" lights up in the center of the dashboard. "The experienced driver", he says, "will usually know what's wrong." -- 'fortune` output
participants (4)
-
blane＠aa.net -
Jeff Barber -
Jeremey Barrett -
Mike Fletcher