In the 4.x version of the framework, it is mandatory to have a strong password for super admin, to get started with the project. Most people pick some easy password to start with, then when they are ready to deploy, changes to a stronger one. Forcing users to choose a strong password from the beginning reduces the efficiency of a developer.
The solution to this will be to have a button, unchecked by default, which ensures that the user is willing to give a less secure password for the time being. And if they want can change the password from the super admin dashboard at a later point in time.
This is how the error that the user faces when he/she provides an insecure password.
Labels |
Added:
?
|
My suggestion was to give an option to the user for them to decide. Personally, I would definitely prefer security over a bit of extra time that I get from small things. But in this situation, I would stick to a much less secure environment in the time of "development". The option to change the password is still there if they want to at a later point. This way we can ensure both types of users are satisfied.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-03-23 16:53:42 |
Closed_By | ⇒ | rdeutz |
We are not going to add such an option.
Its not that we have an obscure rules like 2 numbers, 6 symbols 4 uppercase and 2 lowecase just the only requirement to have a minimum if 12 chars. Thats following the recomendation from the international Security Agencys IIRC thats the suggestion from the europen agency.
One could argue that with the DSGVO in place we also have to apply industry standard security practices as well as secure by default so i dont see us implementing any kind of checkboxk that was suggested given that the user you are creating there has the highest permissions possible in the system.
When you have a shorter PW just write it twice to pass the rule and you should be good to go. When you require one specific PW thats lower you have to modify the database directly and set the correct hash with your PW, that would bypass the PW rules we implemented into the CMS too. Its not recommended but when you have to thats the only way i'm aware of.
The development argument was also discussed back then. The problem with that is after the development ended such sites get moved up to production so we have that less secure PW on production too.
And if you want you can lower the password min length to 8 characters after installation.
As opposed to reduces the security of the website. I know which I prefer.