basic auth request

[Peter J. Holzer]

On 2021-08-22 19:37:24 +1000, Chris Angelico wrote:
> On Sun, Aug 22, 2021 at 6:45 PM Peter J. Holzer <hjp-python at hjp.at> wrote:
> >
> > On 2021-08-22 05:04:43 +1000, Chris Angelico wrote:
> > > On Sun, Aug 22, 2021 at 4:55 AM Martin Di Paola
> > > <martinp.dipaola at gmail.com> wrote:
> > > > HTTPS ensures encryption so the content, including the Basic Auth
> > > > username and password, is secret for any external observer.
> > > >
> > > > But it is *not* secret for the receiver (the server): if it was
> > > > compromised an adversary will have access to your password. It is much
> > > > easier to print a captured password than cracking the hashes.
> > > >
> > > > Other authentication mechanisms exist, like OAuth, which are more
> > > > "secure".
> >
> > OAuth is "an /authorization protocol/, rather than an /authentication
> > protocol/" [Wikipedia].
> >
> > > If your server is compromised in that way, *all is lost*.
> >
> > If "you" are the service provider, yes. but if "you" are the user, no.
> 
> If "your server" is compromised, then you are the service provider,
> are you not? I'm not sure what "your server" would mean if "you" are
> the user.

The server you use. The same way you talk about "your bank" or "your
school" etc. 

But that's besides the point. What I wanted to point out is that as a
service provider you take some responsibility for the user's data and
should take the user's POV into account.

> > there are three levels of security (from highest
> > to lowest) in this scenario:
> >
> > 1: The secret known to the user is never transmitted to the server at
> >    all, the client only proves that the secret is known. This is the
> >    case for TLS client authentication (which AFAIK all browsers support
> >    but is a real pain in the ass to set up, so it's basically never
> >    used) and for SCRAM (which isn't part of HTTP(S) but could be
> >    implemented in JavaScript).
> 
> This would be great, if nobody minded (a) setting up a unique client
> certificate for every site, or (b) allowing the ultimate in remote
> tracking cookie whereby any server could recognize you by your TLS
> certificate.

Which is one of reasons why TLS client authentication wasn't really
practical. It doesn't apply to SCRAM.

> > So given the choice between Basic Auth and Digest or NTLM (over HTTPS in
> > all cases) I would prefer Basic Auth. Ideally I would use SCRAM or a
> > public key method, but I admit that my security requirements were never
> > high enough to actually bother to do that (actually, I used SSL client
> > side auth once, 20 years ago, ...).
> >
> 
> I would, of course, prefer something like form fill-out over Basic,
> but that's due to UI concerns rather than security ones.

Me too. But since that is irrelevant from a security POV I chose not to
complicate matters by bringing that up.

> When it comes to security, one thing I'm very curious about is why we
> don't have any sort of certificate renewal verification. My browser
> could retain the certificates of some web site (or of all web sites,
> even - they're not THAT large), and if the site presents a different
> cert, it could show the previously retained one and challenge the
> server "prove that you're the same guy". This proof would consist of
> the latest cert, signed by the older cert's key (or possibly a chain
> that can construct such a proof, which would allow the server to
> simply retain each new cert signed by the one previous cert, forming a
> line - or a tree if necessary).

I think this wasn't done because it violated the strictly hierarchical
model of X.509, where CAs are fully trusted and the server operators
aren't trusted at all. Letting them add signatures smacked too much of
an egalitarian web of trust.

Of course, technically, these days website certificates do form a web of
trust (with multiple chains and CA cross-signing), but the mental model
is still the same (and web site keys cannot be used for signing).

Apart from that I can see two problems: The first is that if the private
key is compromised, an attacker can use it to sign their own successor
key. The second is that if the private key is lost, a successor key
cannot be signed. So the absence or presence of such a signature is just
corroborating evidence, not proof.

        hp

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp at hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://mail.python.org/pipermail/python-list/attachments/20210825/6374cc4c/attachment.sig>