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} =3D> 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 sa=
lt, the
'-T' seems to work as expected: (a) slappasswd -c 123 =3D> 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 alre=
ady
provided.
Unable to reproduce, SSHA works fine here.
Obviously you can't use a fixed salt with SSHA, that's the point of it=
s 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 o=
utput 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 o=
mitted. This
is already documented in the manpage.
=20 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 l= ong time. In a
Linux machine with internet, just copy paste this: =20 docker run --name slappasswd --rm -ti centos:7 bash =20 yum install openldap-servers -y =20 cat <<EOF >/makeSecret.py import os import sys import hashlib from base64 import urlsafe_b64encode as encode from base64 import urlsafe_b64decode as decode =20 def makeSecret(password): =C2=A0=C2=A0=C2=A0 salt =3D os.urandom(4) =C2=A0=C2=A0=C2=A0 h =3D hashlib.sha1(password) =C2=A0=C2=A0=C2=A0 h.update(salt) =C2=A0=C2=A0=C2=A0 return "{SSHA}" + encode(h.digest() + salt) =20 if __name__ =3D=3D '__main__': =C2=A0=C2=A0=C2=A0 print(makeSecret(sys.argv[1])) EOF =20 cat <<EOF >/checkPassword.py import os import sys import hashlib from base64 import urlsafe_b64encode as encode from base64 import urlsafe_b64decode as decode =20 def checkPassword(challenge_password, password): =C2=A0=C2=A0=C2=A0 challenge_bytes =3D decode(challenge_password[6:=
])
=C2=A0=C2=A0=C2=A0 digest =3D challenge_bytes[:20] =C2=A0=C2=A0=C2=A0 salt =3D challenge_bytes[20:] =C2=A0=C2=A0=C2=A0 hr =3D hashlib.sha1(password) =C2=A0=C2=A0=C2=A0 hr.update(salt) =C2=A0=C2=A0=C2=A0 return digest =3D=3D hr.digest()=20 if __name__ =3D=3D '__main__': =C2=A0=C2=A0=C2=A0 print(checkPassword(sys.argv[1], sys.argv[2])) EOF =20 python /checkPassword.py $(python /makeSecret.py d) d =20 python /checkPassword.py $(slappasswd -s d) d =20 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 # =3D> shows no newline: #Begin-d-End =20 It will show you that all hash works except the part with slappasswd -T=
, and I checked the newline.
I've run your steps. Your test is still invalid. Learn how to use the ech= o command.
#### [root@507ab0515ed6 /]# od -xc /run/secrets/rootpw 0000000 0a64 d \n 0000002 [root@507ab0515ed6 /]# echo -n d > /run/secrets/rootpw [root@507ab0515ed6 /]# python /checkPassword.py $(slappasswd -T /run/secr= ets/rootpw) d Warning: Password file /run/secrets/rootpw is publicly readable/writeable True [root@507ab0515ed6 /]# ####
Closing this ITS.
=20
I saw the same issue in another openldap mail: https://www.openldap.org/lists/openldap-software/200805/msg00060.html=
but no
answer.
--=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
-
hyc＠symas.com