7

I have a development copy of an ASP.NET intranet site checked out and running on my local machine. We're using digest authentication to allow users to log in using their active directory accounts.

On my development copy only, Digest sometimes will repeatedly prompt for login information usually ~9 times per page request. After repeatedly logging in (or it also works to cancel out of 8 out of the 9 prompts), I can use the site as normal.

I cannot pinpoint what is triggering the issue. Sometimes this problem triggers upon the next page request, sometimes after I edited/saved/refreshed a page, and sometimes it doesn't happen at all.

Each prompt triggers several logon (Event ID 4624 & 4672) security events in the Events Viewer. Shortly after each burst of logon events, I'll see a burst of logoff events (Event ID 4634)

A co-worker who has a nearly an identical setup (Windows 7, IIS 7) is not experiencing the issue. Our production copy (that is running on a different server) also does not experience the issue. We've tried to compare our settings in IIS, not really finding any differences.

I'm using chrome but I've experienced the issue in other browsers.

3 Answers 3

2

The question is 11 years old, but still not solved.

The actual problem is wrong MD5-sess implementation in Chrome and Firefox. The only correct implementation can be found in (already abandoned) IE.

IIS is the only popular web server with support for MD5-sess and MD5-sess is always used with recent IIS versions if Digest Authentication is enabled.

According to RFC 2617 (and RFC 7616) the first part of hash code (H(A1)) for MD5-sess must be calculated with the server nonce and the first client cnonce. The H(A1) should not be changed until new server nonce is received, even if client uses another cnonce.

According to Chrome and Firefox source code, browsers ignore this requirement and always recalculate H(A1) with new cnonce. As the result, the first request with the first cnonce is valid and accepted by IIS, but the second and following requests with the same nonce and different cnonce have invalid response hash and rejected by IIS. This force browsers to request the username and password again for every element located on URL with Digest Authorization. As soon as all elements on the page become cached, browser stops asking for password re-enter.

The more info is here.

Looks like IIS with Digest Auth is used very unfrequently and this is why this problem is not noticed (and not fixed) for years.

MS Edge is based on Chromium code and has the same problem.

3
  • ` IIS with Digest Auth is used very unfrequently`. I would say never. Digest authentication is a critical security risk and most organizations disabled it years ago. It's a dead technology. "This update prevents every Microsoft SSP in LSASS, besides WDigest, from storing the user’s clear-text password.” WDigest stores passwords in clear text in LSASS and the only way to prevent this is to disable WDigest." techcommunity.microsoft.com/t5/core-infrastructure-and-security/…
    – Greg Askew
    Oct 5, 2022 at 16:33
  • The mentioned problems are problems in MS's implementation of Digest Auth. Digest Auth allow storing hashed passwords (with different hashes for every realm). SHA-256 is allowed as an alternative to insecure MD5. While Microsoft's implementation WDigest is problematic and has security problems, Digest Auth is still usable in general. This question has been asked originally 11 years ago, when WDigest was used more frequently.
    – Karlson2k
    Oct 6, 2022 at 9:10
  • 1
    In my experience Digest was not used frequently in areas where TLS certificates are pervasive. And this isn't really an issue with Microsoft's implementation, because Microsoft essentially end-of-lifed the technology when they recommended disabling it. The key takeaway is in a Microsoft environment this is a critical security risk.This has been discussed on Security Stack Exchange. security.stackexchange.com/questions/152935/…
    – Greg Askew
    Oct 6, 2022 at 11:03
1

If this app is for internal use only I would recommend using integrated auth rather then digest. For apps without built in web-form auth like yours, 99% are integrated (AD auth pass through) or basic auth over SSL.

Also, Digest doesn't always work with AD and depends on settings in AD and in each user. Google things like "digest auth active directory" or "digest reversible encryption" so see the issues people have with it.

Other things to look at are NTFS permissions on files/folders, and if anonymous is enabled (it shouldn't be).

0

Do you have a (caching/non-caching) web proxy between your machine and the server ? I saw the same problem with Sharepoint authentication, the solution we took was to get rid of the ISA Firewall/Proxy through a rule allowing clients to bypass it for the Sharepoint site. That solved the problem but we didn't investigate the root cause.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .