ldiftopasswd: Can it be done with SSHA hashes?

[Chuck Peters]

Content preview: Can I convert the ldif's userPassword:: "salted hash, aka
SSHA" to "hash type$salt$hash" format of shadow passwords? Or do I need to
force those users with SSHA hashed passwords to change their password? [...]


Content analysis details: (-2.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: axs.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature


Can I convert the ldif's userPassword:: "salted hash, aka SSHA" to "hash type$salt$hash" format of shadow passwords?

Or do I need to force those users with SSHA hashed passwords to change their password?

Most of the users passwords are in crypt format. I found a perl one liner to base64 decode those passwords hashes. (1)

I'm attempting to create shadow passwd files with an old Debian 6.0.10 (squeeze) LDAP installation and Debian's slapd package (2.4.23-7.3+deb6u2 squeeze-lts patched oldoldstable) includes a perl script ldiftopasswd, which I thought came from upstream, but it's not included in the most recent source of openldap. If my reading of the perl is correct, it was meant for earlier iterations of shadow passwords that did not include hash format or salt. I'm not having any success using the script this far.


1. http://www.perlmonks.org/bare/?node_id=963814
alias ldapdecode="perl -MMIME::Base64 -n -00 -e 's/\n //g;s/(?<=:: )(\S+)/decode_base64(\$1)/eg;print'" and just do ldapsearch | ldapdecode


Thanks,
Chuck

[Matthias Apitz]

Post by Chuck Peters

Can I convert the ldif's userPassword:: "salted hash, aka SSHA" > to

"hash type$salt$hash" format of shadow passwords? > > Or do I need to force
those users with SSHA hashed passwords to > change their password? > [...]


Content analysis details: (-2.6 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[178.254.4.101 listed in list.dnswl.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: unixarea.de]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars

Post by Chuck Peters
Can I convert the ldif's userPassword:: "salted hash, aka SSHA"
to "hash type$salt$hash" format of shadow passwords?
Or do I need to force those users with SSHA hashed passwords to change their password?

You will not be able to decode SSHA hashed passwords to clear text, and for
this reason to rehash them again.

matthias

[Andrew Findlay]

Post by Chuck Peters
Can I convert the ldif's userPassword:: "salted hash, aka SSHA" to "hash

type$salt$hash" format of shadow passwords? Not usefully: there is no support
for single-round SSHA1 in most Unix-like crypt(3) libraries. [...]

Content analysis details: (-4.2 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[194.106.223.201 listed in list.dnswl.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: skills-1st.co.uk]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]

Post by Chuck Peters
Can I convert the ldif's userPassword:: "salted hash, aka SSHA" to "hash type$salt$hash" format of shadow passwords?

Not usefully: there is no support for single-round SSHA1 in most Unix-like
crypt(3) libraries.

Post by Chuck Peters
Or do I need to force those users with SSHA hashed passwords to change their password?

Yes

Post by Chuck Peters
Most of the users passwords are in crypt format. I found a perl one liner to base64 decode those passwords hashes. (1)

By 'crypt format' do you mean the old Unix 13-char DES-based hash, or one of
the newer ones? At present you should really only be using the newer
multi-round hashes, with this order of preference:

$2y$ or $2a$ Bcrypt
$6$ Multi-round SHA512
$5$ Multi-round SHA256
$1$ Multi-round MD5

Post by Chuck Peters
I'm attempting to create shadow passwd files with an old Debian 6.0.10 (squeeze) LDAP installation and Debian's slapd package (2.4.23-7.3+deb6u2 squeeze-lts patched oldoldstable) includes a perl script ldiftopasswd, which I thought came from upstream, but it's not included in the most recent source of openldap. If my reading of the perl is correct, it was meant for earlier iterations of shadow passwords that did not include hash format or salt. I'm not having any success using the script this far.
1. http://www.perlmonks.org/bare/?node_id=963814
alias ldapdecode="perl -MMIME::Base64 -n -00 -e 's/\n //g;s/(?<=:: )(\S+)/decode_base64(\$1)/eg;print'" and just do ldapsearch | ldapdecode

That script simply converts the Base64 encoded fields of an LDIF file into
their native (binary) format.

Beware of old distros as they may not support all of the hash formats.

Why do you need a passwd/shadow file in the first place? Surely it is much
better to set your systems up to validate logins against LDAP directly.
That way the only thing that needs to care about hash formats is the LDAP
server process.

Andrew

[Chuck Peters]

Post by Andrew Findlay

Post by Chuck Peters

Most of the users passwords are in crypt format. I found a perl one

liner to base64 decode those passwords hashes. (1) > > By 'crypt format' do
you mean the old Unix 13-char DES-based hash, or one of > the newer ones?
At present you should really only be using the newer > multi-round hashes,
with this order of preference: [...]

Content analysis details: (-2.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: axs.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature

On Thu, Nov 5, 2015 at 9:45 AM, Andrew Findlay

Post by Andrew Findlay

Post by Chuck Peters
Most of the users passwords are in crypt format. I found a perl one liner to base64 decode those passwords hashes. (1)

By 'crypt format' do you mean the old Unix 13-char DES-based hash, or one of
the newer ones? At present you should really only be using the newer

It's the old Unix hash. If it were up to me, we would be requiring
all users change their password and update the hash to SHA512.

Post by Andrew Findlay
Beware of old distros as they may not support all of the hash formats.

I modified a passwd shell script which outputs a file with the SHA512
hash, so it is supported to some degree, but may not work for LDAP.

Post by Andrew Findlay
Why do you need a passwd/shadow file in the first place? Surely it is much
better to set your systems up to validate logins against LDAP directly.
That way the only thing that needs to care about hash formats is the LDAP
server process.

Resources is the short answer. It's only one system currently and
kind of a mess. Originally their were two systems, but system crashes
and lack of resources... It's a small non-profit where we do not want
most of our users sharing LDAP info. We need to upgrade the old
Debian OS and we are migrating to a VPS. Feb is technically when
Debian LTS support ends, and it is two OS upgrades behind.

Volunteers are working on the migration, and the only one with real
LDAP experience is volunteering primarily in an advisory capacity. I
have been running Linux mail systems since 96, but I have very little
experience with LDAP. The non-profit board of directors wants
migration done ahead of other priorities, so I want to take my time to
learn LDAP and avoid potential problems caused by our legacy mess and
inexperienced people attempting to migrate and upgrade LDAP. Once we
migrate, we can put the old system behind a firewall and take our time
migrating/upgrading LDAP.

I noticed your site http://www.skills-1st.co.uk/ has some good
resources. It would be great if we had someone with your skills and
experience volunteering!

One question I haven't completely figured out is how we have 16 users
with the SSHA hashes because 10 of them have never accessed the shell
where the passwd script results in the SSHA hash. The two other
options for changing passwords are through the web using poppassd
within webmail, and some old custom php code, and they both produce
crypt hashes. If a user has the SSHA format, they can't login to the
old php interface. Password changes within webmail work, but the user
sees "ERROR:255". And this issue seems minor compared to others we
have...


Thanks,
Chuck

[Quanah Gibson-Mount]

Content preview: --On Thursday, November 05, 2015 1:19 PM -0500 Chuck Peters
<***@axs.org> wrote: > I modified a passwd shell script which outputs
a file with the SHA512 > hash, so it is supported to some degree, but may
not work for LDAP. [...]

Content analysis details: (-4.3 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[162.209.122.174 listed in list.dnswl.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: axs.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature

--On Thursday, November 05, 2015 1:19 PM -0500 Chuck Peters

Post by Chuck Peters
I modified a passwd shell script which outputs a file with the SHA512
hash, so it is supported to some degree, but may not work for LDAP.

I'm using SSHA512 with my passwords in OpenLDAP, works just fine. You'll
want the contrib pw-sha2 module.

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration