Re: (ITS#9137) slappasswd generate wrong SSHA from file

[antoine.tran@thales-services.fr]

This is a multi-part message in MIME format.
--------------0657C2ED691C0A313ADDDE9F
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 12/12/2019 14:02, Howard Chu wrote:
> antoine.tran@thales-services.fr 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.
>>
>>
>

--------------0657C2ED691C0A313ADDDE9F
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">
    On 12/12/2019 14:02, Howard Chu wrote:<br>
    <blockquote type="cite"
      cite="mid:c5070626-b60e-28f5-38a3-7871c8a0cbec@symas.com">
      <pre class="moz-quote-pre" wrap=""><a class="moz-txt-link-abbreviated" href="mailto:antoine.tran@thales-services.fr";>antoine.tran@thales-services.fr</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/";>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}
=&gt; write 'd' twice as password
slappasswd -h {SSHA} -s d

provides working SSHA.

But:
echo d &gt;/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
=&gt; 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:c5070626-b60e-28f5-38a3-7871c8a0cbec@symas.com">
      <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 &lt;&lt;EOF &gt;/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 &lt;&lt;EOF &gt;/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&gt;/run/secrets/rootpw<br>
        python /checkPassword.py $(slappasswd -T /run/secrets/rootpw) d<br>
        echo Begin-$(cat /run/secrets/rootpw)-End<br>
        # =&gt; 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:c5070626-b60e-28f5-38a3-7871c8a0cbec@symas.com">
      <pre class="moz-quote-pre" wrap="">

</pre>
      <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";>https://www.openldap.org/lists/openldap-software/200805/msg00060.html</a> but no
answer.


</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">

</pre>
    </blockquote>
  </body>
</html>

--------------0657C2ED691C0A313ADDDE9F--