Feature request: add support for Digest authentication for scrape targets

[Tailzip]

Proposal

Add support for Digest authentification (in addition to already existing Basic authentication) for scrape targets.

[LeviHarrison]

Transferring to the appropriate repo.

[LeviHarrison]

I'm not familiar with Digest authentication, but given that it's not included in the Go standard http library, I think it might be too niche to support.

cc @roidelapluie

[roidelapluie]

Indeed. Digest requires an extra roundtrip and does not bring added value. If you want to secure the authorization please use basic auth with tls.

[muety]

Would love to have digest auth support, because wanting to scrape targets that only support such.

[anarcat]

i've found myself in this situation that i needed http digest auth for prometheus, then re-checked what htdigest auth is and, oh dear, that thing is just plain horrible.

the server keeps a copy of the user:realm:password MD5 hash on the server and that is basically what's used by the client to authenticate as a secret. The server sends a nonce, but that's it: the client replies with the MD5(MD5(username:realm:password):nonce:MD5(method:digestURI)) hash, which can be easily replayed by someone who has a copy of the server side password store.

essentially, those are plain-text passwords, it's bonkers.

i actually discourage the Prometheus folks from implementing this, maybe it will give people good ideas if they see Prom does not implement this.

the only universe where this makes sense is in plain HTTP where the wire is constantly surveilled. then there is an advantage because only the latter hash travels over the wire. but those days are long gone...

[muety]

I agree that if Prometheus was a web framework or something, it probably should intentionally not support digest auth to prevent people from implementing a digest auth-based login in the first place.

However, since Prometheus is a monitoring system and people use it to run against already existing systems, which they often times can't control, I think Prometheus should offer as many options as possible (following Postel's Law in some sense).

In my particular use case, I want to monitor a system that only support digest auth. But I can't use Prometheus to so so, unless somebody eventually merges #553.

[anarcat]

On 2024-09-12 23:39:36, Ferdinand Mütsch wrote: I agree that if Prometheus was a web framework or something, it probably should intentionally _not_ support digest auth to prevent people from implementing a digest auth-based login in the first place. However, since Prometheus is a monitoring system and people use it to run against _already existing_ systems, which they often times can't control, I think Prometheus should offer as many options as possible (following [Postel's Law](https://en.wikipedia.org/wiki/Robustness_principle) in some sense). In my particular use case, I want to monitor a system that _only_ support digest auth. But I can't use Prometheus to so so, unless somebody eventually merges #553.

And there were many comments made on that merge request that question whether or not even that code is a good idea. At this point, I would argue the robustness principle would say we should *not* implement this. There are *lots* of authentication systems out there, and you need to figure out a way to work around those to make your monitoring work with Prometheus. I am afraid that if we open the door to legacy systems such as this one, it will make an argument for other people to request more such things. See also: https://www.robustperception.io/prometheus-security-authentication-authorization-and-encryption/ ... which lists, as examples, " Digest access, bearer tokens, Kerberos, GSSAPI, OpenID, SSL client certificates, Radius and PAM ", just for the authentication layer. Out of those, I believe Prometheus supports SSL and bearer tokens. I think that's fair.