IE, Apache Clash on Web Standard

sbsea1 writes "Here is another instance where Microsoft is going one way and everybody else going to other. eWEEK Labs found that Microsoft is using a different implentation of digest authentication which differs from the W3C's digest authentication standards. Internet Explorer Version 5.0 and higher--as well as Microsoft's IIS Web server--has a significant security incompatibility with other major Web browsers and with the Apache Software Foundation's Apache HTTP Web server."

Comments

doesnt look that bad...

[jeffy124]

the article says that even MS spokespeople are admitting that it's a bug. I dont see it as anything to get all up in arms and angry about.

Re:People, please read the article

[aminorex]

This is a bizarre interpretation. MS introduces
an incompatible extension to a standardized
protocol (as usual) and then when someone doesn't
implement that proprietary extension, you fault
them for it? I think you are using the word
"fault" in some new monkeyboy sense.

As is so very typical of Microsoft's "innovation",
it is the pitiable consumers of MS software who
suffer, and nobody gains except MS. Because of the
prevalence of IE on corp desktops (declining, yes,
but still a substantial prevalence), they can
use this as an opportunity to push IIS, which
implements the proprietary version of digest
authentication compatibly with IE.

Re:It's not a clash it's a discussion ;)

[software_non_olet]

I agree, IE is the de-facto standard for browsers.

Hence it breaks down to standard browser against standard server.

But there is no need to give up too early from Apache's side. The function is not in wide use yet and will not in the near future IMO. If a web apllication needs authenticication, it will probably also need encryption of the data somewhere down the menu-tree (if only to change the password). Allthough SSL has a higher price-tag (in dollars or cpu-cycles), it also has the advantage of being supported by practically all browsers.

Time for discussions - not for early give-ins.

Re:Clash on web standard?

[Jon Peterson]

Hey, that works both ways!!

Obviously the Apache Group did not do compatibility testing with the most popular browser on the net, either. Both sides (or, IMHO, none) are at fault on this.

The fact is, this is a new standard that practically no-one is using in anger at the moment. Look at all the other incompatible implementations there have been of new RFCs. It happens all the time, not just with MS.

This is a complete non-issue. "Today, a very early adopter of a new technology notified two software companies that they'd chosen incompatible interpretations of spec. The two companies agreed to make their implementation compatible in future."

Yeah, big story.

who cares about digest authentication anyway?

[phr2]

Sending the digest in the clear still makes most user passwords vulnerable to offline dictionary search. Digest authentication was a kludge on top of HTTP basic authentication (which sends the naked password in the clear) designed at a time when SSL was scary and complicated and there were no free SSL web servers.

These days, for casual passwords like /. logins, HTTP basic authentication is still usually good enough. For passwords that need real security, use mod_ssl instead, which is easily added to Apache 1.3 and comes with Apache 2.0 by default, and do basic auth over SSL so the whole HTTP stream is encrypted including the password. HTTP digest authentication's security is sort of halfway between HTTP basic auth and HTTPS basic auth. As a halfway measure, it's not really that useful any more.

Re:who cares about digest authentication anyway?

[Zeinfeld]

Digest authentication was a kludge on top of HTTP basic authentication (which sends the naked password in the clear) designed at a time when SSL was scary and complicated and there were no free SSL web servers.

SSL did not exist when I invented the Digest mechanism. The problem was the patent on RSA and Diffie Helleman.

Digest was invented for one reason and one reason alone which was to provide a replacement for BASIC and avoid sending password in the clear.

Microsoft implemented Digest first, but Netscape refused. This was before they hired a credible security person. They believed that sending passwords over the internet en-clair was a less important security issue than protecting the authentication information in the Web server storage.

Microsoft removed Digest from IE in IE4 as Netscape refused to implement. Then the IETF stated that HTTP could not become a standard if it sent passwords en-clair at which point people pulled the draft out again.

Removing Digest from IE was not a big issue for me since if only Microsoft was going to implement the standard they might as well use the NT password authentication scheme.

The dictionary attack issue is important, but it was not possible to address it given the state of the IPR at the time. If Diffie Helleman had been available I would have designed the protocol entirely differently. It would have been possible to address security of the auth data on the wire and in storage.

For passwords that need real security, use mod_ssl [modssl.org] instead, which is easily added to Apache 1.3 and comes with Apache 2.0 by default, and do basic auth over SSL so the whole HTTP stream is encrypted including the password. HTTP digest authentication's security is sort of halfway between HTTP basic auth and HTTPS basic auth.

Actually I would recomend Digest over HTTPS. The problem with BASIC is that you have to trust the end point, that is fine if the application is such that the application justifies buying a certificate or securely distributing the point of trust.

More generally however I would suggest people look at our more recent work in SAML (security services at www.oasis-open.org)

Re:Digest vs HTTPS

[Zeinfeld]

One of the main design issues for DIGEST was to eliminate BASIC from the spec entirely. There is no place for a spec that sends passwords en-clair.

The problem is that most people, myself included share passwords across uses. I have something like 200 active authentication points, there is simply no way that I could remember 200 separate passwords if I tried. I have three passwords that I use for high medium and low security. But most people happily share their corposrate password with their WareZ site password.

Although passwords inevitably involve a certain degree of information sharing, DIGEST is dfesigned to ensure that this is minimized. If you give a password to a site and the site is compromised the information stored in their database does not compromise any other site.

The main problem with mechanisms such as SRP is that they are all aledgedly encumbered. The patents are also fairly new.