Caddyfile and hashed password

[clement-igonet-at-galaxy-semi]

1. What version of Caddy are you running (caddy -version)?

0.9.2

2. What are you trying to do?

I'd like to http basic authentication inside Caddyfile, without being force to write my plain text password.
Moreover, I'd like to push my commits in a git repo. So, I can not imagine to let my plain text password in it.

3. What is your entire Caddyfile?

xxx.yyy.net {
    basicauth / user:$2y$05$iIhoKBnUjfoz9HjV6OOHYO4GD7uVbcrP1PbByFx6K2tOxxaEE/E/6
    proxy / 10.0.50.1:8080 {
        transparent
    }
}

4. How did you run Caddy (give the full command and describe the execution environment)?

As a systemd service in debian jessie (8.5) with caddy-ansible role.

5. What did you expect to see?

I expect basic auth to work without suggesting to write my plain text password.

6. What did you see instead (give full error messages and/or log)?

I get a deprecated warning about using htpasswd in the documentation
I get source code able to maange hassh password
I get no implementation if hash inside Caddyfile itself, but a documentation suggesting to write plain text password.

7. How can someone who is starting from scratch reproduce this behavior as minimally as possible?

It's not a real bug but I think a very big improvement to do in term of minimal security level.

[JuliCodes]

Hello,

two ideas for this.

1. Extend the original basicauth directive with a parameter for the hash algorithm or just that the password is hashed. Maybe its cleaner, but i think it makes the syntax more complex.
2. Prefix the given password, so for example sha1=0a4d55a8d778e5022fab701977c5d840bbc486d0 to use Hello World as a password. So in the development everybody could use plain passwords and for the production we can use hashed ones.

Greetings

[clement-igonet-at-galaxy-semi]

Ho please... Whatever is the environment we are working on (development or production env), storing plain text password is a bad solution.

If we want to give caddy a little bit of credibility in term of security, we should not let the ability to rely on plain text password at all, but rely on a format like the one used by /etc/shadow (.htpasswd bcrypt format). This last is extensible and let the ability to use salted hash with a decent algorithm.

[JuliCodes]

Hey,

if you want a strong security, it shouldn't use HTTP Basic Authentication (in my opinion).

For that there are plugins like https://caddyserver.com/docs/multipass.

In my opinion a change here in the BasicAuth middleware shouldn't break older installations of caddy.

Greetings

P.S.: I'm a student in applied computer science, so i know, that unsalted hashes are really insecure.

[yumaikas]

If multipass is a stronger password system than HTTP basic auth, should the basicauth docs be updated to point to it as a solution?

[JuliCodes]

Hello

If multipass is a stronger password system than HTTP basic auth, should the basicauth docs be updated to point to it as a solution?

I think the docs contain a really good description, about what BasicAuth is and what not. And multipass is not really a "better" alternative. It's just an other way of authentication, which removes user credentials from the caddyfile.

But this is going to be OT.

If @mholt or other maintainers think we should use hashed passwords, it would be nice to get their comment here, and i'll look into a useful Merge Request for it.

Otherwise i suggest to close this issue

Greetings from Germany

[mholt]

You could use environment variables to store your password and then you can just reference the env variable in the Caddyfile like so: {$MY_PASSWORD}.

But I agree, I think with the use of env variables, that should satisfy this request. The question is more about password storage than basicauth itself.

[clement-igonet-at-galaxy-semi]

Well, playing with environment variable is not the solution, it just shift the problem outside the config file.
The main problem is to keep clear passwords somewhere in the machine.
The problem is not just "about password storage", the problem is about the way we decide to implement "basicauth itself".
Multipass is a totally different solution, out of scope.
I don't think this case should be closed as is. But if you're not at all concerned by a minimal security level, then I can understand your point of view...

[Technifocal]

I have to agree with @clement-igonet-at-galaxy-semi, utilizing environment variables still keeps the passphrase in plaintext somewhere on the system and is, as such, not an viable solution.

As of current, I am using .htpasswd, which from my understanding does allow hashed passphrases, however is current deprecated by Caddy and as such also isn't a viable solution.

[JuliCodes]

Hello, .htpasswd is not safer than hashed passwords without salt in Caddyfile. And the chosen hash procedure md5 in .htpasswd without salt is broken... So you could prevent the hacker from using Google to decrypt the password and store it in plaintext. And I have no idea how to use that salted, cause then the salt must be stored somewhere in clear text.... Greetings

[mholt]

The main problem is to keep clear passwords somewhere in the machine.

utilizing environment variables still keeps the passphrase in plaintext somewhere on the system and is, as such, not an viable solution.

If your machine gets compromised, it doesn't matter anyway. If your env is not safe, you've got bigger worries. ;)

[clement-igonet-at-galaxy-semi]

Well, mholt, I really appreciate caddy because of his simplicity to use. It does just work, it's so good to use in a DevOps automated environment.
And then, because I'm used to put all my scripts (vagrant, ansible, jenkins, caddy, ssh public keys) in a git repo to automatically mount virtualized server infrastructure, I'm also confortable with the idea of putting my hashed+salted password (with good algorithm and size) in a (limited) shared repo because I trust in the way it is obfuscated.

And no, in this way, my machine is not compromised and I feel confortable enough to keep my clear password secret for some years.

F.Y.I., trusting in an algorithm for a delimited period is what is applied with all modern certificates that used exposed hashes to sign data.

[clement-igonet-at-galaxy-semi]

So, is there a chance to reopen this case?
To summarize, I suggest an important enhancement quite easy to implement.
I feel you don't understand my request and you autoritarily close it. Is it the way you want people to help you?