Pretty sure that you’re thinking of an additional, unrelated security hole. I recall that there were attacks against NTLM hashed passwords too – IIRC, one could sniff login attempts against Windows fileservers on the same network, extract hashed passwords going by on the network, and then run dictionary attacks against them, which sounds like the exploit being described at your link. That was actually worse in that it also affected the (more-widely-used in production in businesses for serious things) Windows NT servers.
The hole I was attacking was specific to the fileserver in the 9x line, and it wasn’t a weak hash or unsalted hash, but a lack of hashing – it was specifically a case where the passwords were not stored in a hashed form. That was fundamentally a requirement for the attack to be be appearing in this way; if they had had any form of hashing, even with the length verification bug, you would have had to extract the entire hash, then do a local brute-force attack against the hash to reverse the hash, and gotten the whole password at once rather than having it show up a digit at a time.
Windows had a lot of security problems around that time.
EDIT: Regarding your hole, it sounds like NTLM authentication still is prone to problems:
Attackers can intercept legitimate Active Directory authentication requests to gain access to systems. A PetitPotam attack could allow takeover of entire Windows domains.
EDIT2: Oh, if you mean “worse than I remember” talking about the case reduction, then never mind – I thought that you were saying that the length check bug made your hole worse.
Pretty sure that you’re thinking of an additional, unrelated security hole. I recall that there were attacks against NTLM hashed passwords too – IIRC, one could sniff login attempts against Windows fileservers on the same network, extract hashed passwords going by on the network, and then run dictionary attacks against them, which sounds like the exploit being described at your link. That was actually worse in that it also affected the (more-widely-used in production in businesses for serious things) Windows NT servers.
The hole I was attacking was specific to the fileserver in the 9x line, and it wasn’t a weak hash or unsalted hash, but a lack of hashing – it was specifically a case where the passwords were not stored in a hashed form. That was fundamentally a requirement for the attack to be be appearing in this way; if they had had any form of hashing, even with the length verification bug, you would have had to extract the entire hash, then do a local brute-force attack against the hash to reverse the hash, and gotten the whole password at once rather than having it show up a digit at a time.
Windows had a lot of security problems around that time.
EDIT: Regarding your hole, it sounds like NTLM authentication still is prone to problems:
https://www.csoonline.com/article/571263/ntlm-relay-attacks-explained-and-why-petitpotam-is-the-most-dangerous.html
EDIT2: Oh, if you mean “worse than I remember” talking about the case reduction, then never mind – I thought that you were saying that the length check bug made your hole worse.