search

aoktox / pwm

Automatically exported from code.google.com/p/pwm
0 stars 0 forks source link

For openldap passwords are stored in cleartext #89

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
With openldap directory, passwords are stored in cleartext no matter how the 
server is configured. It is better to use LDAP Password Modify extended 
operation (RFC 3062) and let the server take care of which password-hash method 
to use instead of writing it in cleartext.

From what I have gathered by looking up the code, this is also the default 
behaviour for edirectory. I think password modify extended operation is 
supported by JNDIProviderImpl which is used when connecting to openldap.

Can you fix this or at least tell me how to fix it?

What steps will reproduce the problem?
1.Create a user or change a users password
2.Use an LDAP Browser to see the cleartext password
3.

What is the expected output? What do you see instead?

What version of PWM are you using?
Build directly from svn r196

What ldap directory and version are you using?
Openldap 2.4.23

Please paste any error log messages below:
2011-07-13 18:16:51, TRACE, pwm.SessionManager, {4~,ebayer} opened new ldap 
connection for cn=ebayer,ou=people,dc=turkuazlinux,dc=org (0ms) [192.168.122.1]
2011-07-13 18:16:51, TRACE, util.Helper, creating new chai provider using 
config of ChaiConfiguration: locked=false settings: 
{chai.bind.URLs=ldap://127.0.0.1:389,, 
chai.bind.dn=cn=ebayer,ou=people,dc=turkuazlinux,dc=org, 
chai.bind.password=**stripped**, chai.cache.enable=false, 
chai.cache.maximumSize=128, chai.cache.maximumAge=1000, 
chai.statistics.enable=true, chai.watchdog.enable=true, 
chai.watchdog.operationTimeout=60000, chai.watchdog.idleTimeout=60302, 
chai.connection.watchdog.frequency=60000, chai.connection.promiscuousSSL=false, 
chai.wireDebug.enable=false, chai.failover.enable=true, 
chai.failover.failBackTime=90000, chai.failover.connectRetries=4, 
chai.ldap.dereferenceAliases=never, chai.ldap.ldapTimeout=5000, 
chai.provider.implementation=com.novell.ldapchai.provider.JNDIProviderImpl, 
chai.edirectory.enableNMAS=true, 
chai.provider.extendedOperation.failureCache=true, 
chai.provider.readonly=false, chai.vendor.default=}
2011-07-13 18:16:51, TRACE, provider.JNDIProviderImpl, bind successful as 
cn=ebayer,ou=people,dc=turkuazlinux,dc=org (2ms)
2011-07-13 18:16:51, TRACE, provider.ChaiProviderFactory, adding 
WatchdogWrapper to provider instance
2011-07-13 18:16:51, DEBUG, provider.WatchdogWrapper, starting up LDAP Chai 
WatchdogWrapper timer thread, 60000ms check frequency
2011-07-13 18:16:51, TRACE, provider.ChaiProviderFactory, adding 
StatisticsWrapper to provider instance
2011-07-13 18:16:51, TRACE, pwm.UserStatusHelper, {4~,ebayer} beginning 
password status check process for cn=ebayer,ou=people,dc=turkuazlinux,dc=org 
[192.168.122.1]
2011-07-13 18:16:51, TRACE, pwm.UserStatusHelper, {4~,ebayer} password for 
cn=ebayer,ou=people,dc=turkuazlinux,dc=org does not appear to be expired 
[192.168.122.1]
2011-07-13 18:16:51, DEBUG, pwm.UserStatusHelper, {4~,ebayer} completed user 
password status check for cn=ebayer,ou=people,dc=turkuazlinux,dc=org 
PasswordStatus {expired=false, pre-expired=false, warn=false, 
violatesPolicy=false} (1ms) [192.168.122.1]
2011-07-13 18:16:51, DEBUG, util.Helper, {4~,ebayer} wrote pwdLastModified 
update attribute for cn=ebayer,ou=people,dc=turkuazlinux,dc=org [192.168.122.1]
2011-07-13 18:16:51, TRACE, pwm.PasswordUtility, {4~,ebayer} skipping 
replication checking, only one ldap server url is configured [192.168.122.1]
2011-07-13 18:16:51, TRACE, pwm.PasswordUtility, {4~,ebayer} waiting for 
minimum replication time of 5000ms.... [192.168.122.1]
2011-07-13 18:16:56, DEBUG, util.EmailQueueManager, discarding email send event 
(no SMTP server address configured) from: PWM Notification Agent 
<noreply@example.com>, to: ebayer@bayer.gen.tr, subject: Password Change 
Notification
2011-07-13 18:16:56, TRACE, pwm.PasswordUtility, no post change password actions
2011-07-13 18:16:56, ERROR, pwm.UserHistory, ldap error writing user event log: 
[LDAP: error code 18 - modify/delete: pwmEventLog: no equality matching rule]
2011-07-13 18:18:46, TRACE, pwm.SessionFilter, {4~,ebayer} GET request for: 
/pwm/public/Logout  [192.168.122.1]
  idle='true'

