An attack vector for DBSC:

[maxhata]

If this topic has already been discussed, please forgive my ignorance.

From what I’ve read about how DBSC works, I believe the following attack vector is possible:

1. Steal a bound cookie, and
2. Hijack the session used for a DBSC transaction.

Exfiltration of cookies is possible through malware. While DBSC may remove the motivation, it does not mitigate the act of stealing themselves.

Once a session is established (possibly after appropriate authentication) following a successful challenge/response, access to bound cookies is enabled as long as the session remains active and the cookies are valid. If a cookie is expired, DBSC allows for cookie recovery if the session is still alive.

Hijacking sessions may not be straightforward, as countermeasures are widely known and deployed. However, it may still not be impossible.

Let’s consider this aspect from the perspective of bound cookies’ lifespan.
Generally, the longer the life of cookies (i.e., the life of DBSC sessions), the higher the risk of sessions to be hijacked. Longer-life bound cookies, such as those lasting 360 days, may be less secure than shorter-lived ones, as they pose a larger risk of session hijacking.

Depending on how seriously you estimate the risk of your sessions to be hijacked, you should be aware of these risks when deploying long-life bound cookies.

Does this view seem reasonable for the security of DBSCs?

[wparad]

Obviously (1) is what DBSC is designed as a countermeasure. But your (2) isn't clear what you mean. Can you expand on how you would expect this to happen?

Hijack the session used for a DBSC transaction.

[maxhata]

Genrally, there are various ways a session can be hijacked. Of course there are various ways to miitigate the risks.
But DBSC does not add anything in particular to prevent its sessions to be hijacked.
So I thought session hijacking is possible as any other systems.
Am I missing anything?

[wparad]

DBSC prevents exfiltrated cookies from having any value, so session hijacking is exactly what DBSC prevents, since the cookies are no longer useble and there will be no way* to exfiltrate the DBSC private keys from the device.

(Note: *, meaning that it wouldn't be any less secure than someone with access to the raw TPM or access to the device's live session where the user actually is using it)

[maxhata]

Cookies themselve are not particularly protected in such a way like encryption, so I thought once attackers take-over the session they can use the stolen cookies. Am I wong?

[wparad]

The proposal is to amend how cookies would be utilized, historically the session cookie would be very long lived and stealing it would mean an attacker could steal the generation of access tokens sourced from the session. Now the session cookie when stolen cannot be used. access token cookies can still be stolen, however if their lifetime is limited then with the session cookies now protected, eliminates many attack vectors.

[maxhata]

Now the session cookie when stolen cannot be used.

Will you elaborate this?

Do you mean,

1. "stolen session cookies cannot be used because of the protection that DBSC provides"?
   If this is the case, I wish to understand why they cannot be. I have been asking this question.

or

2. "There are other mechanisms that prevent using stolen session cookies outside of DBSC"?
   If this is the case, I wish to understand what it is.

[Sora2455]

My understanding of this proposal:

Stolen session cookies can be used, but the server implementing DBSC is supposed to recognise that the DBSC cookie is absent or is not signed with the private key associated with this session's public key. If the DBSC cookie is stolen as well, it expires quickly and cannot be renewed due to the malware not being able to access the private key; after which the server implementing DBSC realises that the session cookie is stolen.

[maxhata]

the DBSC cookie is absent or is not signed with the private key associated with this
session's public key.

The explainer does not say that DBSC cookies are signed by the private keys.
If they were signed it would be easy to understand why :)

[danmarg]

I am not 100% sure I follow this conversation (and sorry for not responding earlier). I think the question is, "How does DBSC actually demotivate stealing the cookies, even though they are managed by a DBSC session?"

It may be easier here for me to first explain the expected security properties and how we achieve them. If my explanation makes sense, please help us clarify the explainer to convey the idea more clearly. If it doesn't, let me know what doesn't make sense. ;)

• DBSC itself doesn't sign cookies, nor does it prevent cookies from being stolen
• DBSC instead provides a mechanism to do two specific things: 1) for a browser to provide proof of possession of a (non-exportable) private key, and b) for a browser to know it has to go talk to a specific "refresh" endpoint when one or more cookies are missing/expired

That's actually it. That's the spec. :) But, what does it get us?

In a nutshell, it gets us the ability to make cookies short-lived, knowing that the browser will refresh them if expired, and only refresh cookies if the browser has proof of a non-exportable private key.

So to what I think is the question in this thread, the cookies themselves are indeed stealable, but that window of vulnerability only exists as long as the cookies are valid. DBSC assumes that servers will limit the lifetime of cookies to something quite short (a few minutes, say) in order to reduce that window of vulnerability.

Is my explanation helpful?