Re: [hackers] [quark] Thoughts on CGI and authentication?

From: José Miguel Sánchez García <soy.jmi2k_AT_gmail.com>
Date: Fri, 23 Oct 2020 17:10:37 +0200

On 10/23/2020 2:08 PM, Laslo Hunhold wrote:

Dear Laslo,

> as RFC 7617 (Basic Authentication Scheme) states:
>
> This scheme is not considered to be a secure method of user
> authentication unless used in conjunction with some external secure
> system such as TLS (Transport Layer Security, [RFC5246]), as the
> user-id and password are passed over the network as cleartext.
>
> So yeah, it would only "really" work on an encrypted connection.
> However, when the data you want to protect is so sensitive, any
> authentication scheme over an unencrypted network won't help you
> protect the data. It may not leak the passwords, because non-Basic
> doesn't transfer it in cleartext, but that's just one detail.

That was the whole reasoning behind supporting digest authentication.
Sure, TLS protects the connection from third parties messing around with
your connection, but nothing prevents an evil/misconfigured server from
stealing your cleartext password. At least with digest authentication,
you know that the server is not seeing your password either (at least
you would if the login UI for HTTP auth were barely usable and told you
info about the security mechanism being used... I'm getting off track
sorry).

> Keeping with the spirit of the current set of command line arguments
> (e.g. -m for maps, of which you can specify as many as you want), one
> could have a flag -p (protect/password/whatever) that takes a group
> name and a cleartext password and applies it to all files matching that
> group in the serving folder, for example '-m "nogroup user:pw"' for
> example.

I like that: simple and intuitive. Will do that, thanks!

> Given quark's static scope, it can be optimized to a point that no
> webserver before it really has gone to. I must admit that I rarely use
> HTTP-authentication in my web-projects, and I see it as half out of
> scope, unless it really is a drop-in solution that doesn't get in the
> way.

I hope it ends up being a drop-in solution, looking at the code it seems
like it will. We'll know when it's done ;)

Best regards.
José Miguel
Received on Fri Oct 23 2020 - 17:10:37 CEST