Original issue reported on code.google.com by erdem.ba...@gmail.com on 13 Jul 2011 at 4:49

GoogleCodeExporter commented 9 years ago 
There's been some discussion on the google groups about this.  If I recall, I 
believe there is a method to have OpenLDAP hash passwords using PWM as is.  I 
have no OpenLDAP experience myself so I can't be sure.

eDirectory and AD both allow the setting of encrypted/hashed passwords by 
writing to a pseudo attribute (userPassword in eDir, and unicodePwd).  

Additionally, I don't think all directories support RFC 3062.  A cursory google 
search suggests AD doesn't.

That being said, Id be happy to have PWM use any method appropriate for 
openLDAP.  It looks like you've already opened an issue for ldapChai, and that 
is the correct place for this topic.  The code change needs to happen there.

Original comment by jrivard on 13 Jul 2011 at 5:58

GoogleCodeExporter commented 9 years ago 
ldapChai issue:

http://code.google.com/p/ldapchai/issues/detail?id=3

Original comment by jrivard on 13 Jul 2011 at 5:58

GoogleCodeExporter commented 9 years ago 
I hate to be a pest, but has any work been done on this issue?  I know one of 
the devs was on vacation last week.   

I'm currently looking at PWM for a project I am working on with OpenLDAP.  The 
cleartext password is an showstopper for me. This is a for a security 
environment.  

Here is where I can help and tell you about OpenLDAP.  The userPassword 
attribute supports multiple types of password hashes, but most situation only 
use one.  If a user attempts to bind with a user that has mulitple userPassword 
entries, the server will test the password against all of them. OpenLDAP does 
not have any automatic hashing mechanism like many other directory servers do.  
If you want to set the user's password, you set it right to the userPassword 
attribute and the client sending data is responsible for hashing it.  

I made a table below to show you the format/values of the supported hashes in 
OpenLDAP 2.4.  

Method - userPassword Attribute Value
Cleartext       - password
SHA Hash        - {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
Seeded SHA Hash - {SSHA}vJrn9qrYggdj0QJLIWNR4Amu0Jde5wMJ
MD5 Hash        - {MD5}X03MO1qnZdYdgyfeuILPmQ==
Seed MD5 Hash   - {SMD5}/o3B0NC1u53FM9e0zpxfZmhxFo4=
Unix Crypt      - {CRYPT}tWmC4lbeo6RRY

Original comment by hydr...@gmail.com on 27 Jul 2011 at 7:17

GoogleCodeExporter commented 9 years ago 
No work has been done that I am aware of.  I'm not familiar with OpenLDAP and 
no one else has volunteered.

So I'm guessing the text to the right of the braces is base64 encoded version 
of the hash?   Is one of these methods more common then the other?

Is there a document somewhere that describes how to generate these values 
programatically?

Original comment by jrivard on 27 Jul 2011 at 7:31

GoogleCodeExporter commented 9 years ago 
I'm also confused by this discussion thread:

https://groups.google.com/forum/#!searchin/pwm-general/OpenLDAP$20hash/pwm-gener
al/3nIJPLhUM9s/-x70nhTw410J

That thread suggests that there is an OpenLDAP configuration which negates the 
need for this feature.

Original comment by jrivard on 27 Jul 2011 at 7:32

GoogleCodeExporter commented 9 years ago 
No the text to the right of the curly braces is the raw hash.  It is not 
base64.

Original comment by hydr...@gmail.com on 27 Jul 2011 at 7:43

GoogleCodeExporter commented 9 years ago 
I'm sorry.  You are correct.  It is base64ed.  Here is a link for how the raw 
password data is generated.  It is in perl, but I think is staight forward 
enough figure out what is going on.  

http://www.openldap.org/faq/data/cache/347.html

Original comment by hydr...@gmail.com on 27 Jul 2011 at 8:16

GoogleCodeExporter commented 9 years ago 
Also looking over the logs that erdem posted, everyone have to be careful with 
the ppolicy overlay.  If ppolicy (Password Policy) settings require certain 
number of characters or specific types, the ppolicy may block a hashed password 
as ppolicy is evaluated after the password has been hashed.

Original comment by hydr...@gmail.com on 27 Jul 2011 at 8:37

GoogleCodeExporter commented 9 years ago 
So does that mean this is still a worthwhile enhancement?

Original comment by jrivard on 28 Jul 2011 at 5:36

GoogleCodeExporter commented 9 years ago 
Absolutely.  You can enforce password policy in the password changing API. It 
doesn't have enforced at the LDAP server layer.   PWM does this quite well.  
Having static passwords in the clear goes against just about every security 
recommendation out there.  

I just mentioned the ppolicy issue to warn PWM/OpenLDAP implementers that they 
may have issues with ppolicy.  ppolicy is an optional addon to openldap.

Original comment by hydr...@gmail.com on 1 Aug 2011 at 6:22

GoogleCodeExporter commented 9 years ago 
I did not know ppolicy overlay is capable of hashing cleartext userPassword 
fields by default (thanks for pointing that out) . I tried now and am able to 
verify that all userPassword fields are stored as hash if ppolicy overlay is 
configured to do so. Therefore I do not think it is critical implementing 
openldap-exop in ldapchai.

That being said, I still think being able to use exop in chai is better. Since 
it is not that urgent, I will not dive into that soon, but it is definately on 
my to-do list.

Original comment by erdem.ba...@gmail.com on 3 Aug 2011 at 10:20

GoogleCodeExporter commented 9 years ago 
My evaluation of pwm came to a halt when I discovered this "feature". ;) 
otherwise, I enjoyed using it.

