Bug 759276 - setpin doesn't work if you use not dn as salt attribute
Summary: setpin doesn't work if you use not dn as salt attribute
Keywords:
Status: CLOSED EOL
Alias: None
Product: Dogtag Certificate System
Classification: Retired
Component: Tools - Native
Version: 1.2
Hardware: i386
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Matthew Harmsen
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On: 530474
Blocks: 760378
TreeView+ depends on / blocked
 
Reported: 2011-12-01 20:58 UTC by bbonok
Modified: 2020-03-27 18:36 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 760378 (view as bug list)
Environment:
Last Closed: 2020-03-27 18:36:34 UTC


Attachments (Terms of Use)

Description bbonok 2011-12-01 20:58:56 UTC
Description of problem:
setpin doesn't work if you use not dn as salt attribute if you use hash.

How reproducible:
set saltattribute of setpin that setpin doesn't use default. the user can't
authenticate to create certificate request.

Steps to Reproduce:
1. Use input file to set not automatic generated pins
2. Execute setpin with saltattribute 
3. Try user to authenticate with generated pin
  
Actual results:
user isn't authenticated

Expected results:
user have authenticated

Additional info: (in setpin.c)

on row 764 : saltval = vals[0] // saltval is value in attribute
on row 806 : ldap_value_free( vals );  // memory is freed. saltval points to uninitialized memory(something)
on row 868 : strcpy(hashbuf_source,saltval); // making hash with saltvalue points to something(not value in LDAP attribute)

This bug is also in pki-native-tools-8.0 (from RHCS 8.0)

Comment 1 Matthew Harmsen 2011-12-05 23:07:41 UTC
The setpin documentation for RHCS 8.1 (http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/8.1/html/Command-Line_Tools_Guide/PIN_Generator.html) states the following about 'hash':

    Specifies the message digest algorithm with which to hash the PINs 
    before storing them in the authentication directory.

    NOTE:  This should be set to none (which does not hash PINs) because the
           Directory Server may have restrictions on incoming hashed passwords.

    The default is sha1, which produces a 160-bit message digest. md5 produces
    a 128-bit message digest. none does not hash the PINs. 

while the same documentation states the following about 'saltattribute':

    Specifies the LDAP attribute to use for salt creation. If an attribute is
    set, the tool integrates the value of the attribute with each PIN and hashes
    the resulting string with the hash routine. The default is to use the entry
    DN. For details, refer to Section 5.2.3, “How PINs Are Stored in the
    Directory”.

Therefore, if there is a bug in the code, it would be that if 'hash=none', then
the 'saltattribute' should be ignored (e. g. - that the entry DN will always be utilized).

Additionally, it may be beneficial to document that the use of the 'saltattribute' is not useful with the documented preference of 'hash=none' is being used with directory servers which restrict the use of incoming hashed passwords (e. g. - 389, RHDS, etc.).


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