pwdHistory, encrypted passwords and selfservice application

[Bogdan Rudas]

Hello all,

I'm working on Self-service application and want to prevent user from
re-using old passwords. What is correct way to chage password takin in mind
password history?

I guess it is:

1. Bind with special user and check if specified uid exists
2. Bind using user-supplied uid and password
3. Get password policy, history etc. and validate on selfservice-side
4. Execute LDAP modifyRequest with single item: userPassword and value of
new hashed password.


In my case same password gives same hash. Are there any way to force
encrypted password history validation on server side?

Thank you.
--
Bogdan Rudas
Head of Minsk IT Support Department
Exadel Inc.
http://www.exadel.com/
E-mail: ***@exadel.com <***@exadel.com>
Skype ID: bogdan.rudas

[Dario Zanzico]

Content preview: On Thu, Oct 29, 2015, at 11:18 AM, Bogdan Rudas wrote: > Hello
all, > I'm working on Self-service application and want to prevent user from

Post by Bogdan Rudas
re-using old passwords. What is correct way to chage password takin in
mind > password history? > > I guess it is: > 1. Bind with special user

and check if specified uid exists > 2. Bind using user-supplied uid and password

Post by Bogdan Rudas
3. Get password policy, history etc. and validate on selfservice-side >

4. Execute LDAP modifyRequest with single item: userPassword and value of

Post by Bogdan Rudas
new hashed password. > > In my case same password gives same hash. Are

there any way to force > encrypted password history validation on server side?
[...]

Content analysis details: (-1.9 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[66.111.4.28 listed in list.dnswl.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: messagingengine.com]
0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature

Post by Bogdan Rudas
Hello all,
I'm working on Self-service application and want to prevent user from
re-using old passwords. What is correct way to chage password takin in mind
password history?
1. Bind with special user and check if specified uid exists
2. Bind using user-supplied uid and password
3. Get password policy, history etc. and validate on selfservice-side
4. Execute LDAP modifyRequest with single item: userPassword and value of
new hashed password.
In my case same password gives same hash. Are there any way to force
encrypted password history validation on server side?

you could leave points 3 and 4 to a ppolicy overlay (server side)
http://www.openldap.org/doc/admin24/overlays.html (12.10)

You should set, in your policy(es), the
olcPPolicyHashCleartext
attribute to true and send the new password as cleartext so the overlay
can test it against your requisites and, if those checks are successful:
- encrypt it
- rotate the pwdHistory attributes (which stores the last $pwdInHistory
password hashes)

take a look at the slapo-ppolicy manpage

Post by Bogdan Rudas
Thank you.
--
Bogdan Rudas

hope this helps,

dario zanzico

[Howard Chu]

Content preview: Dario Zanzico wrote: > On Thu, Oct 29, 2015, at 11:18 AM,
Bogdan Rudas wrote: >> Hello all, >> I'm working on Self-service application
and want to prevent user from >> re-using old passwords. What is correct
way to chage password takin in >> mind >> password history? >> >> I guess
it is: >> 1. Bind with special user and check if specified uid exists >> 2.
Bind using user-supplied uid and password >> 3. Get password policy, history
etc. and validate on selfservice-side >> 4. Execute LDAP modifyRequest with
single item: userPassword and value of >> new hashed password. >> >> In my
case same password gives same hash. Are there any way to force >> encrypted
password history validation on server side? > > you could leave points 3
and 4 to a ppolicy overlay (server side) > http://www.openldap.org/doc/admin24/overlays.html
(12.10) > > You should set, in your policy(es), the > olcPPolicyHashCleartext

Post by Dario Zanzico
attribute to true and send the new password as cleartext so the overlay
- encrypt it > - rotate the pwdHistory attributes (which stores the last

$pwdInHistory > password hashes) > > take a look at the slapo-ppolicy manpage
[...]

Content analysis details: (-4.2 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[69.43.206.106 listed in list.dnswl.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: highlandsun.com]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]

Post by Dario Zanzico

Post by Bogdan Rudas
Hello all,
I'm working on Self-service application and want to prevent user from
re-using old passwords. What is correct way to chage password takin in mind
password history?
1. Bind with special user and check if specified uid exists
2. Bind using user-supplied uid and password
3. Get password policy, history etc. and validate on selfservice-side
4. Execute LDAP modifyRequest with single item: userPassword and value of
new hashed password.
In my case same password gives same hash. Are there any way to force
encrypted password history validation on server side?

you could leave points 3 and 4 to a ppolicy overlay (server side)
http://www.openldap.org/doc/admin24/overlays.html (12.10)
You should set, in your policy(es), the
olcPPolicyHashCleartext
attribute to true and send the new password as cleartext so the overlay
- encrypt it
- rotate the pwdHistory attributes (which stores the last $pwdInHistory
password hashes)
take a look at the slapo-ppolicy manpage

ppolicyHashCleartext is a kludge. The correct approach is to use the
passwordModify operation.

[Clément OUDOT]

This post might be inappropriate. Click to display it.