Thanks Nicholas, I agree with your proposal.
Sometimes we do not consider in depth the risks (and their effects).

I have the benefit of hindsight and following the infosec community for business reasons :) I understand the use case for having a reveal password feature but at this point I believe that the use case is like the Loch Ness monster: some people claim to have witnessed it, many have seen a blurry thing which might or might not be it, most are still waiting to see it at all. You know?

I hadn't even realised it was new in Joomla 4 I've been using it for so long now. I do recall now I am reminded that @Hackwar did raise it as an over the shoulder issue.

I opposed that feature during the J4 admin template rewrite. I wouldn't call it an "over the shoulder" issue.

If it was just "over the shoulder" it would be merely inconvenient. This is far more dangerous because the security failure mode is invisible to the user.

So should this be a config setting? And if so should it be global or per use

@brianteeman I would say per use case for the following reasons:

• Joomla only uses this in login forms (com_users and mod_login)
• There might be a use case where the risk is mitigated by other factors and being able to view your password might be desirable (I am thinking Intranets accessed with locked down browsers and/or Internet kiosk points).

I would also add a Big Fat Warning in the respective layouts and the JS that it's a security risk enabling this feature, in case a 3PD gets overly excited about this feature.

As a result, I propose that this feature be disabled by default and introduce options in com_users and mod_login to enable it explicitly, if the site owner deems that the security risk involved is outweighed by the perceived utility with their target audience.

For consideration:
My wish is to build in a choice for each user group. Because I have users with low privileges who struggle with long passwords.

@sandewt I thought about it this too, but if you are not already logged in how do you know the user group? As far as I know time travel and telepathy are out of the question.

Please don't say "read the username" because that's a different security issue: information disclosure. It tells you if the username exists and whether it's a privileged account.

@nikosdion
Maybe I misunderstand. A user who registers on my site gets low rights. Depending on the situation, the administrator is given more rights.

The password field is shown before you log into the site. At this point, you are a guest. You need to enter a username and password to log in.

Therefore you have a chicken and egg problem.

I need you to log into the site (with your username and password) to know who you are and what are your permissions.

I need your permissions to decide if the password field will show a "Reveal password" button or not.

Therefore you have a chicken and egg problem.

Indeed.

When logging into the administrator, there should be a separate option to disable anyway.
In other words, distinguish between the administrator and the site client.

@sandewt Yes, of course they are separate options. I said it but I realise I did not spell it out for people who don't know the Joomla internals like I do. Sorry.

When I said that com_users and mod_login would get separate options I of course meant that each of the two mod_login modules (frontend and backend) would get separate permissions. The backend Joomla login page is rendered by administrator/modules/mod_login.

Further to that, I would like to stress that these options should be disabled in all three places (users component login page used in the frontend, login module used in the frontend, and login module used in the backend) because a Super User, Administrator, etc privileged accounts can and do log into the frontend of the site on many types of sites. It doesn't make sense protecting them in one place but not the other.

Side note (slightly off-topic, but gives you a better idea of the future of login security in Joomla as it has been discussed thus far): Eventually, we'll do what we discussed with @SniperSister many months ago, give you a way to set up allowed and disallowed login methods for each user group and/or each user separately. Ideally, highly privileged user accounts such as Super Users should only be allowed to log into the site with WebAuthn or a similarly strongly secure, non-subversible method. Since 4.2.0 you get the runner-up solution which is that you can force certain user groups to use Multi-factor Authentication so even if their password gets compromised it will still make it very, very hard for an attacker to log into the site as a privileged user.

@nikosdion

Thanks, a clear explanation. I assume that the registration form of com_users falls under that as well.

I haven't used the registration form in forever but, yes, if it has a reveal password button this applies to it as well. Same for the password reset, of course.

For security reasons, I am trying to separate the front end log in form - which in my case does not need additional security and can be permissive - from the back end user form which needs greater security. I was surprised to learn that they appear to be the same form. I agree with all of the comments on this page and would like to ask if there is anything planned to address this issue and give us more control over at least the back end log in form.

This issue is related to #39241

@Hackwar Should I leave this issue open for a while longer?

Yes please. I noticed it and got it on my radar but did not yet get to it. It will be processed soon. Feel free to contact me if you have questions about the process itself. If course everything related to this issue should stay here.

No problem, I will leave this open. I am glad to know that this is taken seriously and will be fixed!

I am taking this seriously, but I wont guarantee you a certain action. I will have to simply invest more time into this.

Valid issue

Open your own issue. I don't want to contribute anymore. Can you please respect that?

Ofc I can, I have blocked you now form the organisation. So you are not tempted to contribute again. I am tired of all the drama you are making and made over the last years, it is enough.