Subject: WWW-Authenticate proposal: timeout flag

From: "Soni L." <[email-masked]>
Date: Thu, 29 Apr 2021 17:24:54 -0300

We'd like to be able to specify a timeout value for WWW-Authenticate, in
particular `timeout=0` so the HTTP authentication can be converted into
session cookies rather than sending the password in plaintext (sure, it
gets sent over TLS, but that doesn't matter) on every request. Would
anyone be interested in such proposal?

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 29 Apr 2021 22:42:09 +0200 (CEST)

On Thu, 29 Apr 2021, Soni L. wrote:

> session cookies rather than sending the password in plaintext (sure, it gets 
> sent over TLS, but that doesn't matter) on every request. Would anyone be 
> interested in such proposal?

What should happen when the time runs out? Is that just an ask to the client 
that it should drop the auth status at that point?

I don't think this is enough to make people stop using cookies for logged in 
session status even if you would get someone to adopt.

-- 

  / daniel.haxx.se

---

From: "Soni L." <[email-masked]>
Date: Thu, 29 Apr 2021 17:50:53 -0300

On 2021-04-29 5:42 p.m., Daniel Stenberg wrote:
>> We'd like to be able to specify a timeout value for WWW-Authenticate,
>> in particular `timeout=0` so the HTTP authentication can be converted
>> into session cookies rather than sending the password in plaintext
>> (sure, it gets sent over TLS, but that doesn't matter) on every
>> request. Would anyone be interested in such proposal?
>
> What should happen when the time runs out? Is that just an ask to the
> client that it should drop the auth status at that point?
>
> I don't think this is enough to make people stop using cookies for
> logged in session status even if you would get someone to adopt.
>

It's to stop using forms, not cookies. Cookies are more secure because
they don't keep re-sending the password such that a malicious or
compromised server could exfiltrate the plaintext. Using cookies for
logged in session status is a good thing.

---

From: Rafal Pietrak <[email-masked]>
Date: Fri, 30 Apr 2021 13:33:06 +0200

Hi everyone,

> logged in session status is a good thing.

Still, cookies have their problems.

Would somebody be so kind and have a look at my proposal regarding
cookies at: https://datatracker.ietf.org/doc/draft-pietrak-cookie-scope/

... and naturally give it a comment or two :)

Best regards,

-R
-- 
Rafał Pietrak

---

From: Daniel Veditz <[email-masked]>
Date: Fri, 30 Apr 2021 09:00:48 -0700

One thing that jumped out at me was the Viewport visibility overriding the
specified Domain. Don't do that! Either make setting a too-broad domain an
error and reject the cookie (as we did with __Host- prefixed cookies), or
accept that the server knows what it's doing and honor the domain. If, as a
web author, you restrict cookies to a viewport you still might have all
kinds of sub-resource requests from sibling origins in the same domain. Why
break that?

It's the "Secure" attribute, not "SecureOnly"

4 different visibility levels sounds like a PITA to implement, or even
define. If a site is using "Tabs" visibility and they do a
window.open(<same-origin>), does it have the same cookies or not? That used
to be a popup, so new window == no cookies. In the last decade or so
browsers (only one kind of user agent) have converged on having that be a
new tab in the same window (has cookies). If the author specifies size
attributes then it's back to a separate window (no cookies). But that's not
part of the HTML specifications, it's just conventions that User Agents
have adopted. It would be better to define a cookie spec based on concepts
that are specified somewhere and aren't just conventions. You need to come
up with some compelling reasons for why each of the levels is necessary and
when it would be useful.

Please restrict this to "session" cookies (no set expiration time). I don't
know how I'd store a "Viewport" cookie (on disk, between browser runs if it
has a long expiration) that makes sense after you close that one viewport.
Or tab, or window.

Would your use-cases be served by the HTML "sessionStorage" feature? It's
not sent in HTTP requests so it's definitely not the same, but that is
explicitly scoped to the current document and not shared with other
documents of the same origin (similar to your Viewport, but excludes
same-origin frames).

-Dan Veditz

---

From: Rafal Pietrak <[email-masked]>
Date: Fri, 30 Apr 2021 20:12:27 +0200

Hell,

Thank your for the review.

Before I'd address your comments, I'd say, that:

1. I'm opened to any suggestions and I'd like to forge the proposal as
useful (for the purpose intended) and possible - even when a complete
rewrite would be necessary.

2. The intention is to allow for multiple security www contexts being
available for a user at his/her web-browser. .... and that not at the
URL level.

W dniu 30.04.2021 o 18:00, Daniel Veditz pisze:
> One thing that jumped out at me was the Viewport visibility overriding
> the specified Domain. Don't do that! Either make setting a too-broad

OK.

As you can imagine, my intention was to close any possible leakage of
cooqies with security tokens.

But, would you think that stating that: "any Viewport element with
'domain' different then domain of the cookie with radius attribute set
MUST by omitted from 'fetch-list'"? (the "fetch-list" to be defined as
all the "remote" elements of document in viewport).

