On Fri, 23 Oct 2020 06:27:08 +0100 Nick <suckless-hack...@njw.name> wrote:
Dear Nick, > I don't think it's insecure presuming the HTTP is being served > behind some TLS connection. And if you're doing authentication you > want that anyway. I haven't particularly thought it through, though, > maybe there's something dangerous about it. I mean, lack of browser > support for a straightforward "log out" function sucks, but hey, > it's the web, of course it's broken. 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. > The filesystem based thing sounds odd to me, personally - I think > it's common for websites to have a quite different set of users to > those that exist on the server operating system. But I think setting > it in config.h is also a bad idea, as one of the nice design things > about quark is the ability to run it straight from the command line, > and needing to recompile to redo authentication would detract from > that. Maybe a simple authentication file with > username<space>password one per line, which is passed to a flag, > would be good? If you want a system with different files accessible > to different users, though, then reusing filesystem permissions is > the only non-intrusive way I can imagine. 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. > Just some early morning thoughts. I look forward to Anselm replying > and saying that authentication is out of scope for quark, keeping us > all honest ;) Quark is in a difficult position, because OpenBSD's httpd really is an excellent piece of software that provides all the functionality you would want in an all-purpose web server (CGI, Auth, etc.). Even though I intend quark to be web server that is quick and simple to deploy (i.e. in seconds from the command line to quickly share data on a local network), which would put in question many functions it has (vhosts, redirects, possibly auth later on), I have noticed that many people are just looking for a simple web server for their non-OpenBSD servers. And within that scope, quark fits its role, and because I like to tinker with things, I like to experiment with new things, e.g. the 100%-runtime-configuration. 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. With best regards Laslo
