Banned words accepted in certain formats

[joshama]

It seems I've managed to trick the system. I just happened to test with this password format and the change was accepted, so I thought it wasn't working, but having tested further it seems like using the format of [banned word][special characters][any text] will cause acceptance. I can also do [banned word][special characters][banned word] and get accepted. So aardvark!@bacon gets accepted.

[ryannewington]

Hey @joshama,

Your observations are indeed correct. However we must remember the purpose of the banned word feature.

What we are trying to do is prevent known, common substitutions that an attacker may try when trying to guess a password through brute force and password spraying attacks.

People may think they are clever by using P@55w0rd instead of password, or Winter2018!, but these substitutions and patterns are well known, and baked into the 'dictionaries' used by password cracking tools.

So while advark!password would be accepted, it doesn't match a 'known pattern' of password use, and therefore is not considered a weak password.

The best way to think about it is that banned words are there to prevent the use ofknown substitutions and patterns against single dictionary words.

If you did have a word you wanted to outright prevent the use of, even when used as part of a larger phrase, you could used the regex rule to create a pattern that matched that word.

I hope that helps clarify the behaviour of the product. Let me know if you have any follow up questions.

[joshama]

I see. Thanks for the response! What I'm attempting to do is disallow actual complete dictionary words and names from being used, as is required by a security audit I have to comply with.

Is it possible to use this system to check for and disallow all instances of dictionary words in a password?

In this case, "p@ssw0rd" would comply with the standard, but "password!dictionary#cheese" would not, despite being a much stronger password.

[ryannewington]

@joshama

The tool doesn't support that scenario today, but I'm not adverse to adding in capability if it benefits others.

I'd need to understand what this requirement is, and be able to clearly articulate how it improves security of passwords.

I could be wrong, but at face value, it does perhaps sound like someone has misinterpreted a common requirement of not allowing passwordsbased solely on dictionary words - a common and we'll known mechanism to stop brute force attacks. That's what LPP does today. Im not aware of any security benefits to not allow the use of dictionary words in passwords at all, but I'm happy to be educated.

Ryan

[joshama]

@ryannewington I took a closer look at the standards we have to adhere to an you are absolutely correct! We understood the policy as a password cannot "contain" a dictionary word, but it actually says it cannot "be" a dictionary word. So in fact LPP as it stands does meet this requirement for us.

Thank you for talking this through with me. In this case I was mistaken and there is no issue with this software, or additional feature required.