Bug 653007 - db2ldif export of clear text passwords lacks storage scheme
Summary: db2ldif export of clear text passwords lacks storage scheme
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Database - Import/Export
Version: 1.2.6
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 639035 389_1.2.8
TreeView+ depends on / blocked
 
Reported: 2010-11-14 03:59 UTC by mheiges
Modified: 2015-12-07 16:30 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-12-07 16:30:46 UTC
Embargoed:


Attachments (Terms of Use)
git patch file (master) (2.78 KB, patch)
2011-01-06 01:54 UTC, Noriko Hosoi
no flags Details | Diff
revised git patch file (master) (2.79 KB, patch)
2011-01-06 18:37 UTC, Noriko Hosoi
rmeggins: review+
Details | Diff
yet another revised git patch (master) (2.32 KB, patch)
2011-01-06 22:13 UTC, Noriko Hosoi
nhosoi: review?
rmeggins: review+
Details | Diff

Description mheiges 2010-11-14 03:59:42 UTC
Description of problem:

db2ldif exports clear text passwords without the storage scheme,
  userPassword: notsosecret

Instead of 
  userPassword: {CLEAR}notsosecret
as the db2ldif from  fedora-ds-1.0.4 did.

If the exported ldif file is re-imported without the {CLEAR} storage scheme, the clear text password becomes encrypted.

Version-Release number of selected component (if applicable):
389-ds-base-1.2.6.1-2.el5


How reproducible:
always

Steps to Reproduce:
1. Add user with userPassword: {CLEAR}notsosecret
2. db2ldif -n userRoot


  
Actual results:

ldif with
  userPassword: notsosecret

Expected results:

ldif with
  userPassword: {CLEAR}notsosecret

Additional info:

Comment 3 Noriko Hosoi 2011-01-06 01:54:05 UTC
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

Comment 4 Noriko Hosoi 2011-01-06 18:37:58 UTC
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.

Comment 5 Noriko Hosoi 2011-01-06 22:13:59 UTC
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 6 Rich Megginson 2011-01-06 22:21:32 UTC
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?

Comment 7 Noriko Hosoi 2011-01-06 22:37:01 UTC
(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?

Comment 8 Rich Megginson 2011-01-06 22:44:46 UTC
(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.

Comment 9 Noriko Hosoi 2011-01-06 22:52:37 UTC
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

Comment 10 Noriko Hosoi 2011-01-06 22:53:45 UTC
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

Comment 11 Amita Sharma 2011-06-16 13:04:35 UTC
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

Comment 12 Rich Megginson 2011-06-16 15:07:57 UTC
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=='

Comment 13 Amita Sharma 2011-06-17 06:45:43 UTC
ok, I thought It will give me the password in clear text on tty.
That said marking it as VERIFIED.


Note You need to log in before you can comment on or make changes to this bug.