Bug 759276

Summary:	setpin doesn't work if you use not dn as salt attribute
Product:	[Retired] Dogtag Certificate System	Reporter:	bbonok
Component:	Tools - Native	Assignee:	Matthew Harmsen <mharmsen>
Status:	CLOSED EOL	QA Contact:	Ben Levenson <benl>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	1.2	CC:	alee, cfu, dlackey, dpal, jmagne, nkinder
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	760378 (view as bug list)		Environment:
Last Closed:	2020-03-27 18:36:34 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:	530474
Bug Blocks:	760378

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.).