Re: WWW User authentication
At 11:58 4/9/96 -0400, Jeff Barber wrote:
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?
Well, that isn't exactly how digest authentication works. In fact mister barber should figure out what he is talking about before saying anything. But, you can't really use a hash function to send the new password.
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
Once again mister barber is being an idiot. netscape is not a "large number of browsers". He is right that ssl is probably a good way to go. (shttp would be better :) ) You might be able to hack something together with java that did some kind of clever thing, but then you are limited again. CGI just isn't made for sending secure information. As far as digest (MD5) authenitcation goes, I know that the spyglass browser, and most of its derivatives (like m-soft i-net explorer) can use it. I know cause I did a lot of the QA on it. The real problem is finding a server that supports it. I don't know if apache or ncsa do, but they could probably be hacked to do it. If you download a spyglass server, I know it works (I did a lot of the early QA on that too ). But that probably doesn't help too much. You should probaly find something better than the web to do it. Chris ############################################ Chris Stillson Chief Rocket Scientist Resident Web Geek Hip Young Nerd Second Rate graphic designer Unix Guru In other words, Webmaster American Software & Hardware Distributors fluffy@ashd.com Check out our web site-> http://www.ashd.com Cause I did it all.... stop the CDA. Check http://www.eff.org ############################################
Chris Stillson writes:
At 11:58 4/9/96 -0400, Jeff Barber wrote:
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?
Well, that isn't exactly how digest authentication works. In fact mister barber should figure out what he is talking about before saying anything. But, you can't really use a hash function to send the new password.
OK. I suppose I deserved this -- I didn't make the leap from "MD5" to digest access authentication. I've studied up now. Still, as you say, digest authentication won't protect the password modification scenario.
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.
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.
Once again mister barber is being an idiot. netscape is not a "large number of browsers".
This, on the other hand, was both uncalled-for and incorrect. Netscape browsers certainly do account for a large majority of the total browsers. If a solution doesn't work with Netscape, most people would agree that it isn't "useable by a large number of browsers". And, in any case, Netscape is not the only browser to implement SSL. Several other commercial browsers also claim to support SSL and I have even heard that there is a version of Mosaic that uses SSLeay.
He is right that ssl is probably a good way to go. (shttp would be better :) )
SHTTP might be better if it didn't have to be "useable by a large number of browsers" -- since Netscape doesn't support SHTTP. (I'm sorry that you apparently find Netscape's success so frustrating, but it is a fact.) -- Jeff
participants (2)
-
Jeff Barber -
stillson＠ashd.com