[TYPO3-dev] Password expiry and blacklists

Peter Russ peter.russ at 4many.net
Wed Feb 15 07:28:58 CET 2012


--- Original Nachricht ---
Absender:   Christian Lerrahn (Cerebrum)
Datum:       15.02.2012 03:01:
> 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?


In an enterprise you use LDAP. There the company's password policy is 
defined. I see now need to add this into TYPO3. May be the extension to 
connect to the LDAP could be improved to handle the few error codes 
getting from LDAP correctly.

Further in companies it is a security risk to store passwords in TYPO3.

Peter.

-- 
Fiat lux! Docendo discimus.
_____________________________
uon GbR

http://www.uon.li
http://www.xing.com/profile/Peter_Russ



More information about the TYPO3-dev mailing list