> domain an error and reject the cookie (as we did with __Host- prefixed
> cookies), or accept that the server knows what it's doing and honor the
> domain. If, as a web author, you restrict cookies to a viewport you
> still might have all kinds of sub-resource requests from sibling origins
> in the same domain. Why break that?

I don't think my proposal would break anything. I think, that a web
author, with *new* tool to setup a security-session of his/her web-page
can conform to any well defined standard.

On the other hand, I tried to think of any way, the new attribute could
possibly break current services, and I think I've eliminated all of
them. If not I'd prefer to modify the proposal around the other
(WORLD/WINDOW) values to have them guarantee undisturbed work in today's
use scenario.

So, I'd rather opt for the requirement, that all who'd like to use the
new attribute for session logging SHOULD restrict all subresources to
the domain of the session cookie with viewport radius. ... then loosen
constraints and exorcise some unforeseen security holes.

Naturally, I may be too cautious. May be this requires some more examples??

> It's the "Secure" attribute, not "SecureOnly"

Right. :)

> define. If a site is using "Tabs" visibility and they do a

I think, inclusion of examples in the document could clearify the specs.
I will do that in next revision.

> window.open(<same-origin>), does it have the same cookies or not? That

window.open(same_origin) should work (with current proposal). It goes
into the same origin as defined in cookie in question, so cookie should
be delivered to the server as expected, and all should work be fine.

> used to be a popup, so new window == no cookies. In the last decade o> so browsers (only one kind of user agent) have converged on having that
> be a new tab in the same window (has cookies). If the author specifies
> size attributes then it's back to a separate window (no cookies). But

I this case my intention would be to popup the window *without* viewport
cookie. Consequently, popups wouldn't work with "tight cookie security".
For a web designer, there are two workarounds:
1. put credentials into URL of the popup.
2. use modal-pane within the original viewport.

Both workarounds are "simple", and I believe cover vast majority of use
cases.

> that's not part of the HTML specifications, it's just conventions that
> User Agents have adopted. It would be better to define a cookie spec
> based on concepts that are specified somewhere and aren't just
> conventions. You need to come up with some compelling reasons for why
> each of the levels is necessary and when it would be useful.

OK. I'll do the in next release.

> 
> Please restrict this to "session" cookies (no set expiration time). I
> don't know how I'd store a "Viewport" cookie (on disk, between browser
> runs if it has a long expiration) that makes sense after you close that
> one viewport. Or tab, or window.

OK. Very good point, I didn't thought of that.

> 
> Would your use-cases be served by the HTML "sessionStorage" feature?
> It's not sent in HTTP requests so it's definitely not the same, but that
> is explicitly scoped to the current document and not shared with other

No, it wouldn't. The goal is to replace "security-tokens" today
maintained within URL of the page. That (current - to be obsoleted)
method allows for web-links (the "a href=") on such page to be correctly
executed by browsers even without JavaScript. This is very desirable.

On the other hand, security Tokens kept in sessionStore have to be
retrieved, and put into the GET headers by a script. This is
undesirable. Security cookies would most likely be httpOnly, and in such
case that would be just impossible.

I hope this explanation make sense. But pls comment if you don't agree.

BR

-Rafał

> 
> -Dan Veditz
> 
> On Fri, Apr 30, 2021 at 4:37 AM Rafal Pietrak <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi everyone,
> 
>     cookies at:
>     https://datatracker.ietf.org/doc/draft-pietrak-cookie-scope/
>     <https://datatracker.ietf.org/doc/draft-pietrak-cookie-scope/>
> 

-- 
Rafał Pietrak

---

From: Rafal Pietrak <[email-masked]>
Date: Fri, 30 Apr 2021 22:45:31 +0200

> Hell,

Tsss...

I mean HELLO.

-- 
Rafał Pietrak