First of all we should distinguish that while Golden Ticket is potentially viable on other Kerberos and Kerberos-style systems Pass-the-hash is a security vulnerability per se and outside of Windows it would just be given a CVE number and you'd be expected to fix it not write that "Mitigation is not practical" and act as though it isn't your fault.
In fact it has been given a CVE number and fixed in obscure systems where it was done, only Windows gets to shrug and say it's hard so we won't fix it. e.g. CVE-2005-3435
In Windows every user - anywhere in the world not just within one organisation - with the same password has the same hash. Worse than a PHP app from the turn of the century their most sophisticated password hash scheme is MD4(password). This makes the mistake that results in Pass-the-hash almost irresistible.
Because a Linux system uses salted (and pessimised) hashes, it is not tempting to try to authenticate remote hashes because you're going to have to build a multi-step protocol, passing parameters to the client so it can perform the hash. You'd probably instead look at existing protocols and discover SRP (or in the modern era any sensible asymmetric PAKE). This immediately shows you a better path forwards with no Pass-the-hash.
But because Windows has this constant 16-byte hash it is tempting to use that for authentication. You can do a bit of hand waving to avoid confronting how insecure the result is:
‣ Bad guys can't possibly know this 128-bit value because it's MD4(password) and there's no way to find that without knowing password. Therefore we only need to check that the 128-bit value is correct and we've authenticated the user.
‣ Storing the 128-bit value locally is fine because it's MD4(password) and you can't reverse MD4 to get the password back so it's not a secret.
Only when you see these arguments next to each other it is obvious this is absurd. So long as they're on different pages of a document, or preferably made in entirely separate discussions at Microsoft, the mistake is unnoticed.
You've engaged in the same equivocation that Microsoft uses by adding "or Golden Ticket attacks". Microsoft documents about Pass-the-hash routinely argue that this is just the same as any other stolen credentials attack, so it's not Windows at fault nobody could be expected to do better. This is definitively wrong and we need to call them out on it.
In fact it has been given a CVE number and fixed in obscure systems where it was done, only Windows gets to shrug and say it's hard so we won't fix it. e.g. CVE-2005-3435
In Windows every user - anywhere in the world not just within one organisation - with the same password has the same hash. Worse than a PHP app from the turn of the century their most sophisticated password hash scheme is MD4(password). This makes the mistake that results in Pass-the-hash almost irresistible.
Because a Linux system uses salted (and pessimised) hashes, it is not tempting to try to authenticate remote hashes because you're going to have to build a multi-step protocol, passing parameters to the client so it can perform the hash. You'd probably instead look at existing protocols and discover SRP (or in the modern era any sensible asymmetric PAKE). This immediately shows you a better path forwards with no Pass-the-hash.
But because Windows has this constant 16-byte hash it is tempting to use that for authentication. You can do a bit of hand waving to avoid confronting how insecure the result is:
‣ Bad guys can't possibly know this 128-bit value because it's MD4(password) and there's no way to find that without knowing password. Therefore we only need to check that the 128-bit value is correct and we've authenticated the user.
‣ Storing the 128-bit value locally is fine because it's MD4(password) and you can't reverse MD4 to get the password back so it's not a secret.
Only when you see these arguments next to each other it is obvious this is absurd. So long as they're on different pages of a document, or preferably made in entirely separate discussions at Microsoft, the mistake is unnoticed.
You've engaged in the same equivocation that Microsoft uses by adding "or Golden Ticket attacks". Microsoft documents about Pass-the-hash routinely argue that this is just the same as any other stolen credentials attack, so it's not Windows at fault nobody could be expected to do better. This is definitively wrong and we need to call them out on it.