Discussion:
pwdHistory, encrypted passwords and selfservice application
(too old to reply)
Bogdan Rudas
2015-10-29 10:18:02 UTC
Permalink
Raw Message
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
--
CONFIDENTIALITY NOTICE: This email and files attached to it are
confidential. If you are not the intended recipient you are hereby notified
that using, copying, distributing or taking any action in reliance on the
contents of this information is strictly prohibited. If you have received
this email in error please notify the sender and delete this email.
Dario Zanzico
2015-10-30 08:14:28 UTC
Permalink
Raw Message
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
2015-10-30 08:19:04 UTC
Permalink
Raw Message
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Clément OUDOT
2015-10-30 08:37:20 UTC
Permalink
Raw Message
Content preview: Le 29/10/2015 11:18, Bogdan Rudas a écrit : > Hello all,
Post by Bogdan Rudas
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? > [...]

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

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
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: ltb-project.org]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
X-BeenThere: openldap-***@openldap.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OpenLDAP Technical Discussion list <openldap-technical.openldap.org>
List-Unsubscribe: <http://www.openldap.org/lists/mm/options/openldap-technical>,
<mailto:openldap-technical-***@openldap.org?subject=unsubscribe>
List-Archive: <http://www.openldap.org/lists/openldap-technical/>
List-Post: <mailto:openldap-***@openldap.org>
List-Help: <mailto:openldap-technical-***@openldap.org?subject=help>
List-Subscribe: <http://www.openldap.org/lists/mm/listinfo/openldap-technical>,
<mailto:openldap-technical-***@openldap.org?subject=subscribe>
Errors-To: openldap-technical-***@openldap.org
Sender: "openldap-technical" <openldap-technical-***@openldap.org>
X-Spam-Score: -1.9 (-)
X-Spam-Report: Spam detection software, running on the system "gauss.openldap.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: Le 29/10/2015 11:18, Bogdan Rudas a écrit : > Hello all,
Post by Bogdan Rudas
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? > [...]

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

pts rule name description
---- ---------------------- --------------------------------------------------
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: ltb-project.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
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?
Hi,

just for information, if you are looking for a self service application,
you can check
http://ltb-project.org/wiki/documentation/self-service-password/latest/start

But as it is written in PHP, it does not use the ppolicy control (not
yet implemented in PHP-LDAP API).
--
Clément OUDOT
Consultant en logiciels libres, Expert infrastructure et sécurité
Savoir-faire Linux
Loading...