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:doesnt look that bad...

[questionlp]

Blockquoth the poster:

I dont see it as anything to get all up in arms and angry about.

Remember, this is /. If it's about Microsoft and it goes against anything open or standard, then everyone will get pissy. If it were Netscape or Opera, then it will be passed of as a fluke.

Re:doesnt look that bad...

[jeffy124]

oh i'm definitely aware of the anti-microsofties there are at /. I just think it's good to point out to those that skip straight to the comments that MS is taking it seriously and not trying to change the embrace/extend yet another standard like they have in the past, which was implied by the original poster: Here is another instance where Microsoft is going one way and everybody else going to other

Re:doesnt look that bad...

[einhverfr]

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.

I am running Windows 3.1 beta on DR-DOS and I keep getting this "Non-fatal error" message. If Microsoft would only stop writing buggy software ;)

People, please read the article

[PhysicsGenius]

I hate Microsoft as much as the next Slashbot, but let's get the facts before we post frontpage Slashrants. It says, and I quote:

We [microsoft] were told by the Apache group that it would support multiple digest protocols. The MS Digestion protocol just hasn't been implemented by Apache yet.

In other words, like the libXML problem we all remember from last year, this is Apache's fault.

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.

A bug? I think not...

[Mr. Muse]

...MS spokespeople are admitting that it's a bug...

This incompatibility has been in place for about 2 years in IE, and is also built-in to IIS. That is not an oversite. That is yet another example of a company trying to pick and choose which standards they can disregard with impunity.

Make no mistake, Microsoft aren't going to willingly "comply" with any technology or standard that facilitates fair competition.

Differences in computing the message digest?

[cpeterso]

Does anyone have any real information about the actual differences between how Microsoft and Apache are computing the message digest? The article does not say much. I know the Microsoft and Netscape used to have some interop problems because one implemenation (Netscape's, I think) would include a string's NUL terminator when computing a message digest. This would obviusly lead to a different result. :)

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)

Digest vs HTTPS

[phr2]

Thanks for the response, and I'm not saying Digest was badly designed. It was a reasonable response to the situation that existed at the time it was first proposed. It's just that the current situation isn't like that--SSL is easily available now.

I don't understand "The problem with BASIC is you have to trust the end point", unless you mean you have to give them a password that you might also be using on other sites. Of course by even giving them the digest of the password, you let them mount an offline dictionary search. That means that the site also needs to keep the digest secret from attackers who might also want to do searches, so again you have to trust the site's security.

I agree with Netscape that unencrypted BASIC is good enough for a lot of purposes (how bad is it if someone intercepts your Slashdot password and changes your user preferences?). Applications that need more security (online banking) need enough design attention that buying a certificate ($125/year) isn't that big a deal. Low traffic sites can always use self-signed certificates which cost nothing (but pop a browser dialog when the user first connects). Really high security applications should use SSL client certificates instead of passwords. That avoids the need for any shared secrets. If you really want to use passwords over an unencrypted channel, it's best to use a protocol like SRP, though like SSL, SRP would have been a problem before the DH patent expired.

Yes, if you look at the spectrum of all possible web applications, there's probably some examples where Digest is slightly preferable to the next best alternative, but with SSL easily available Digest just doesn't seem like a big deal any more.

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.

Re:Digest vs HTTPS

[phr2]

I'd thought that SRP wasn't patented, and the whole purpose of its development was to get around the EKE/SPEKE patents. If it's encumbered by different patents instead, well, thanks a lot dude :-(. But its license says it's unencumbered, and "What is SRP?" amplifies:

SRP is available to commercial and non-commercial users under a royalty-free license. The Internet played a significant role in SRP's early development; without it, SRP would not have received anywhere near the amount of analysis and feedback that it has gotten since it was first proposed and refined. It is thus fitting that the Internet at large can benefit from the fruits of this endeavor. Since SRP also works around existing patents in the area, it gives everybody access to strong, unencumbered password authentication technology that can be put to a wide variety of uses.

It's really isn't feasible to get rid of BASIC once BASIC is in a lot of browsers. It's not enough to get it out of the spec; it has to be removed from both browser and server implementations, and that won't happen. Browsers will keep it to interoperate with old servers and servers will keep it to interoperate with old browsers. So we're stuck with it forever. It's unfortunate that it was put into the spec in the first place instead of using something like Digest.

Re:Digest vs HTTPS

[Zeinfeld]

I'd thought that SRP wasn't patented, and the whole purpose of its development was to get around the EKE/SPEKE patents. If it's encumbered by different patents instead, well, thanks a lot dude :-(.

One of the bastards that owns one of the other patents sent a patent troll letter to the IETF.

It's really isn't feasible to get rid of BASIC once BASIC is in a lot of browsers.

It wasn't when I wrote the spec, a week after they did BASIC. What happened was that they told me they were using RSA, then they found the patent issues were going to be too much of a problem and they did BASIC without actually mentioning the change of plan to me.

The problem was that the people writing the code knew enough about security to be dangerous, but not enough to be useful. They had heard the UNIX encrypted password file argument and were applying to an inappropriate context. It was cargo cult security, slogans not thought.

Re:its beta!

[einhverfr]

Actually, it was a reference to the infamous AARD code which was probably intended to intimidate customers into avoiding the rival DR-DOS. This was one of the major pieces of evidence in Caldera vs. Microsoft. Do some research on that-- you may be surprised at what you see.

No, I do not runn Windows 3.1 nor do I run DR DOS.