This is a multi-part message in MIME format. --------------618A3E9CC74C1DE7FC603227 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit
I also tried with '-n' for slappasswd, in the test below, for '-T' and '-s' cases. It changed nothing. On 12/12/2019 14:59, Antoine Tran wrote: > On 12/12/2019 14:02, Howard Chu wrote: >> [email protected] wrote: >>> Full_Name: Antoine TRAN >>> Version: openldap-servers-2.4.44-21.el7_6.x86_64 >>> OS: CentOS Linux release 7.7.1908 (Core) >>> URL:ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (213.190.88.94) >>> >>> >>> I use slappasswd to generate SSHA password. The issue is it behavior is >>> different whether I submit the password - in stdin or in command-line '-s' >>> - and >>> from a secret file '-T'. Command: >>> slappasswd -h {SSHA} >>> => write 'd' twice as password >>> slappasswd -h {SSHA} -s d >>> >>> provides working SSHA. >>> >>> But: >>> echo d >/run/secrets/rootpw >>> slappasswd -h {SSHA} -T /run/secrets/rootpw >>> provides a valid SSHA, but that does not match the password. >>> >>> My multiple test are done by replacing rootpw in /etc/openldap/slapd.conf, >>> regenerating with: >>> systemctl stop slapd >>> sed -i -e "s,rootpw .*\$,rootpw ${ROOTPW_HASH},g" /etc/openldap/slapd.conf >>> slapcat -n 0 -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d >>> systemctl start slapd >>> ldapsearch -D "${ROOTDN}" -w "${ROOTPW}" >>> >>> The content of the secret file can be "d" or "d\n", it does not make a >>> difference. Also, if I change the schema from SSHA to just a fixed salt, the >>> '-T' seems to work as expected: >>> (a) slappasswd -c 123 >>> => write d twice >>> (b) slappasswd -c 123 -s 123 >>> (c) slappasswd -c 123 -T /run/secrets/rootpw >>> >>> (a), (b) and (c) gives the exact same hash. But I cannot put a fixed salt >>> and >>> use SSHA, slappasswd prevents me from that, with an error schema already >>> provided. >> Unable to reproduce, SSHA works fine here. >> >> Obviously you can't use a fixed salt with SSHA, that's the point of its salt >> is to >> be random and different every time. > I wanted to override the salt as a test, to check if we have the same > output with a file and in command-line. But I found another way to test. >> When using a password in a file you must ensure the trailing '\n' is >> omitted. This >> is already documented in the manpage. > > I did read and checked this point. I have written that I did not have > a newline. But here is a simple and reproducible test, that took me > some long time. In a Linux machine with internet, just copy paste this: > > docker run --name slappasswd --rm -ti centos:7 bash > > yum install openldap-servers -y > > cat <<EOF >/makeSecret.py > import os > import sys > import hashlib > from base64 import urlsafe_b64encode as encode > from base64 import urlsafe_b64decode as decode > > def makeSecret(password): > Â Â Â salt = os.urandom(4) > Â Â Â h = hashlib.sha1(password) > Â Â Â h.update(salt) > Â Â Â return "{SSHA}" + encode(h.digest() + salt) > > if __name__ == '__main__': > Â Â Â print(makeSecret(sys.argv[1])) > EOF > > cat <<EOF >/checkPassword.py > import os > import sys > import hashlib > from base64 import urlsafe_b64encode as encode > from base64 import urlsafe_b64decode as decode > > def checkPassword(challenge_password, password): > Â Â Â challenge_bytes = decode(challenge_password[6:]) > Â Â Â digest = challenge_bytes[:20] > Â Â Â salt = challenge_bytes[20:] > Â Â Â hr = hashlib.sha1(password) > Â Â Â hr.update(salt) > Â Â Â return digest == hr.digest() > > if __name__ == '__main__': > Â Â Â print(checkPassword(sys.argv[1], sys.argv[2])) > EOF > > python /checkPassword.py $(python /makeSecret.py d) d > > python /checkPassword.py $(slappasswd -s d) d > > mkdir -p /run/secrets/ > echo d>/run/secrets/rootpw > python /checkPassword.py $(slappasswd -T /run/secrets/rootpw) d > echo Begin-$(cat /run/secrets/rootpw)-End > # => shows no newline: > #Begin-d-End > > It will show you that all hash works except the part with slappasswd > -T, and I checked the newline. > >>> I saw the same issue in another openldap mail: >>> https://www.openldap.org/lists/openldap-software/200805/msg00060.html but >>> no >>> answer. >>> >>> --------------618A3E9CC74C1DE7FC603227 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <p>I also tried with '-n' for slappasswd, in the test below, for '-T' and '-s' cases. It changed nothing.<br> </p> <p>On 12/12/2019 14:59, Antoine Tran wrote:</p> <blockquote type="cite" cite="mid:[email protected]"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> On 12/12/2019 14:02, Howard Chu wrote:<br> <blockquote type="cite" cite="mid:[email protected]"> <pre class="moz-quote-pre" wrap=""><a class="moz-txt-link-abbreviated" href="mailto:[email protected]"; moz-do-not-send="true">[email protected]</a> wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Full_Name: Antoine TRAN Version: openldap-servers-2.4.44-21.el7_6.x86_64 OS: CentOS Linux release 7.7.1908 (Core) URL: <a class="moz-txt-link-freetext" href="ftp://ftp.openldap.org/incoming/"; moz-do-not-send="true">ftp://ftp.openldap.org/incoming/</a> Submission from: (NULL) (213.190.88.94) I use slappasswd to generate SSHA password. The issue is it behavior is different whether I submit the password - in stdin or in command-line '-s' - and from a secret file '-T'. Command: slappasswd -h {SSHA} => write 'd' twice as password slappasswd -h {SSHA} -s d provides working SSHA. But: echo d >/run/secrets/rootpw slappasswd -h {SSHA} -T /run/secrets/rootpw provides a valid SSHA, but that does not match the password. My multiple test are done by replacing rootpw in /etc/openldap/slapd.conf, regenerating with: systemctl stop slapd sed -i -e "s,rootpw .*\$,rootpw ${ROOTPW_HASH},g" /etc/openldap/slapd.conf slapcat -n 0 -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d systemctl start slapd ldapsearch -D "${ROOTDN}" -w "${ROOTPW}" The content of the secret file can be "d" or "d\n", it does not make a difference. Also, if I change the schema from SSHA to just a fixed salt, the '-T' seems to work as expected: (a) slappasswd -c 123 => write d twice (b) slappasswd -c 123 -s 123 (c) slappasswd -c 123 -T /run/secrets/rootpw (a), (b) and (c) gives the exact same hash. But I cannot put a fixed salt and use SSHA, slappasswd prevents me from that, with an error schema already provided. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">Unable to reproduce, SSHA works fine here. Obviously you can't use a fixed salt with SSHA, that's the point of its salt is to be random and different every time.</pre> </blockquote> I wanted to override the salt as a test, to check if we have the same output with a file and in command-line. But I found another way to test.<br> <blockquote type="cite" cite="mid:[email protected]"> <pre class="moz-quote-pre" wrap="">When using a password in a file you must ensure the trailing '\n' is omitted. This is already documented in the manpage.</pre> </blockquote> <p>I did read and checked this point. I have written that I did not have a newline. But here is a simple and reproducible test, that took me some long time. In a Linux machine with internet, just copy paste this:</p> <blockquote> <p>docker run --name slappasswd --rm -ti centos:7 bash<br> <br> yum install openldap-servers -y<br> <br> cat <<EOF >/makeSecret.py<br> import os<br> import sys<br> import hashlib<br> from base64 import urlsafe_b64encode as encode<br> from base64 import urlsafe_b64decode as decode<br> <br> def makeSecret(password):<br> Â Â Â salt = os.urandom(4)<br> Â Â Â h = hashlib.sha1(password)<br> Â Â Â h.update(salt)<br> Â Â Â return "{SSHA}" + encode(h.digest() + salt)<br> <br> if __name__ == '__main__':<br> Â Â Â print(makeSecret(sys.argv[1]))<br> EOF<br> <br> cat <<EOF >/checkPassword.py<br> import os<br> import sys<br> import hashlib<br> from base64 import urlsafe_b64encode as encode<br> from base64 import urlsafe_b64decode as decode<br> <br> def checkPassword(challenge_password, password):<br> Â Â Â challenge_bytes = decode(challenge_password[6:])<br> Â Â Â digest = challenge_bytes[:20]<br> Â Â Â salt = challenge_bytes[20:]<br> Â Â Â hr = hashlib.sha1(password)<br> Â Â Â hr.update(salt)<br> Â Â Â return digest == hr.digest()<br> <br> if __name__ == '__main__':<br> Â Â Â print(checkPassword(sys.argv[1], sys.argv[2]))<br> EOF<br> <br> python /checkPassword.py $(python /makeSecret.py d) d<br> <br> python /checkPassword.py $(slappasswd -s d) d<br> <br> mkdir -p /run/secrets/<br> echo d>/run/secrets/rootpw<br> python /checkPassword.py $(slappasswd -T /run/secrets/rootpw) d<br> echo Begin-$(cat /run/secrets/rootpw)-End<br> # => shows no newline:<br> #Begin-d-End<br> </p> </blockquote> <p>It will show you that all hash works except the part with slappasswd -T, and I checked the newline.<br> <br> </p> <blockquote type="cite" cite="mid:[email protected]"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">I saw the same issue in another openldap mail: <a class="moz-txt-link-freetext" href="https://www.openldap.org/lists/openldap-software/200805/msg00060.html"; moz-do-not-send="true">https://www.openldap.org/lists/openldap-software/200805/msg00060.html</a> but no answer. </pre> </blockquote> </blockquote> </blockquote> </body> </html> --------------618A3E9CC74C1DE7FC603227--