Original comment by gy...@modeln.com on 8 Mar 2012 at 10:43

GoogleCodeExporter commented 9 years ago 
Is there some reason you can't use the open ldap ppolicy feature?  It is still 
amazing to me that openldap doesn't handle encryption by default itself.

Original comment by jrivard on 8 Mar 2012 at 10:46

GoogleCodeExporter commented 9 years ago 
Yeah, this is a show-stopper for using PWM.

Original comment by nick.e.c...@gmail.com on 2 May 2012 at 5:48

GoogleCodeExporter commented 9 years ago 
nick, I found a workaround at 
http://ltb-project.org/wiki/documentation/self-service-password

I tried it and it works quite well, so I went ahead and deployed it in to our 
production environment.

Original comment by gy...@modeln.com on 2 May 2012 at 6:21

GoogleCodeExporter commented 9 years ago 
ppolicy works fine ...

for the following error :

2011-07-13 18:16:56, ERROR, pwm.UserHistory, ldap error writing user event log: 
[LDAP: error code 18 - modify/delete: pwmEventLog: no equality matching rule]

add the following line to  pwm.schema:  EQUALITY octetStringMatch

attributetype ( 1.3.6.1.4.1.591242.2.2010.04.16.1
        NAME 'pwmEventLog'
        EQUALITY octetStringMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
attributetype ( 1.3.6.1.4.1.591242.2.2010.04.16.2
        NAME 'pwmResponseSet'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 
         )
attributetype ( 1.3.6.1.4.1.591242.2.2010.04.16.3
        NAME 'pwmLastPwdUpdate'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
attributetype ( 1.3.6.1.4.1.591242.2.2010.04.16.4
        NAME 'pwmGUID'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
objectclass ( 1.3.6.1.4.1.591242.1.2010.04.16.1
        NAME 'pwmUser'
        AUXILIARY
        MAY ( pwmLastPwdUpdate $ pwmEventLog $ pwmResponseSet $ pwmGUID ) )

Original comment by ben.said...@litens.com on 22 May 2012 at 6:46

GoogleCodeExporter commented 9 years ago 
I made a patch for ldapchai to make use of exop. Tested against the pwm 1.6.3 
and openldap 2.4.23. Please see

http://code.google.com/p/ldapchai/issues/detail?id=3#c3

Original comment by ipaq3...@gmail.com on 14 Aug 2012 at 2:30

GoogleCodeExporter commented 9 years ago 
I am using apache ds, also noticed that password is changed to cleartext. Would 
be great to have this feature

Original comment by kayrox...@gmail.com on 13 Oct 2012 at 1:22

GoogleCodeExporter commented 9 years ago 
@18: see 
https://cwiki.apache.org/DIRxSRVx11/62-implementing-a-simple-custom-interceptor.
html#6.2.ImplementingasimplecustomInterceptor-Passwordhash.Asimpleinterceptor

@17: Exop has been implemented a while ago in the current source tree; try a 
nightly build.

Original comment by menno.pi...@gmail.com on 23 May 2013 at 7:48

GoogleCodeExporter commented 9 years ago 
Doesn't the schema file require an .LDIF to base it off of?  Or can a schema 
file be included by itself?  Trying to figure out my own issue.

Regards,

Eric

Original comment by sinist...@gmail.com on 17 Jul 2013 at 5:21

GoogleCodeExporter commented 9 years ago 
Issue 452 has been merged into this issue.

Original comment by jrivard on 19 Aug 2013 at 3:23