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
