It is an edge case but some implementations of password policy checks will have response timing differences depending on which rules are being tripped. That way you can possibly discount a lot of passwords. eg if you get a quicker no by not using special chars than if you have special chars then chances are that special chars are required.

I do accept that this is pretty extreme and you have to be pretty close to the server to detect those time intervals. The main use case is to stop a user changing their password as many times as the history allows and then immediately setting it back to the original one.


Kevin Thorpe
VP Enterprise Platform


T: +44 (0)20 3005 6750  | F: +44(0)20 7730 2635  | T: +44 (0)808 204 0344 
150 Buckingham Palace Road, London, SW1W 9TR, UK 

               

SAVE PAPER - THINK BEFORE YOU PRINT!

____________________________________________________________________

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.


On 22 March 2016 at 16:44, Stian Thorgersen <sthorger@redhat.com> wrote:

Why is it an issue that someone can sniff the password policy? Is it that would make it slightly easier to guess passwords?

On 22 Mar 2016 10:09, "Kevin Thorpe" <kevin.thorpe@p-i.net> wrote:
As Stefan has already said one thing is to stop people changing their password and putting it straight back. Also for some implementations it's possible to repeatedly change passwords mechanically and sniff timings to get an idea of the implementation of the password check policy. In my case it's simply that we have a large prospective clients who specifically requested this functionality.


Kevin Thorpe
VP Enterprise Platform


T: +44 (0)20 3005 6750  | F: +44(0)20 7730 2635  | T: +44 (0)808 204 0344 
150 Buckingham Palace Road, London, SW1W 9TR, UK 

               

SAVE PAPER - THINK BEFORE YOU PRINT!

____________________________________________________________________

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.


On 18 March 2016 at 11:58, Stian Thorgersen <sthorger@redhat.com> wrote:

Seems like a strange requirement. I can see why you would want users to update the password frequently, not the other way around. Or is there something I'm missing?

Password policy will be made an spi in the future. That will make it easy to do, but it's not going to be done for a little while.

On 18 Mar 2016 10:10, "Marek Posolda" <mposolda@redhat.com> wrote:
Btv. Kevin you are using LDAP/MSAD right? If you have writable LDAP, then for the LDAP users, you can create custom LDAP Mapper implementation, which will implement "proxy" method and override "updateCredential" method of the proxy user object. Here you can
implement this functionality by yourself (MSAD has pwdLastSet attribute with the time when password was updated for last time)

Marek

On 18/03/16 10:04, Marek Posolda wrote:
Hi,

this is not available right now. It can be achieved with password policy, but we don't have such a password policy right now. We can either:
- Add the password policy to have this available in Keycloak OOTB
- Make PasswordPolicy pluggable SPI, so you can add your custom password policy for the functionality like this.

Feel free to create JIRA for this.

Marek

On 16/03/16 15:02, Kevin Thorpe wrote:
A standard practice for login systems is to stop users changing their passwords too often. Keycloak does not support this as of 1.7.0. Is there a possibility of adding a timeout to stop too frequent password changes?


Kevin Thorpe
VP Enterprise Platform


T: +44 (0)20 3005 6750  | F: +44(0)20 7730 2635  | T: +44 (0)808 204 0344 
150 Buckingham Palace Road, London, SW1W 9TR, UK 

               

SAVE PAPER - THINK BEFORE YOU PRINT!

____________________________________________________________________

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.



_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user



_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user