- From: Henrik Nordström <henrik@henriknordstrom.net>
- Date: Thu, 01 Mar 2012 01:54:08 +0100
- To: Adrien de Croy <adrien@qbik.com>
- Cc: ietf-http-wg@w3.org
tor 2012-03-01 klockan 13:07 +1300 skrev Adrien de Croy: > I'm not 100% convinced. Esp with auth. Even disregarding NTLM, any > time you have a challenge and response, if the response comes to a > server over a different TCP connection, then I think a lot of > implementations will break. Maybe therefore they are poorly designed. We do have a bit of this problem with digest auth. If the servers do not have syncronized nonce stores then digest performance degrades considerably if the client switches server. > Maybe if assuming 1 connection = 1 user is broken, it should be > explicitly warned about in the spec. That assumption is utterly broken. Has always been since HTTP/1.0 added keep-alive. Not even 100% safe to assume that for https:// these days. > The alternative though is either > the server has to challenge every request, or the auth tokens submitted > by clients can be used without round-trips, or some other token needs to > be stored and looked up by the server in global (i.e. > non-connection-oriented) memory. Basic fits there, but does Digest? > NTLM certainly doesn't of course. basic auth is completely stateless on the server side, by nature of transmitting plaintext login:password in each request. digest auth requires servers to keep shared state of issued server nonces to perform well. If not then each time the client lands at a different server the server will issue a new nonce and the client automatically retry the request until the client manages to hit the same server twice in a row. keep-alive helps mitigating this a lot but not fully. NTLM is.. well NTLM. Does not fit into anything HTTP terms. > > Are you talking of transparent intercepting proxies doing NTLM here? If > > you do then please stop, that's just happens to work because the > > security model of NTLM is plain broken broken allowing it to be abused > > in mitm attacks in completely insecure manners. end of discussion. > > actually any sort of auth when you intercept you no longer know who the > target is. You can't do any standard HTTP auth (basic or digest) in intercepting mode and still have happy users. > > Please let NTLM die a painful death. > > It's going to be a very long death. It's just not going away. I think > we will still see significant use of it in 10 years from now. I hope not. Most should be switching to Kerberos via Negotiate now. And you can't do the transparent intercepting proxy auth trick with kerberos. > I'm not even sure how to implement Digest on windows (I've only briefly > looked), but it looks quite difficult. It's not very difficult. But you need to enable it in the domain controller and reset the password on every account that needs to use digest auth, and also enable it in IIS obviously. In theory Windows should even be able to do automatic single sign on with Digest auth just as it does for NTLM/Kerberos, but I do not think that's implemented. Never investigated it in detail. > Even Negotiate is still connection-oriented? Yes, it's the same breakage HTTP wise as NTLM, but at least a reasonably secure auth protocol as such if ignoring the mess it does to HTTP. > So basically the answer remain: "use Digest". Yes. Digest is the best we currently have in HTTP with some sanity preserved. Regards Henrik
Received on Thursday, 1 March 2012 00:54:38 UTC