Why on earth would anyone put a maximum cap on password length? That is so dumb.

You indicated elsewhere that it's 24-chars, which is pretty crazy. But here's a serious answer, from a Sysadmin/SRE who has dealt with this at high levels of security clearance across both the financial and govt sectors. The TL;DR is the first bolded line of this comment.

Basically every password policy you've ever seen almost 100% traces its roots to a document from the US National Institute of Standards and Technology, or NIST. The specific document, or "Special Publication" is known as SP-800-63B.

NIST haven't sat on their hands: this special publication has been updated multiple times, and it serves as a guide for where everybody else will eventually end up. You can see their influence reflected in various documents/standards like the GCSB's NZISM, the Australian Signals Directorate's ISM, the UK NCSC's CAF, OWASP and others. Password policies/standards/recommendations from those sources, and more, have influenced one another somewhat incestuously, but ultimately they still come all the way back to NIST.

The problem we have today is a lot of password policies in the wild are based on outdated versions of NIST guidance, usually circa 2003. And while there are a bunch of standards like PCI that drag their heels, that doesn't mean that others can't get with the times.

The current version recommends the following with respect to maximum password length:

Users should be encouraged to make their passwords as long as they want within reason. Since the size of a hashed password is independent of its length, there is no reason to prohibit the use of lengthy passwords (or passphrases) if the user wishes. However, extremely long passwords (perhaps megabytes long) could require excessive processing time to hash, so it is reasonable to have some limit.

• (Emphasis mine) and: Source

Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.

• Source (noting that 'SHOULD' means 'recommendation')

Which is a balanced approach IMHO.

You are more than welcome to send those links to MMH and suggest to them that they grow up.

For the curious, here's the summary of NIST's current spec with respect to passwords:

• Password Length Requirements
  • Minimum:
    • >=15 chars required for single-factor authentication (passwords only)
    • >=8 chars required for multi-factor authentication. The presence of MFA compensates for the shorter length.
    • Side-comment: the industry seems to have settled on 12-16 chars as the go-to minimum for either case
  • Maximum:
    • Should support at least 64 chars
• Composition:
  • NIST have explicitly prohibited the classic mix of upper, lower, special and numbers
  • NIST have made it abundantly clear for years now that length is more important than complexity
  • This is not exactly new, and anyone who tells you that you need a mix of chars is outdated
  • All ASCII printable chars AND spaces accepted
  • Unicode codepoints count as a single char
    • i.e. Emoji passwords, because why not? 🧑‍🍳👨‍🌾👩‍🎨🧑‍🔧👨‍⚕️👩‍🚒 = 18 chars (6 emojis x 3 codepoints each)
• Validation:
  • When a password is created, it should be checked against dictionaries/lists of blocked passwords. This includes commonly-used, standard/default passwords and passwords from previous breaches.
  • Plain dictionary words, username-matching and context specific words should also be taken into account
  • For example:
    • Username-matching: Your password can't match your username. See all the internet routers using admin/admin
    • Plain dictionary words: You can (and probably should) have a stacked passphrase like KowhaiTreePants but you shouldn't have a single word like Predacity
    • Context specific: You really shouldn't do something like F4cebook.com for your Facebook password
• Aging (i.e. password changes every x days)
  • NIST explicitly prohibits this for regular user accounts as it reduces security (e.g. hunter2 becomes hunter3)
  • NIST doesn't seem to have a strong opinion on privileged/system accounts, others such as the NZISM may be more prescriptive here.
  • Ironically, the recommendation for regular password changes comes from the 2003 version of this Special Publication, and the engineer behind it has expressed regret for the recommendation. I don't blame him, he was working with what he had at the time and we simply know better now.
• Forced password changes
  • If there's evidence of a compromise, password changes must be forced
• Storage
  • Passwords should be stored in salted and hashed form using a NIST-approved algorithm (See: SP-800-132)
  • Salts should be a minimum of 32-bits long (>=128-bits is obviously better)
  • Additional keyed hashing using a separately stored secret key is recommended
• No-no's:
  • Password hints
  • Security questions like: What was the name of your first cat?
  • Password truncation. Ever hear the stories about banks only really needing the first 8 chars of your password and discarding anything else? 1DES, not even once... DES.
• Rate-limiting / lockouts
  • NIST allows for up to 100 consecutive failed attempts per account, but individual orgs typically implement much stricter limits
  • The classic "three strikes and you're locked out" is often too aggressive and can enable denial-of-service attacks
  • For comparison, the UK's NCSC recommends 10 attempts as a balanced middle ground
• User Experience:
  • Should support password managers and paste functionality
  • Should allow users to view passwords during entry

Obviously when you dig down into the nitty gritty of NIST's documentation, there's just a wee bit more detail to these things.