A couple of things here.

1. I am not going to comment on the decision to implement a 12-character password for all user accounts as the default minimum on installation. That's just a decision taken based upon the consensus view of the developers. It's debatable whether a hard-set minimum of 12 characters is a defect; it's probably more of a hurdle to climb over for website developers and their end users.

2. The 12-character minimum password length was implemented more than 12 months ago.

Of course, while people are merely testing J! 4, having to enter (and remember) long passwords just to perform a simple installation that may last anything from 5 minutes to a few weeks, is a bit of a "pain". It's not an insurmountable pain while people are testing. The real difficulty may lie ahead when a J! 4 website is used in a production environment and the site owner may have to answer "complaints" from end users who feel that long passwords are overkill.

In the last-mentioned regard, that's a question about customer acceptance and approval about a product. Some people may like long passwords and some people may not. If, however, there's a overwhelming rejection by consumers to embrace long passwords as "the norm" then that could be a factor in revisiting this current constraint. However, as I mentioned before, J! 4 is still very much pre-release and we won't really know what the market uptake of J! 4 will be for quite some time.

@sozzled what you are missing is that the site owner can change the minimum password count themselves for all their users on their site. It is only the password created during the installation that is secured with a 12 character minimum.

I know that the site owner can reduce the minimum password length to eight characters. The question posed by the OP relates to the 12-character setting applied (as the default) during installation. In order to progress the installation, the site owner has to use twelve characters for the admin password just to get the site up and running and then can reduce the password length afterwards; yes, I am aware of that. No dispute there. :)

The 8 characters min password is a security decision by jsst following the nist recommendations. You can still change this minimum in the XML file if you really want to do this.

I'm closing this here because it's not an issue. You can create a discussion if you like.

Adding other security mechanism are planed but are not so trivial because it increases support and education effort. So have to be well designed. And of course volunteers ;)

Its issue!! Most of usual users will just abort installation and go to another CMS Its stupid to make difficulties for users

This 12 char is nothing but BS and is totally unacceptable - what planet the dev's living on. Such practices have been clearly identified as leading to lower security by NIST.

This practice is antiquated and ill conceived.

Time to do some hacking. I will not be dictated too .....

find this tip for localhost easy installation

on installation/forms/setup.xml

change on

<field
    name="admin_password" 

line validate FROM:

validate="password"

TO:

