Caddy: Feature Request: Digest Authentication

[shellster]

Please consider implementing a Digest Authentication option.

You might possibly be able to implement it with this library: https://github.com/abbot/go-http-auth/blob/master/digest.go

Thanks.

[mholt]

This would definitely be useful.

Should it be an add-on? Or should it be combined with basicauth? How involved is digest authentication to implement? If possible, can we avoid using another dependency for it (regardless of vendoring)?

[shellster]

You could make it an add-on.  It offers roughly the same security as NTLM authentication, but isn't proprietary and should work with HTTP/2.  Digest auth can be implemented in roughly two ways, the crappy way or by properly implementing a server nonce and qop options.  I highly recommend the full implementation.  The whole thing is documented in the associated RFC, and is relatively straight forward.  My cursory look at the link I provided, seems to be a pretty solid implementation, so if you wish to avoid a dependency is still might not be a bad reference.

For completeness, here is the latest RFC on the protocol:
https://www.ietf.org/rfc/rfc2617.txt

Here is the original RFC that has the less secure, original implementation:
https://www.ietf.org/rfc/rfc2069.txt

As far as I know, MD5 is the only hashing option that was ever actually implemented in browsers.

-------- Original message --------
From: Matt Holt [email protected]
Date: 04/03/2016 14:13 (GMT-08:00)
To: mholt/caddy [email protected]
Cc: shellster [email protected]
Subject: Re: [mholt/caddy] Feature Request: Digest Authentication (#712)

This would definitely be useful.

Should it be an add-on? Or should it be combined with basicauth? How involved is digest authentication to implement? If possible, can we avoid using another dependency for it (regardless of vendoring)?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

[kenny-house]

I'm looking for some places to contribute and implemented Basic Auth for another project recently, so if there's still some interest in this I'd be happy to jump on it!

[mholt]

@Kenny-House I think that would be great. I'm still not sure yet if it will be a plugin or built into core, but let's see what the implementation is like!

[vchimishuk]

Guys, what do you think about replacing basichauth module with new auth module which supports many authorization algorithms?
For instance config can looks next:
auth /foo basic user secret
auth /bar digest user2 secret2

[mholt]

I'm okay with two separate directives -- digestauth and basicauth -- in fact, I think I'd prefer two small middlewares than one bigger one. They can still share code if needed. If the digestauth plugin is small enough and doesn't have more dependencies (preferable), we could perhaps still keep it in this repo.

[kenny-house]

I'll aim toward a separate middleware from basic auth for the time being. I'm keeping in mind the similarity between basic and digest auth so that if merging to a single middleware is desirable later, it wouldn't take too much refactoring.

[mholt]

@Kenny-House How's this coming?

[kenny-house]

Hey @mholt. I was actually working on this a bit more yesterday. I'll see about getting the progress pushed up today or tomorrow!

[mholt]

@dzervas Cool. It's hard to say for sure with that little information, but if you need to persist something across all connections, perhaps a field in the middleware struct (mutex-protected) will do.

[dzervas]

Yeap, removed my comment 5 minutes later as I did exactly that. The implementation is done, I'm writing the tests now (they're PITA as golang does not support digestauth by default).
I also have to clean the code a bit.

[20zinnm]

Is this moving along or is this something I can pitch in on? @dzervas

[dzervas]

I don't have that much time (finals start in a week) but the only thing left is the tests. If you can pitch in, you're more than welcome!

[rmenessec]

I'm a touch confused—as referenced above, I thought digest only worked with MD5 hashes. The couple of times I've considered doing something besides basic auth or app-level auth, I ended up rejecting it for that specific reason: I couldn't find support for anything besides no-salt, one-pass, MD5-hashed passwords. The RFC doesn't seem to mention anything else, either.

Does the proposed support get us something better? Salts? Multi-round SHA-1, at least? Argon2id?

If it's still only MD5, I'm not sure I understand the benefit. I'm working on setting up a service that I was simply going to secure with private CA-issued certs—something of a hassle—so if there's more to this than MD5, I'd be very interested in hearing more detail...

[mholt]

I wonder if we could just break spec and implement our own with better ciphers? 👀

[shellster]

Implementing anything outside of the spec is pointless, no browser will support it. Digest is far better than Basic auth. It's not perfect, but it's on par with NTLM auth, but an open spec supported by all browsers. Combined with tls, it is perfectly reasonable.

[rmenessec]

@mholt If you have plans to one-up the browser space next—say, after Caddy hits 1.0—I'm making popcorn. And downloading the 0.0.1 release first thing.

@shellster Technically, if someone's willing to write all the necessary patches for Chrom[e,ium] and Firefox and probably get at least one other major server to support it, someone could probably get an extensible form of digest auth supported. All the necessary crypto pieces already exist, certainly.

I'm not arguing against digest auth, so long as no one is requiring me to use it. It's always nice to see Caddy get an extra feature that you can find in a competing server. I just wanted to be clear that your reference to "full implementation" and the mention I found of "proxy authentication" in the RFC didn't point to some way of expanding the available algos. I got a little excited; I tend to trust authentication directly via the web server over authentication via an app it's serving.

I simply don't see a benefit to MD5-in-TLS _vs._ plaintext-in-TLS, is all. If I used it, it would probably be an end run around someone's demand that I satisfy a compliance checklist that says I can't have plaintext passwords on disk. (Even if the file's protected by caps, the disk's encrypted, and the server's closed in a locked server cabinet in a locked cage in a locked room with guarded access and remote surveillance...)

[mholt]

This can be a Caddy 2 module, but I don't think it will go into this repo (i.e. not included by default into Caddy). The http.handlers.authentication module takes provider plugins and one of them could be digest auth.

Going to close this now since I don't think we'll work on it in here, but I'd love to help guide someone along creating a Caddy 2 module!