@sshcli New features go into J4, so I've changed branch information in the issue tracker for your feature request there.

Thanks @richard67

TBH, I'm not a fan of these PIN based systems as a primary means of verifying your account. They are actually a greater security risk as they create a system with a known range of characters and a fixed number of variations (you have 1 million 6 digit combinations, it is exponentially larger when you have six alphanumeric characters), the odds of brute forcing these systems is much more in favor of the attacker. These types of PINs are better suited as a secondary authentication method than a primary account verification token.

If someone wants to make sure core can be written in a way to support PIN based codes, then go for it. But I don't think it should be a core feature.

Me too, i don't see this as a core feature

IMHO, it could be available as an option, not mandatory.

TBH, I'm not a fan of these PIN based systems as a primary means of verifying your account. They are actually a greater security risk as they create a system with a known range of characters and a fixed number of variations (you have 1 million 6 digit combinations, it is exponentially larger when you have six alphanumeric characters), the odds of brute forcing these systems is much more in favor of the attacker.

A little addition (without disagreeing your concerns), a PIN-approach only makes sense, if you limit the number of trys. That's how some bank cards work, 3 trys and you're out.

A bank card is different because that is the only means the system has for validating use. Internet websites don't have that same system design limitation.

It's not that I don't like PIN based systems, but I think they are inherently a greater security risk and not as suitable as a primary authentication/validation mechanism as a result. They are well suited as a secondary authentication/validation mechanism (think how you log into a site then get a SMS with a code you have to enter in, sure it's a pretty weak form of 2FA but still fits the example here).

That's why I said if someone wants to design Joomla in a way where someone wants to flip to a 4-6 digit PIN as a validation token instead of a more secure 16-32 character alphanumeric string (I forget what core is actually generating), then by all means make core extensible enough to pull it off. But I don't think it's core's territory to ship that feature (if done right a plugin provides the implementation), and it's definitely not core's territory to make that the default mechanism. Security postures shouldn't be changed because "it's trending".

Security postures shouldn't be changed because "it's trending".

My main concern here is the "password reset email" landing in the in spam folder. (Sometimes, not always)
URLs in emails are taken into consideration when calculating spam score.

Anyway, this is just a suggestion, I will not be offended if you decide to close this issue.

The two-factor authentication method, which requires using third party services, is clumsy and seems to me NOT a feature within Joomla! 4 but more of an add-on. Plus it does cost $$$ or is very difficult for the average novice or beginner user to implement. A PIN CODE generated by Joomla! itself makes more sense than reaching outward to third parties for "touted" Joomla! two factor authentication being "built in" - IT IS NOT.

It does not have to cost anything

Maintainers please make a decision about this feature request. If it would not be accepted (if developed) then it should be closed @wilsonge @rdeutz

Please feel free to close this feature request If you don't want it. I really mean it.

This has been in the RLDQ for 14 months. the entire point of the RLDQ was to avoid this from happening

Base on feedback from some maintainers on this topic, I can see that this is something would not be implemented in core. Therefore I'm closing this issue.