A couple of thoughts here. FWIW, I spent 2-1/2 years early in the life of the web writing custom security realms, etc., for use across the web.
First, I thought the HTTP spec dictated when and for what criterion to use what has been dubbed the "preemptive strike" behavior. Don't have it handy to double-check. Typically, the browsers make any first request to a site (server+port) ***in that run of the browser process*** without any credentials. After getting the 401 challenge, supplying the entered credentials, and then getting a subsequent 200, the browser caches them for the duration of that run. Of course the recent browsers are providing an option to store those names and passwords and use them during subsequent browser invocations w/o prompting. Second, and this may be common knowledge by now, but digest authentication isn't necessarily more secure than basic. It certainly prevents you from learning the password, which could be useful if the user happens to visit other sites and uses that password. However, the "digested" password is all the credentials you need to get to the site in question. So sniffing the network can get you that value and you can impersonate that individual with those credentials. It's really unfortunate that a secure, challenge-response authentication mechanism hasn't become standard for HTTP. Five-six years ago, all the hype was about digital certificates and how they were the answers to everyone's prayer. Our security guru was adamant then that they'd never catch on for client authentication, and so far he's been proven right. Waiting for that nirvana has, I'm afraid, prevented the smart folks at W3C or elsewhere from moving us to a ubiquitous standard. FWIW... Donnie > -----Original Message----- > From: Paul C. Bryan [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 17, 2002 9:29 PM > To: Jakarta Commons Developers List > Subject: Re: HttpClient: Basic Authentication & acting more like a > browser > > > Hi Matthew: > > I've noticed this behavior too. The question, in my opinion, is how to > decide when to invoke the "preemptive strike" behavior. You don't know > until a 401 has been returned exactly what realm is required for > authentication for a particular request. > > Storing the URL, as you suggest is overly restrictive, and would > potentially require caching every separate URL that has required > authentication for a particular realm. > > Most browsers appear to send credentials for every subsequent request to > the same host and port. This can be a bit risky in my opinion, as the > user's credentials could be supplied to unrelated services on the > same host. > > Some of this risk is mitigated in browser implementations by the fact > that credentials can be sent using digest. Unfortunately, only basic > authentication is provided in HttpClient so far, causing credentials to > always be sent virtually in plaintext (actually, base64). > > If we decided to implement digest authentication in HttpClient, I'd be > supportive of taking the approach of storing a collection of hosts and > ports with the realm and credentials and send the credentials > unconditionally to the same hosts and ports in subsequent requests. > > If the host doesn't support digest, we'd continue to send with basic. At > least we provided the opportunity to use a more secure authentication > method with that server, so if the credentials are sent to an > undesireable service, too bad. > > My initial idea of Behavior: > > Attempt to find realm by host and port in HttpState (in new host/port > map). Not found. Make request without credentials. Receive 401 response > with realm. Lookup credentials by realm returned with 401. Found. Store > realm for host and port in host/port map. Future attempts to find realm > by host and port will result in the stored realm. > > That's my thinking thus far. Thoughts? Anyone? > > Yours truly, > > Paul C. Bryan <[EMAIL PROTECTED]> > http://pbryan.net/ > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
