tg16
God what i would give for a modern reimagining of Freelancer 2...
For context, getting something to low earth orbit is about 9.4km/s of Delta-V. From LEO to mars is another 4.3 km/s of Delta-V. Getting from LEO to any solar escape trajectory adds is about 18km/s.
As you can see, 30km/s of fuel savings is extremely significant, and that required the 175 year Grand Tour alignment.
The tyranny of the rocket equation is the fact that to carry more fuel to orbit, you need more fuel to get it into orbit, which itself needs more fuel. That's why gravity assists are so essential for escaping the solar system on a budget.
The planetary alignment that enabled the Voyager launch windows only occurs once every 175 years.
We should definitely be sending out more probes, but we can't just do it whenever we want, at least not without a lot more expense.
I'm also not going to respond to a non-expert's plea for information with unnecessary minutiae like the differences between LM, NT, and NTLM hashes or the differences between NTLMv1/v2 and NetNTLM. My ommissions were intentional because i'm trying to make my comment approachable.
In a default, non-hardened Windows environment, NTLM is a nightmare. Yes, it can be secured. No, it is not straightforward.
- NTLM doesn't sign packets. If you can intercept an NTLM auth request you can forward that authentication attempt to another resource and impersonate the user without needing to know or crack their password. You simply MitM the challenge-response between the client and the server. This is called NTLM relaying and is a core issue of NTLM, though some protocols have additional verification such as SMB signing, which is not enforced by default.
- NTLM has relatively weak hashes, though this is far from the biggest issue with NTLM.
- NTLM (unlike Kerberos), uses a single hash for all authentication. If you can compromise this hash, you can impersonate the user anywhere. With Kerberos, each auth event generates a signed with a narrow validity period that grants access to a tuple of user, device, and resource. Meaning if you compromise a user's Kerberos tickets, you can only impersonate them on services that they already had a ticket for at the time, and for only a few hours in until those tickets expire. The NTLM hash itself is the proof-of-identity for all NTLM auth, and this can be recovered in memory or on disk for local accounts.
- NTLM, combined with older broadcast name resolution protocols (namely LLMNR, NBT-NS mDNS, and WPAD) can be very easily intercepted and abused for NTLM relaying due to the lack of signing. It is trivial in most Windows environments to run Responder.py and get an administrative session on pretty much everything. Unless the enterprise has taken steps to harden against NTLM relaying (which is difficult both for compatibility issues and the sheer number of required changes), they're going to be vulnerable to it. My current environment has top of the line network monitoring, SIEM, and EDR, but it's still very easy to slip under the radar with NTLM relaying if you know what you're doing.
Edit: That said, I would not be surprised if this account was 100% accurate.