Bug 653007

Created attachment 471975 [details]
git patch file (master)

Description: When passwordStorageScheme is clear, db2ldif{.pl}
exports clear text passwords without the storage scheme name
{CLEAR}.  This patch fixes it:
    userPassword: {CLEAR}notsosecret

Created attachment 472112 [details]
revised git patch file (master)

Thanks to Nathan for his comment on my previous review request.

I modified the patch following his suggestion.

Created attachment 472145 [details]
yet another revised git patch (master)

Discussed with Nathan and removed the "passwordStorageScheme" check.  My previous proposals added "{CLEAR}" only when the global passwordStorageScheme was "clear" and passwords were not hashed.  This did not cover some cases such as the global passwordStorageScheme was not clear and a fine grained password policy was.

This revised patch checks every userPassword value regardless of the password scheme and put "{CLEAR}" if the value is not hashed.

Comment on attachment 472145 [details]
yet another revised git patch (master)

How do you know the password is encoded in clear if there is no storage scheme in the password?

(In reply to comment #6)
> Comment on attachment 472145 [details]
> yet another revised git patch (master)
> 
> How do you know the password is encoded in clear if there is no storage scheme
> in the password?

The patch relies on the API slapi_is_encoded.  The API returns it's not hashed if there is no "{SCHEME}" is found.  That is, if db2ldif finds an userPassword with no "{SCHEME}", it always adds "{CLEAR}".  Do you think it could cause any problem?

(In reply to comment #7)
> (In reply to comment #6)
> > Comment on attachment 472145 [details]
> > yet another revised git patch (master)
> > 
> > How do you know the password is encoded in clear if there is no storage scheme
> > in the password?
> 
> The patch relies on the API slapi_is_encoded.  The API returns it's not hashed
> if there is no "{SCHEME}" is found.  That is, if db2ldif finds an userPassword
> with no "{SCHEME}", it always adds "{CLEAR}".  Do you think it could cause any
> problem?

Ok.  So if the password is hashed, the server code will guarantee that it has a {SCHEME} prefix, and if there is no prefix, it is clear.  Looks good.

Thanks to Nathan and Rich for the discussions and reviews!

Pushed to master.

$ git merge 653007
Updating 8c30b05..3c021b2
Fast-forward
 ldap/servers/slapd/back-ldbm/ldif2ldbm.c |   26 ++++++++++++++++++++++++++
 1 files changed, 26 insertions(+), 0 deletions(-)
$ git push
Counting objects: 13, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 1.25 KiB, done.
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   8c30b05..3c021b2  master -> master

Steps to verify.
1. stop the server and set the following config param to cn=config
   passwordStorageScheme: clear
2. import an ldif file which contains at least one entry having userPassword
3. start the server and add at least one entry having userPassword
4. stop the server and remove the passwordStorageScheme
5. start the server and add at least one entry having userPassword
6. run the export utility db2ldif
7. check the exported ldif file
   * entries imported in (2) and added in (3) should have the userPassword:
     {CLEAR}clear_password_string
   * entries added in (5) should have the userPassword:
     {SSHA}hashed_password_string

1. stop the server and set the following config param to cn=config
   passwordStorageScheme: clear

ldapmodify -x -h localhost -p 389 -D "cn=directory manager" -w Secret123 << EOF
> dn: cn=config
> changetype: modify
> replace: passwordStorageScheme
> passwordStorageScheme: clear
> EOF
modifying entry "cn=config"


Not as expected when added from console :
1. this entry was with passwordStorageScheme: clear
# entry-id: 3
dn: uid=aams,ou=people,dc=example,dc=com
nsUniqueId: 9a35c601-981711e0-bedb997a-dc2554a2
uid: aams
givenName: ams
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: ams
cn: ams ams
creatorsName: cn=directory manager
modifiersName: cn=directory manager
createTimestamp: 20110616125319Z
modifyTimestamp: 20110616125319Z
userPassword:: e0NMRUFSfWFtcw==

2. This is without passwordStorageScheme: clear
# entry-id: 4
dn: uid=aami,ou=people,dc=example,dc=com
nsUniqueId: b5a0d1b5-981711e0-bedb997a-dc2554a2
uid: aami
givenName: ami
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: ami
cn: ami ami
userPassword:: e1NTSEF9Y0t4bnVWRk5SUHhKeVZvbVA4V2hpYVZBVW5TT2pCNWNaUFJkV2c9PQ=
 =
creatorsName: cn=directory manager
modifiersName: cn=directory manager
createTimestamp: 20110616125413Z
modifyTimestamp: 20110616125413Z

Trying with ldapadd:
========================
[root@rhel61 slapd-rhel61]# service dirsrv start
Starting dirsrv: 
    rhel61...                                              [  OK  ]
[root@rhel61 slapd-rhel61]# ldapmodify -x -h localhost -p 389 -D "cn=directory manager" -w Secret123 << EOF
dn: cn=config
changetype: modify
replace: passwordStorageScheme
passwordStorageScheme: clear
EOF
modifying entry "cn=config"

[root@rhel61 slapd-rhel61]# service dirsrv restart
Shutting down dirsrv: 
    rhel61...                                              [  OK  ]
Starting dirsrv: 
    rhel61...                                              [  OK  ]
[root@rhel61 slapd-rhel61]# ldapadd -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123  << EOF
> dn: uid=amsharma1,ou=people,dc=example,dc=com
> cn: amsharma
> sn: amsharma
> givenname: amsharma
> objectclass: top
> objectclass: person
> objectclass: organizationalPerson
> objectclass: inetOrgPerson
> uid: amsharma
> mail: ams
> userpassword: amsamsams
> EOF
adding new entry "uid=amsharma1,ou=people,dc=example,dc=com"

[root@rhel61 slapd-rhel61]# service dirsrv stop
Shutting down dirsrv: 
    rhel61...                                              [  OK  ]
[root@rhel61 slapd-rhel61]# pwd
/usr/lib64/dirsrv/slapd-rhel61
[root@rhel61 slapd-rhel61]# ./db2ldif -n exapledb -a /usr/lib64/dirsrv/slapd-rhel61/export.ldif
Exported ldif file: /usr/lib64/dirsrv/slapd-rhel61/export.ldif
ldiffile: /usr/lib64/dirsrv/slapd-rhel61/export.ldif
[16/Jun/2011:18:33:15 +051800] - export exapledb: Processed 6 entries (100%).
[16/Jun/2011:18:33:15 +051800] - All database threads now stopped

vim /usr/lib64/dirsrv/slapd-rhel61/export.ldif
# entry-id: 6
dn: uid=amsharma1,ou=people,dc=example,dc=com
nsUniqueId: aa9a7135-981811e0-bedb997a-dc2554a2
cn: amsharma
sn: amsharma
givenName: amsharma
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: amsharma
uid: amsharma1
mail: ams
creatorsName: cn=directory manager
modifiersName: cn=directory manager
createTimestamp: 20110616130100Z
modifyTimestamp: 20110616130100Z
userPassword:: e0NMRUFSfWFtc2Ftc2Ftcw==

# entry-id: 7
dn: uid=sghai1,ou=people,dc=example,dc=com
nsUniqueId: d0c01135-981811e0-bedb997a-dc2554a2
cn: sghai
sn: sghai
givenName: sghai
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: sghai
uid: sghai1
mail: sghai
userPassword:: e1NTSEF9bVZpM2x6OVgyQWtEMWJURk9STFFnOTdaTTdkOEVrdUJSekhCOGc9PQ=
 =
creatorsName: cn=directory manager

I think this is working as expected:

python
>>> import base64
>>> base64.b64decode('e0NMRUFSfWFtcw==')
'{CLEAR}ams'
>>> base64.b64decode('e1NTSEF9Y0t4bnVWRk5SUHhKeVZvbVA4V2hpYVZBVW5TT2pCNWNaUFJkV2c9PQ==')
'{SSHA}cKxnuVFNRPxJyVomP8WhiaVAUnSOjB5cZPRdWg=='
>>> base64.b64decode('e0NMRUFSfWFtc2Ftc2Ftcw==')
'{CLEAR}amsamsams'
>>> base64.b64decode('e1NTSEF9bVZpM2x6OVgyQWtEMWJURk9STFFnOTdaTTdkOEVrdUJSekhCOGc9PQ==')
'{SSHA}mVi3lz9X2AkD1bTFORLQg97ZM7d8EkuBRzHB8g=='

ok, I thought It will give me the password in clear text on tty.
That said marking it as VERIFIED.