Password security "secure" does not recognize a secure password as secure but as 'medium'

[D3nnis3n]

User name: D3nnis3n

TITLE

Password security "secure" does not recognize a secure password as secure but as 'medium'

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk Obsidian 18.0.30, Ubuntu 20.04.1

PROBLEM DESCRIPTION

Kl1#-3zL (for example) is not recognized as a secure password but only as a 'medium' password, despite fulfilling all requirements:
- 8 Characters
- At least one uppercase character
- At least one lowercase character
- At least one number
- At least one special sign

STEPS TO REPRODUCE

Try the password with password security set to "secure".

ACTUAL RESULT

Password will be rejected for not fulfilling 'secure' requirements.

EXPECTED RESULT

Password will be accepted due to fulfilling 'secure' requirements.

ANY ADDITIONAL INFORMATION



YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug

 

[Bitpalast]

I think that the algorithm is o.k., but the description of the requirements is not detailed enough. For example
P@ssw0rd12 will work as a strong password, but
P@ssw0rdab will not work (because there is only one digit; the requirement is at least three digits in this case).
But this is dynamic. For example, if your password is long enough, you can omit digits altogether. It's not really about a certain number of certain characters. The algorithm calculates how many different combinations will need to by tried given the character set that the password is using. It's a pretty smart approach. For example
Psswrd1234948593 is considered strong, because it is very long, although it does not have any special characters. The length makes up for the missing special characters. The character set may be smaller, but the number is higher, so that it takes just as long to decrypt like
Psswrd123%
because here an attacker will need to try less positions but more variations per position.

So, yes, probably the text description should be updated.

 

[D3nnis3n]

Yes, it's confusing, we've now set security to Medium, as we couldn't enter passwords otherwise. For all low-security cases we use passwords that fulfill exactly the current description of 'secure' and those are definately not crackable in 7 minutes. Unfortunately with 'secure' they cannot be entered despite the description suggests otherwise. Passwords of bigger size are hard to remember for people for those simple tasks (webmail, etc) and can therefore not be used.

 

[Bitpalast]

Great that you found a solution that works for you.

... definately not crackable in 7 minutes. ...

Let me address this, please. I absolutely respect your opinion on this. However, for other users who might read this post, I would like to encourage you to rather use more difficult passwords. The computing power has dramatically increased over the past decade, and passwords can easily be cracked within seconds by parallel architectures where several systems test a certain subset of combinations each. For normal websites and users who have a backup of their website, a lower security password might be sufficient, but in general it is possible today to use the processing power of a gamer's computer, specifically their graphics board, to run enormeously powerful brute-foce attacks.

 

[D3nnis3n]

Brute-Force attacks are effectively stopped by not allowing them, not by longer passwords. If you allow someone to test a million passwords without stopping him, that's a totally different issue. For normal users requiring them to use that long passwords does simply not work and is not required when brute-force is effectively stopped. Noone wants to type 16 character passwords for his e-mail account if he is not an IT professional. (And to my experience as one most of my colleagues don't want either, especially when trust in password management systems is low) Can't close the eyes from reality. I did state that for usages that require higher security and are typically not used by non-it-personnel different security measures are used by us as well, typically 32 long passwords or key setups. But that's not the main security layer against brute-force specifically.

Hence i'd actually prefer if passwords fulfilling the description are accepted, as making users happy is the most important factor. You don't need security if you don't have users or if users just pin their passwords on notes that can be read by everyone as they cannot remember it otherwise - effectively nullifying your security. And unfortunately, that's reality. Changing the documentation fixes the issue as well, but not in my preferred way. Both is acceptable from the it-standpoint of a 'bug', though.

Different security levels for different usages would be even better.

 

[mow]

However, for other users who might read this post, I would like to encourage you to rather use more difficult passwords.

Consider Issue - "Very Strong" password policy is unnecessarily prohibitive

 

[D3nnis3n]

Oof, that algorithm seems broken beyond repair.