Thanks for the response. It looks like there is already a ticket for this
which has been open for a while (

I understand that distributing hashes is a bad idea. I was considering it
mainly to do a seamless migration of clients. What was slightly unsettling
was that enabling (crypt + nis-plugin) is actually worse than plain old nis
because of limited crypt support. From a migration standpoint, it makes it
pretty much an all or nothing solution. i.e. Migrate all the NIS clients in
some way at once, either to LDAP or completely to native IPA clients, or
live with DES crypt if one wants to do a staged migration from NIS.

On Fri, Apr 3, 2015 at 9:06 AM, Simo Sorce <> wrote:

> On Thu, 2015-04-02 at 17:33 -0400, Prasun Gera wrote:
> > I had a look at ldap/servers/plugins/pwdstorage/crypt_pwd.c, and it looks
> > like it is hardcoded in crypt_pw_enc, which uses the default DES crypt
> > method. This only affects the encoding. The verification of passwords
> works
> > with any of MD5 or SHA-* schemes since the underlying crypt function in
> > recent glibcs supports them. Would it make sense to add the other options
> > to the encoding function ?
> You should probably pose that question to the 389ds team.
> From the IPA pov, these hashes are legacy and not needed because we
> *strongly* discourage users from distributing hashes around and
> recommend hashes are not made available. Rather users should use
> kerberos, or as a less desirable alternative LDAP simple binds to
> authenticate. Brute forcing weak passwords even w/o random tables is
> easy these days with the available on-demand computing power provided by
> cloud operators, so distributing hashes is riskier than ever, especially
> old hashes based on DES or MD5, but SHA-1 is not far down the list.
> HTH,
> Simo.
> --
> Simo Sorce * Red Hat, Inc * New York
Manage your subscription for the Freeipa-users mailing list:
Go to for more info on the project

Reply via email to