validate=""
```<hr /><sub>This comment was created with the <a href="https://github.com/joomla/jissues">J!Tracker Application</a> at <a href="https://issues.joomla.org/tracker/joomla-cms/35035">issues.joomla.org/tracker/joomla-cms/35035</a>.</sub>

pretty much what I did but I blew the whole validate option out - did the same for the db prefix.

other security measures planned - well they had better consult not dictate or this will be the last release of Joomla on my servers - I decide the security in my environment - complex patterns /enforced changes / password hints and the like have been roundly condemned by NIST as it leads to bad habits on the part of users

I decide the security in my environment - complex patterns /enforced changes / password hints and the like have been roundly condemned by NIST as it leads to bad habits on the part of users

And that is why joomla does not do any of that.

Well were that true then this thread wouldn't exist because it does during install ...

read the code - you will see that it does not enforce complex patterns, enforced changes or password hints

and if you read the NIST guidelines you will see that Joomla follows every one of them including the minimum length

Fraid not - I deal with NIST as part of the day job - 800-63 provides no explicit length demands, it is all on use case and security model, brute force attacks aren't the principle attack vector these days, base reference to password length is made in 800-63B in appendix A2. I'd be genuinely interested in the document number in which you believe this 12 char compliance is required.

Not withstanding NIST allows things I don't - minimum 10 login attempts - fraid not on my systems - if I had my way you would get no feedback if you entered incorrectly.

In any event this shouldn't be part of any setup, I shouldn't need to read any code - the references to specific behaviours is an example of principle based on the installers insistence not only on 12 chars minimum but also on specific DB prefixes and a warning for those with 'future plans' - allow the user to make their own choices - by all means recommend and guide, give reasons, but enforcement is not the for the developers to decide.

I agree with @brianteeman. I will also repeat what I wrote earlier:

I am not going to comment on the decision to implement a 12-character password for all user accounts as the default minimum on installation. That's just a decision taken based upon the consensus view of the developers. It's debatable whether a hard-set minimum of 12 characters is a defect; it's probably more of a hurdle to climb over for website developers and their end users.

The 12-character minimum password length [during installation] was implemented more than 12 months ago.

Of course ... having to enter (and remember) long passwords just to perform a simple installation that may last anything from 5 minutes to a few weeks, [may be] a bit of a "pain". It's not an insurmountable pain [and a bigger] difficulty may lie ahead when a J! 4 website is used in a production environment and the site owner may have to answer "complaints" from end users who feel that long passwords are overkill.

In the last-mentioned regard, that's a question about customer acceptance and approval about a product. Some people may like long passwords and some people may not. If, however, there's a overwhelming rejection by consumers to embrace long passwords as "the norm" then that could be a factor in revisiting this current constraint. [We] won't really know what the market uptake of J! 4 will be for quite some time.

In the meantime the changes brought with J! 4 w.r.t. minimum password lengths are what they are. I have noticed that with many websites that I have accounts with these day, the password settings are now more rigorous including the need to enter 10+ characters, upper and lowercase, with numerics and, sometimes, special characters. That's just the direction things seem to be heading.

Anyway, I store my user account credentials (usernames and passwords) in several places; most web browsers allow people to store those details and use them to login to whatever services they need. It's not a big deal.

@SukMeWot the JSST decided to go with 12 characters as default because we don't have any "login attempts limitation", "ip blocklist", "fraud detection" measurements at this time. So the easiest way to make joomla more secure and less annoying per default is to extend the length of the password. The 8 characters minimum by nist is as you say a "minimum" so it means the "worst case". They also say you should allow at least 63 character long passwords (iirc we allow 200+ character long passwords)

We discussed this a lot and for us it was more important not to force you to use cryptic passwords (what you still can do) but to use a long password that is not so easy to brutforce.

As already mentioned you can always short the minimum password length to 8 and if you thing that's still to strong for you then you can change the xml file and set it to 1.

The reason why we enforce this also on "localhost" installation, is that many sites get created on a local installation and copied to a webserver afterwards, keeping the password "adminadmin" for the super user (which has 8 characters).

I hope you understand that for us this was a better compromise then enforcing upper/lower/digs/symbols which is harder to remember. I personally use 20+ character passwords incl all the symbol space and a password manager and never think about which password I have on which installation. Since Joomla 4 I also use Webauthn frequently even if I'm not so happy with it.

@HLeithner - Rational and thought out. That people can be lazy and deploy inappropriately configured systems I also deal with, you can never hope to keep up with this problem, security is a big deal for me, it really is although it may not come across that way. I deal day in and day out with programmers that think they know how to do my job better than I do so I can get testy on the subject.

Passphrases vs passwords, biometric, 2 factor there are many many ways to ensure identity, NIST discusses a few. Problems are compounded by the extensive use of mobile devices and the inability to tie a specific address to a specific individual, you can never be truly sure where communications are really coming from. I'd like to see more effort when it comes to 'public sign in' with permanent bans for repeat offenders, blocking an IP is often fruitless as the perpetrators use bots and hijacked systems, I'm a big fan of 2 factor but even that isn't infallible.

I remove the login from all my site offline pages (something for which I've yet to find an alternative to editing php directly), it appears even if you disable the login module you can bomb that indefinitely if other measures aren't taken.

For my own passwords I use a key vault and PW generator but this is largely to ensure 'uniqueness' since I can be lazy like anyone else - and I can't install another memory module. Most security breaches these days are caused by the user themselves, or our desire to create more and more complexity that ultimately leads to errors in deployment, oversight or configuration.

Perhaps an additional setup step is warranted that requires the installer to define the security policies during setup itself

So I'm finally getting around to looking at updating some of my sites from Joomla 3 and the very first thing I hit is this stupidity. Who on earth thinks that 12 char passwords are sensible?

Thanks to @Halison for the tip where to edit setup.xml before installing, but it pisses me off that I have to edit a file before I can even begin to use J5. Goodness knows what other nightmares I'm going to find imposed on me in the name of 'security'.

Perhaps an additional setup step is warranted that requires the installer to define the security policies during setup itself

That's a really sensible suggestion. Before even specifying the admin user and db prefix length (another bugbear - what is the point of a stupidly long one?) - let the installer specify the admin and default password length and the db prefix length.