EnforceStongPassword set to False

We were wondering the same thing just yesterday! If anyone knows, I'd love to hear as well. 

Just tested this on TNEW v6. It appears that the only requirement is that the password is not an empty string! The letter 'a' works just fine, for example.

Because I can't help myself, I've got to make the case for not using EnforceStrongPassword. The logic that leads to this style of password complexity requirements has been roundly debunked by the technology industry over the past few years.

First, this XKCD webcomic speaks for itself: https://xkcd.com/936/

The main objection to using num/cap/lowercase/special requirements is that they make your login mechanism user-hostile. Humans can't remember passwords like that, and if they do, they're going to memorize basically one or two passwords and then use them everywhere (also bad). Password managers alleviate this difficulty, at least for the people who know how to use them, but then some websites insist on adding insult to injury by attempting to prevent the user from pasting into the password field. (Browser manufacturers almost universally recognize this to be counterproductive, and override the websites' prevention methods for the user's benefit.)

Many of these silly requirements came from a NIST publication from 2003 that was subsequently taken up by all but the least lazy of the cybersecurity auditing firm industry, leading to these awful recommendations entering widespread usage. Case in point, this feature was added to TNEW as a direct result of needing to pass a 3rd party security audit that just flat-out required the feature in absence of consideration of its actual effectiveness. In 2017, NIST released new recommendations along with a mea culpa that basically says "yeah, we were completely wrong about all of this and people should be doing the opposite". The story is nicely told in this WSJ interview with the original author of the standard (readable here: http://archive.is/A613V).

The main functional problem to keep in mind here is that "security" without usability results in neither. For requiring that passwords are of a certain "strength", much more subtle and robust heuristics should be used than character set variety. For example, 'aA1!' is a far weaker password than "a series of different words all in lowercase". The open-source library zxcvbn (yes, that's its real name) is widely recognized as a free and highly effective way to do this.

TL;DR: Using "EnforceStrongPassword" results in a worse user experience and worse security overall.

100 internet points to the first person to integrate zxcvbn with TNEW as a custom frontend validation!

Problem: PCI-DSS auditors don't care about what is secure, they care about what is listed in the document.  So not having the rules would potentially endanger your PCI-DSS attestation.

PCI-DSS v3.2.1 says the following:

8.2.3 Passwords/passphrases must meet the following:

• Require a minimum length of at least seven characters.

• Contain both numeric and alphabetic characters.

Alternatively, the passwords/ passphrases must have complexity and strength at least equivalent to the parameters specified above.

That "Alternatively" bit at the end would suggest using something like zxcvbn to calculate complexity requirements would be acceptable. The "Guidance" section of this requirement also references "the current version of NIST SP 800-63", which is what I referenced in my previous post. See section 10.2.1 for their "Memorized Secrets" recommendations.

Interesting: that's new to me.