You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
No matter how long the password is, if it does not strictly contain a number, capital, or symbol, it is rejected. This actually means the password search space is less secure, because the passwords being eliminated for example are Sq$Y/DsZ="!-#tLvm:}x which is clearly quite strong, and the search space for brute force password cracking is significantly lessened.
To Reproduce
Steps to reproduce the behavior:
Try to change passwords.
Use a random Password generator in a password manager to generate a password.
>ñhooãgâÖsxOôÆÙR is an example password that has no numbers and so would be rejected.
Expected behavior
Not accepting common passphrases is the more appropriate password rejection step, alongside password length. Implementation of a hardware security key architecture would negate the need for strong passwords in all but the most mission critical environments.
Additional context
Eliminating any potential variable in passwords means the sample size for potential passwords is significantly reduced. The more secure way to adopt is from https://cry.github.io/nbp/ to eliminate common password usage.
The text was updated successfully, but these errors were encountered:
JuPing, you mean on QuRouter from router side
or QTS from NAS side?
QTS user side is where I saw this problem.
The default password options on the sticker as standardised, I understand. It's the setting up of a new passphrase that's an issue. I use a passphrase generator to randomly set my passphrases, so oftentimes I have to generate several new passphrases before I hit on one QTS will accept by default, which shows in practice how introducing criteria that is not well thought out, will degrade security rather than enhance it.
Implementing the commonly-used passwords to reject database by default should be a better option in terms of eliminating bad passwords.
Describe the bug
No matter how long the password is, if it does not strictly contain a number, capital, or symbol, it is rejected. This actually means the password search space is less secure, because the passwords being eliminated for example are
Sq$Y/DsZ="!-#tLvm:}x
which is clearly quite strong, and the search space for brute force password cracking is significantly lessened.To Reproduce
Steps to reproduce the behavior:
>ñhooãgâÖsxOôÆÙR
is an example password that has no numbers and so would be rejected.Expected behavior
Not accepting common passphrases is the more appropriate password rejection step, alongside password length. Implementation of a hardware security key architecture would negate the need for strong passwords in all but the most mission critical environments.
Additional context
Eliminating any potential variable in passwords means the sample size for potential passwords is significantly reduced. The more secure way to adopt is from https://cry.github.io/nbp/ to eliminate common password usage.
The text was updated successfully, but these errors were encountered: