[TYPO3-dev] Password expiry and blacklists

[Christian Lerrahn (Cerebrum)]

Hi guys,
I've been meaning to write to the list about this for a long time but
never really got around to doing it. So, here I go now... :)

As TYPO3 is referred to as an Enterprise CMS, I really think it should
have a password expiry (particularly for the backend) and password
blacklists. This is a very common feature in corporate environments but
completely absent in TYPO3.

I've written an extension before for a client and hacked the core for
that but it was all very messy so I decided against publishing it. What
would really be needed is a proper approach to this problem from the
core's end. While it is quite simple to lock out users with expired
passwords, it is very hard to make users change their passwords instead
because they are expired.

Here is what I believe is necessary around password expiry and
blacklisting.

1. Users with expired passwords should either be locked out or made
change their password at the TYPO3 administrators discretion.

2. If forced password change is to occur, authentication needs to be
completed before allowing password change or even disclosing that the
password is expired.

3. Upon successful authentication, no session should be initiated but
the user should be redirected to a password change form instead.

4. The password change form needs to authenticate the user again before
accepting the password change. If authentication and password change
were both completed successfully, the session is initiated.

5. It should be possible to blacklist the last x passwords used and
ideally password rules should be definable as well. Blacklists and
rules also need to be enforced  when the password is changed
voluntarily in the backend to ensure forced password change cannot be
reverted.

These are my thoughts on the issue. Any additions or objections to the
procedure and constraints I am suggesting?

In my former core hack, I just added fields for password setting to the
login form which were enabled by a redirect after authentication. That
worked but had the downside that I couldn't really react to a wrong
"old password" in the password setting process and the user would be
logged out, have to log back in and then type the old password again
when changing the password.

I think the best way would be to have the whole password changing
process handled by an extension which could still use a skin provided
by the core (to not risk inconsistencies).

But, to come to my real point, I'm happy to implement all that. The
question I want to ask here is how to approach the problem. As I'm not
familiar with core development in general, I am worried that I might
approach this in a way as to never get my patches approved. This is why
I am presenting my thoughts about how to approach this in order to get
some feedback.

Are there any strong opinions about how this should be handled or how I
am suggesting to handling it?

Cheers,
Christian