Learning how to secure Traefik ending up with some safety concerns

Traefik Traefik v2
1

Hi,
there was quite along learning curve but start feeling comfortable using Traefik on a daily base.
Recently I went into the details on how to secure Traefik.
I'm afraid, that the information that is given in the tutorial Traefik 2.0 & Docker 101 and in the docs are misleading, may even imply a security risk.
The first makes you belive setting a password is all that has to be done, the latter even advertises an insecure hash algorithm.

May I start with the latter.

It is strongly advised not to use MD5 and SHA1 as mentioned in/by

So why is BCrypt strongly recommended and used in the code example?

Now the first.

Reading Traefik's blog entries Traefik 2.0 & Docker 101 can lead to the imagination that settings the password barrier is all that is needed.
That is definitely not the case and poses an operational risk as a proper BCrypt hash can take time to be generated following recommended cost factors.
Years ago a cost factor of 10 was default and 12 recommended, read:

So you may go for >=13 nowadays, what as quite time-wise impact, see Hashing in Action: Understanding bcrypt.
This decision has an impact on the server and the usability of Traefik dashboard. On the one hand that can slow down your server when it suffers a brute-force attack, see dashboard loads longer with BasicAuth & Bcrypt Hash · Issue #6200 · containous/traefik, plus in there referenced issues.
On the other hand, if a brute-force attack, originating from multiple corners of the internet, is on-going, the additional load that is put on the server can be quite high as it needs lot of CPU power to answer each log-in attempt.
So I'm wondering that there are not any warning and recommendations to implement:

and get a free account at Cloudflare to prevent DDoS-Attacks as the tickets

So that is my humble opinion on this, coming from learning by doing approach.

It is properly easier to understand why I say this when I state what I have learned so far and what sources are to blame

To be honest, the first time I read the documentation I was quite confused by the hash syntax and trying to understand how the password is stored/checked.

So I began to ask google and I found a nice visualization of the Bcrypt result string in

I continued reading the essence of the difference between Encryption, Hashing and Salting and how it can be combined, see An Illustrated Guide to Cryptographic Hashes.
Moreover, I found good explanation on the difference of Salting and Hashing, reading:

and good illustration on how all if cab be combined: RSA sign and verify using Openssl : Behind the scene

So I learned that ashing and salting won't prevent a brute force attack but it will slow down the process, as well commented in How is hashing and salting a password going to stop Brute Force attack. : webdev.
Another point is, taht if the database is breached by either SQL injection vulnerability or obtaining a backup of the database they are able to crack any of the hashes, so it is recommended to pepper the salts.
There is a nice explanation of all this in What is hashing? - Tech Tales - Medium and an excellent presentation, what you can enjoy on Safely storing passwords.

As I generated some hashed I was quite irritated that the result different each time I press the generate button. It turned it wasn't only me and the reason is simple, it is due salting and/or encoding, depending on your hash function:

Last but not least I found a good explanation of why you should not use Digest access authentication - Wikipedia. Wikipedia lists the risk clearly and you find the risk in a nutshell on Flaw in HTTP Digest Authentication - Information Security Stack Exchange. My main concern is that since either the password or the digested username, realm and password must be recoverable, it means it isn't digested/hashed.

For information here a the tools I used during my journey

7 Likes