Hi, As I see these two requirements are orthogonal and better to discuss in separate threads. If we consider one by one,
1. Password History Validation. This is another layer of password pattern validation, which is done when an user try to change his password. Hashing method of old password matters only to this requirement and IMO we should treat old passwords in the same manner for the current password, hence the default option would be set the same hashing mechanism for both old and current passwords. Having a configuration to override this behaviour and set any password hashing mechanism is fine.. But if we implement "allowing to change hashing algorithm", it would be tricky to move current password to idn_password_history_data table with the new hashing in scenarios like "password recovery", "change password by admin" where old password is not provided. One other thing should take note is, password hashing algorithm can vary from one user store to another, hence hashing algorithm should be a picked from idn_password_history_data table. 2. Force Password Reset. This policy enforced when an user try to login. During login, if user subjected to this policy, the default behaviour would be to force to change password. As Dulanja mentioned, it will be useful make password reset optional and give user to skip it, if the admin enable that option. If user wanted\have to change the password, it would initiate password change flow... then depending on the Password history validation feature is enabled or any other password policy is enabled, user have to enter suited new password. My point is, Force password reset feature should take care upto only initiating the password change flow, rest of the password change flow is depends on password policy features. As I recall, there was some other requirement came up with this feature where an user should get an notification before (2weeks, 3days, 1day... etc) he\she reach to the threshold period. We should implement these features, in a way we could easily implement such supplementary requirments as well. If we consider generally for both these features, 1. What would needed to be configurable for service provider \ application wise? > IMO, Force Password Reset feature would be a configurable option for service provider wise. Having this feature enabled for a service provider would contribute towards to strong authentication index. 2. How to get use of underlying user store implementations? > Some userstore implementations (LDAP\AD) do have OOTB support for both these features. Its better if we can come up with a model where we can get use of those implementations. Thanks, Darshana On Mon, Jun 20, 2016 at 3:43 PM, Omindu Rathnaweera <[email protected]> wrote: > Hi, > > >> All the passwords which are supposed to store in this table are old >>> passwords (expired). >>> >>> - I think we don't need to use the same password hashing algorithm >>> (with or without salted value) which is defined user-mgt.xml for password >>> history validation. >>> >> >> IMO using the same hashing algo is cleaner. Isn't the current password >> also stored in this table? If stored, it's mandatory to use salting. >> > > I believe we should use either the hashing algorithm specified in the > user-mgt.xml or provide a separate config to specify a hashing algo for > password history. > > Consider the following scenario. > > Let's say we have specified the hashing algo in user-mgt.xml as SHA-512 > and we use SHA-256 (hard coded) to store old passwords. Given that the user > has the option to maintain the old password during a periodic password > reset, then the old password will be the same as the existing password if > the user decides to stick with the old password. Now, in the history table > the current password will be stored in a much weaker hash. This doesn't > seems right, does it ? Also using the hashing algorithm specified in the > user-mgt.xml or a different config means that we'll have to store the > hashing algo in the history table. > > Regards, > Omindu. > > >> >> >>> - admin users can change other user's passwords without giving their old >>> passwords. In that case, how can we find the old password hash value to >>> store for password history validation? >>> >>> >>> Your comments and suggestions are highly appreciated. >>> >>> Thanks >>> Isura. >>> >>> >>> Isura Dilhara Karunaratne >>> Senior Software Engineer >>> >>> Mob +94 772 254 810 >>> >>> >> >> >> -- >> Thanks & Regards, >> Dulanja Liyanage >> Lead, Platform Security Team >> WSO2 Inc. >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > Omindu Rathnaweera > Software Engineer, WSO2 Inc. > Mobile: +94 771 197 211 > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Regards, *Darshana Gunawardana*Associate Technical Lead WSO2 Inc.; http://wso2.com *E-mail: [email protected] <[email protected]>* *Mobile: +94718566859*Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
