basic auth request

[Peter J. Holzer]

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:
> >
> > While it is correct to say that Basic Auth without HTTPS is absolutely
> > insecure, using Basic Auth *and* HTTPS is not secure either.
> >
> > Well, the definition of "secure" depends of your threat model.
> 
> Yes. Which makes statements like "not secure" rather suspect :)

Right.


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

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

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.

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.

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

        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/20210822/486612c8/attachment.sig>