Related to Issue ID 72589 and 5497 ? We are also looking for a way to invalidate the http auth credentials when receiving a 401 HTTP with previously entered valid credentials on first 401 HTTP.

harishreddyg -- Can you describe how this is a security risk, rather than just a user-experience bug?


asanka -- Who on network team should look at this?

nparker - Didn't knew about the classification at your end it may be a different category bug. 

As chrome is storing the Security Auth headers, on second timeout HTTP 401 is fired and gives the pop-up. As this request is already having the security auth headers from the first timeout challenge, just clicking cancel/refresh will re-authenticate user. It's a security issue and doesn't happen on IE.


Can refer to the attachment containing HTTP traces and actual fiddler log. please let us know if you are looking any information.

Can you please assign it to right member. Appreciate your help in this regards. 

Yeah. That would be me. I'll have a look shortly.

I'm marking this as Low severity because IIUC the browser is sending credentials to the server that were already sent in the first request, so I think the security risk is fairly small. Please let me know if I'm misunderstanding.

Thanks Asanka!

est..@chromium.org - Correct, browser is sending credentials to server even on click of cancel/cross on second timeout unauth 401 pop-up

When the business user leave the system idle for the second time, any passing by user can click cancel/cross mark to get re-authenticated. It's high-security risk atleast for us. 

Bt keeping view of this Chrome's default functionality, you can make it security_sev to Medium to work this further. 

Appreciate your help.

Sorry about the delay. Could you send me a net-internals log as described in https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details ?

I'd like to see what requests are being issued and the outcome of each.

asanka - captured and attached the net-internals as requested.

Followed replication steps 

1. Logged in to my application
2. Started Chrome net-internals event capturing.
3. Waited for 30+ seconds timeout to get HTTP 401 Auth pop-up
4. Provided valid credentials.
5. Waited again for 30+ seconds for second timeout to get HTTP 401 Auth pop-up.
6. Now, I didn't provide any credentials. Just clicked on cancel button.
7. I am able to re-authenticate and access the application 
8. Stopped Chrome net-internals event capturing.

Deleted: net-internals-log_Issue 619445.json 5.4 MB

net-internals-log_Issue 619445.json 5.4 MB View Download

Part of the problem is that the server is switching realms between authentication challenges.

Chrome supports sending pre-emptive authentication headers as described in RFC 7617 Section 2.2. However, the semantics for invalidating credentials where the rejection is accompanied by a realm change is less clear. If the server rejects pre-emptive authentication with a challenge from a different realm, Chrome elects to keep the older credentials around until new credentials are available for the new realm.

In your case, since no new credentials are available, a subsequent request within the same protection space will use the older cached credentials again. This behavior is spec compliant.

If your intention is to invalidate the previous set of credentials, then consider using the same realm for subsequent challenges. That is an unambiguous signal that the older credentials should no longer be used.

Sending credentials that were known to be valid to the same server while accessing the same path during the same browsing session is not a security vulnerability. That's something specifically allowed and encouraged for some schemes where it's dependent upon to reduce the number of roundtrips used for accessing authenticated resources.

Asanka - Thanks for your analysis and sharing the RFC details.

We have few questions in here.

1. Chrome will not send pre-emptive authentication headers if we have the same realm for subsequent challenges ?


2. If yes, can you please explain/help us on how to prevent realm change at server level on this use-case? (we are completely unaware of realms part, it would be great if you share some info) 


3. This doesn't occur on IE, does it mean that most likely IE don't support/adhere RFC 7617 section 2.2?


We will look for your response. 

#11:

1. If Chrome sends pre-emptive authentication headers to a server, and the server responds with a 401 challenge using the same realm, then Chrome assumes that the credentials supplied were incorrect. If the realm is different, then Chrome can't come to the same conclusion, so it retains the previous set of credentials.

   If you would like Chrome to discard an older set of credentials, then you can respond with a challenge using the same realm. If the user doesn't respond to the challenge, then Chrome won't use pre-emptive authentication for that protection scope (server + path) since it no longer has a valid set of credentials.

2. Can't help with server configuration. Sorry. I don't know of any server that by default changes the realm every now and then like yours is doing.

3. RFC 7617 Section 2.2 allows a UA to send a pre-emptive authorization header. It doesn't require it, and doesn't clearly define the behavior following a challenge that uses a different realm. Since the credentials are associated with a protection space (defined by the realm), a challenge for a new realm doesn't invalidate the credentials for the previous realm.

   IE and Chrome differ in that once a challenge is received for a different realm for the same authentication scope, IE seems to assume that the older protection space is no longer valid, while Chrome doesn't. There's no spec violation as far as I know since the spec doesn't define what should happen in this case.

Thanks for the explanation. Can you please change the category of this issue  so that I can share this link with my stakeholders containing the analysis. 

Just wanted to make it visible so that I can share this item details.

Appreciate your help.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot