basic auth request

[Chris Angelico]

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.

But okay. Suppose I log in to Random Service 1, using a user name and
password, and also to Random Service 2, using OAuth. What happens if
those servers get compromised?

1) Someone knows the login credentials that I created for that
service. If I've used the same password that I also use at my bank,
then I am in big trouble. It is, largely, my fault.

2) Someone has access to my login token and the client ID/secret
associated with it. That attacker can now impersonate me to the OAuth
provider, to the exact extent that the scopes permit. At absolute
least, the attacker gets to know a lot about who I am on some entirely
separate service.

I'm talking here about a complete and utter compromise, the sort where
neither SSL encryption nor proper password hashing would protect my
details, since that's what was being claimed.

Which is actually worse? Is it as clear-cut?

> From a user's perspective "all" is much more than the data (including
> username and password) associated with that particular service. So if
> one service is compromised, not all is lost, but only a bit (of course,
> depending on the importance of the service, that bit may be little or
> big; a random web forum probably doesn't matter. Your bank account
> probably does).
>
> So assuming that many people reuse passwords (which of course they
> shouldn't and thanks to password is becoming rarer, but is still
> distressingly common),

True, but reuse of passwords is something under the user's control.
OAuth scope selection is partly under the service's control, and
partly under the provider's (some providers have extremely coarse
scopes, widening the attack).

> 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.

> 2: The secret is transmitted on login but never stored. This limits the
>    damage to users who logged in while the server was compromised. This
>    is the case for Basic Authentication combined with a probperly salted
>    hashed storage.

Current best prac, and what I'd generally recommend to most people.

> 3: The secret is stored on the server. When the server is compromised,
>    all user's passwords are known. This is (AFAIK) the case for Digest
>    and NTLM.

I'm not sure what the effects of wide-spread Digest/NTLM usage would
have on password managers and the risks of compromise to them, but the
way things currently are, I would prefer salted/hashed passwords, such
that a data breach doesn't mean compromise of all historical data.

> 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.

SCRAM seems tempting, but in a context of web browsers, I'm not sure
that it would be worth the hassle.

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). My suspicion is that it'd add little
above simply having a valid cert, but if people are paranoid, surely
that's a better place to look?

ChrisA