My guess is that it is a sort of knee-jerk reaction. Just like the xkcd about CorrectBatteryHorseStaple, where there is a huge difference if the attacker knows for certain that everyones password is Four English Words From The Dictionary, or if you use those four words on a "anything 8 chars or longer works fine" system.
If you know a site has a 4-words policy, the xkcd pw has very low entropy, but if you use this strategy on a "any pw goes" site, a bruteforcer would have to test all lengths upto 25 chars before finding yours (sort of).
So in the port-knock case, it is probably a rather poor method in the specific case that I am on some remote network, and the evil 3rd party is actively sniffing my traffic from my client to my server and can record the knocks. If I have a simplistic knock sequence and they sniff it, they can replay it and get access to my https. But, if we are talking about some 3rd party that only knows a service may be up on the host newly.minted.cert.ccTLD, then it is FAR less likely that they can ALSO sniff my port knocking sequence and start abusing my new TLS service. The chances become almost ridiculously low for this to occur.
So I agree that simplistic port knocking is sort of bad in the long run for cases like "I am often on a hostile network but still want to talk to my home server securely" but would work wonders for "soon after the cert is signed, someone scans my TLS boxes ip".
> If I have a simplistic knock sequence and they sniff it, they can replay it and get access to my https.
Somewhat related, I've never set up port knocking but I've been wondering how hard it would be to set up TOTP-flavored port knocking. The basic idea would be to select the pattern of "knocks" the same way TOTP generates a code, I'm not sure how much it would improve things though.
> If you know a site has a 4-words policy, the xkcd pw has very low entropy, but if you use this strategy on a "any pw goes" site, a bruteforcer would have to test all lengths upto 25 chars before finding yours (sort of).
How so? Iirc, the entropy calculations assume that the attacked is aware passphrases are used. The eff-long word list often used for xkcd-style passphrases has 7776 words. So on average it would take 7776^4/2 attempts to guess one (randomly generated) 4-word passphrase, comparable to a truly random 8-9 character password with special chars. As the comic points out, people tend to be pretty bad at remembering random sequences of characters and therefore often often use combinations of common words and apply non-random substitutions and patterns, resulting in much lower entropy for those passwords.
Of course, everyone should use a password manager in the first place, but for cases where people don't or they need to reliably remember it (master passwords and critical ones), xkcd-style passphrases are a good and secure option.
If you know a site has a 4-words policy, the xkcd pw has very low entropy, but if you use this strategy on a "any pw goes" site, a bruteforcer would have to test all lengths upto 25 chars before finding yours (sort of).
So in the port-knock case, it is probably a rather poor method in the specific case that I am on some remote network, and the evil 3rd party is actively sniffing my traffic from my client to my server and can record the knocks. If I have a simplistic knock sequence and they sniff it, they can replay it and get access to my https. But, if we are talking about some 3rd party that only knows a service may be up on the host newly.minted.cert.ccTLD, then it is FAR less likely that they can ALSO sniff my port knocking sequence and start abusing my new TLS service. The chances become almost ridiculously low for this to occur.
So I agree that simplistic port knocking is sort of bad in the long run for cases like "I am often on a hostile network but still want to talk to my home server securely" but would work wonders for "soon after the cert is signed, someone scans my TLS boxes ip".