[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#9137) slappasswd generate wrong SSHA from file
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:
>> 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.
>>>
>>>
--------------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:948b761f-cb48-024a-dbb2-970493a9def2@thales-services.fr">
<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: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"; moz-do-not-send="true">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/"; 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: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 <<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:c5070626-b60e-28f5-38a3-7871c8a0cbec@symas.com">
<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--